Hi
Am 25.02.25 um 14:45 schrieb Tomi Valkeinen:
Hi,
On 21/02/2025 11:19, Thomas Zimmermann wrote:
Hi
Am 20.02.25 um 11:53 schrieb Tomi Valkeinen:
Hi,
On 20/02/2025 12:05, Thomas Zimmermann wrote:
Hi
Am 20.02.25 um 10:18 schrieb Tomi Valkeinen:
[...]
+ * Color modes of 10, 12, 15, 30 and 64 are only supported for
use by
+ * legacy user space. Please don't use them in new code. Other
modes
+ * are not support.
+ *
+ * Do not attempt to allocate anything but linear framebuffer
memory
+ * with single-plane RGB data. Allocation of other framebuffer
+ * layouts requires dedicated ioctls in the respective DRM driver.
According to this, every driver that supports, say, NV12, should
implement their own custom ioctl to do the exact same thing? And,
of course, every userspace app that uses, say, NV12, should then
add code for all these platforms to call the custom ioctls?
Yes, that's exactly the current status.
There has been discussion about a new dumb-create ioctl that takes
a DRM format as parameter. I'm all for it, but it's out of the
scope for this series.
As libdrm's modetest currently supports YUV formats with dumb
buffers, should we remove that code, as it's not correct and I'm
sure people use libdrm code as a reference?
Of course not.
Well, I'm not serious above, but I think all my points from the
earlier version are still valid. I don't like this. It changes the
parameters of the ioctl (bpp used to be bits-per-pixel, not it's
"color mode"), and the behavior of the ioctl, behavior that we've
had for a very long time, and we have no idea how many users there
are that will break (could be none, of course). And the
documentation changes make the current behavior and uses wrong or
legacy.
Before I go into details about this statement, what use case
exactly are you referring to when you say that behavior changes?
For every dumb_buffer allocation with bpp that is not divisible by
8, the result is different, i.e. instead of DIV_ROUND_UP(width *
bpp, 8), we now have width * DIV_ROUND_UP(bpp, 8). This, of course,
depends on the driver implementation. Some already do the latter.
The current dumb-buffer code does a stride computation at [1], which
is correct for all cases; although over-allocates sometimes. It's the
one you describe as "width * DIV_ROUND_UP(bpp, 8)". It's in the ioctl
entry point, so it's somewhat authoritative for all driver's
implementations. It's also used by several drivers.
The other variant, "DIV_ROUND_UP(width * bpp, 8)", is used by
gem-dma, gem-shmem and others. It can give incorrect results and
possibly OOBs. To give a simple example, let's allocate 15-bit
XRGB1555. Bpp is 15. With a width of 1024, that would result in 1920
bytes per scanline. But because XRGB1555 has a filler bit, so the
pixel is actually 16 bit and a scanline needs to be 2048 bytes. The
new code fixes that. This is not just a hypothetical scenario: we do
have drivers that support XRGB1555 and some of them also export a
preferred_depth of 15 to userspace. [2] In the nearby comment, you'll
see that this value is meant for dumb buffers.
Rounding up the depth value in user space is possible for RGB, but
not for YUV. Here different pixel planes have a different number of
bits. Sometimes pixels are sharing bits. The value of bits-per-pixel
becomes meaningless. That's why it's also deprecated in struct
drm_format_info. The struct instead uses a more complicated per-plane
calculation to compute the number of bits per plane. [3] The
user-space code currently doing YUV on dumb buffers simply got lucky.
[1] https://elixir.bootlin.com/linux/v6.13.3/source/drivers/gpu/drm/
drm_dumb_buffers.c#L77
[2] https://elixir.bootlin.com/linux/v6.13.3/source/include/drm/
drm_mode_config.h#L885
[3] https://elixir.bootlin.com/linux/v6.13.3/source/include/drm/
drm_fourcc.h#L83
This change also first calls the drm_driver_color_mode_format(),
which could change the behavior even more, but afaics at the moment
does not.
Because currently each driver does its own thing, it can be hard to
write user space that reliably allocates on all drivers. That's why
it's important that parameters are not just raw numbers, but have
well- defined semantics. The raw bpp is meaningless; it's also
important to know which formats are associated with each value.
Otherwise, you might get a dumb buffer with a bpp of 15, but it will
be displayed incorrectly. This patch series finally implements this
and clearly documents the assumptions behind the interfaces. The
assumptions themselves have always existed.
This is perhaps where the biggest gap in understanding/view is: I have
always thought dumb-buffer's "bpp" to mean bits-per-pixel, where, for
more complex formats, "pixel" is not necessarily a visible pixel but a
container unit of some kind. So bpp * width = stride.
It would not occur to me to allocate XRGB1555 dumb-buffer with 15 bpp,
but 16 bpp, as that's what a pixel takes. I have never seen the
dumb-buffer bpp connected directly to the pixel format (that's what
the ADDFB brings in).
I may be alone with that thinking, but afaics the documentation leans
a bit on my interpretation (instead of considering bpp as a "color
mode"), although admittedly the docs also don't really say much so
this may be fully just my interpretation:
https://man.archlinux.org/man/drm-memory.7.en
Agreed, this could be read in the way you do. Is this being generated
from source somehow? The information is not incorrect, but how did they
get to this interpretation? It would definitely need an update with this
patch series applied. Citing from the man page:
"/bpp/ is the number of bits-per-pixel and must be a multiple of 8."
That's what currently works on all drivers. But nothing enforces that it
"must by a multiple of 8". Doing so would prevent C1/C2/etc pixel
formats without over-allocation. OR bpp is not bits-per-pixel but just
some factor that controls the buffer size. This is how you use it for
YUV formats.
"You most commonly want to pass 32 here."
That's also just semi-true. 32 is simply what mostly works in practice
IFF you interpret it as XRGB8888. Userspace should read the formats from
the primary plane, or at least look at the driver-provided
preferred_depth field.
https://cgit.freedesktop.org/drm/libdrm/tree/include/drm/drm_mode.h#n1055
This one doesn't say anything specific AFAICT. Bpp is somewhat pointless
information without a known pixel and framebuffer layout, as I've
outlined before.
I (mostly) understand all the complexities around here, thanks to your
replies, and I think I'm ok with the series as it doesn't break
anything (need to test the v3, though).
Thank you so much.
I still don't like it though =). And I would be happier with the
simpler "bpp" interpretation that I mentioned above, instead of it
being a color mode. But we can't have it both ways, and perhaps it's
better to unify the code and have the behavior explained explicitly as
you do in this series, even if the explanation only covers some RGB
formats.
No worries. The intention is not to break anything and existing code
will continue to work.
Best regards
Thomas
Tomi
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
