Thomas Zimmermann
2025-Feb-21 09:19 UTC
[PATCH v3 02/25] drm/dumb-buffers: Provide helper to set pitch and size
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. The color modes in?drm_driver_color_mode_format() are set in stone and will not change incompatibly. It's already a user interface. I've taken care that the results do not change incompatibly compared to what the dumb-buffer ioctl currently assumes. (C1-C4 are special, see below.)> Although, maybe some platform does width * DIV_ROUND_UP(bpp, 8) even > for bpp < 8, and then this series changes it for 1, 2 and 4 bpps (but > not for 3, 5, 6, 7, if I'm not mistaken).True. 1, 2 and 4 would currently over-allocate significantly on some drivers and the series will reduce this to actual requirements. Yet our most common memory managers, gem-dma and gem-shmem, compute the sizes correctly. But there are currently no drivers that support C4, C2 or C1 formats; hence there's likely no user space either. I know that Geert is interested in making a driver that uses these formats on very low-end hardware (something Atari or Amiga IIRC). Over-allocating on such hardware is likely not an option. The other values (3, 5, 6, 7) have no meaning I know of. 6 could be XRGB2222, but I not aware of anything using that. We don't even have a format constant for this.> > However, as the bpp is getting rounded up, this probably won't break > any user. But it _is_ a change in the behavior of a uapi, and every > time we change a uapi that's been out there for a long time, I'm > getting slightly uncomfortable.As I tried to explain, we currently have both versions in drivers: rounding up bpp and rounding up (bpp*width). User-space code already has to deal with both cases. Best regards Thomas> > So, as a summary, I have a feeling that nothing will break, but I > can't say for sure. And as I'm having trouble seeing the benefit of > this change for the user, I get even more uncomfortable. > > ?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)
Geert Uytterhoeven
2025-Feb-21 09:57 UTC
[PATCH v3 02/25] drm/dumb-buffers: Provide helper to set pitch and size
Hi Thomas, On Fri, 21 Feb 2025 at 10:19, Thomas Zimmermann <tzimmermann at suse.de> wrote:> Am 20.02.25 um 11:53 schrieb Tomi Valkeinen: > > 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. > > The color modes in drm_driver_color_mode_format() are set in stone and > will not change incompatibly. It's already a user interface. I've taken > care that the results do not change incompatibly compared to what the > dumb-buffer ioctl currently assumes. (C1-C4 are special, see below.) > > > Although, maybe some platform does width * DIV_ROUND_UP(bpp, 8) even > > for bpp < 8, and then this series changes it for 1, 2 and 4 bpps (but > > not for 3, 5, 6, 7, if I'm not mistaken). > > True. 1, 2 and 4 would currently over-allocate significantly on some > drivers and the series will reduce this to actual requirements. Yet our > most common memory managers, gem-dma and gem-shmem, compute the sizes > correctly. > > But there are currently no drivers that support C4, C2 or C1 formats; > hence there's likely no user space either. I know that Geert is > interested in making a driver that uses these formats on very low-end > hardware (something Atari or Amiga IIRC). Over-allocating on such > hardware is likely not an option.Note that the gud and ssd130x drivers do support R1, and I believe work is underway to add grayscale formats to ssd130x.> The other values (3, 5, 6, 7) have no meaning I know of. 6 could be > XRGB2222, but I not aware of anything using that. We don't even have a > format constant for this.Yeah, e.g. Amiga supports 3, 5, 6, and 7 bpp, but that is using bitplanes. There is already some sort of consensus to not expose bitplanes to userspace in DRM, so limiting to 1, 2, 4, and 8 bpp (which can be converted from C[1248]) is fine. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Tomi Valkeinen
2025-Feb-25 13:45 UTC
[PATCH v3 02/25] drm/dumb-buffers: Provide helper to set pitch and size
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 https://cgit.freedesktop.org/drm/libdrm/tree/include/drm/drm_mode.h#n1055 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). 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. Tomi