Tomi Valkeinen
2025-Jan-16 10:03 UTC
[PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with drm_mode_size_dumb()
Hi, On 16/01/2025 10:09, Thomas Zimmermann wrote:> Hi > > > Am 15.01.25 um 15:20 schrieb Tomi Valkeinen: > [...] >> >> My point is that we have the current UAPI, and we have userspace using >> it, but we don't have clear rules what the ioctl does with specific >> parameters, and we don't document how it has to be used. >> >> Perhaps the situation is bad, and all we can really say is that >> CREATE_DUMB only works for use with simple RGB formats, and the >> behavior for all other formats is platform specific. But I think even >> that would be valuable in the UAPI docs. > > To be honest, I would not want to specify behavior for anything but the > linear RGB formats. If anything, I'd take Daniel's reply mail for > documentation as-is. Anyone stretching the UAPI beyond RGB is on their own. > >> >> Thinking about this, I wonder if this change is good for omapdrm or >> xilinx (probably other platforms too that support non-simple non-RGB >> formats via dumb buffers): without this patch, in both drivers, the >> pitch calculations just take the bpp as bit-per-pixels, align it up, >> and that's it. >> >> With this patch we end up using drm_driver_color_mode_format(), and >> aligning buffers according to RGB formats figured out via heuristics. >> It does happen to work, for the formats I tested, but it sounds like >> something that might easily not work, as it's doing adjustments based >> on wrong format. >> >> Should we have another version of drm_mode_size_dumb() which just >> calculates using the bpp, without the drm_driver_color_mode_format() >> path? Or does the drm_driver_color_mode_format() path provide some >> value for the drivers that do not currently do anything similar? > > With the RGB-only rule, using drm_driver_color_mode_format() makes > sense. It aligns dumb buffers and video=, provides error checking, and > overall harmonizes code. The fallback is only required because of the > existing odd cases that already bend the UAPI's rules.I have to disagree here. On the platforms I have been using (omap, tidss, xilinx, rcar) the dumb buffers are the only buffers you can get from the DRM driver. The dumb buffers have been used to allocate linear and multiplanar YUV buffers for a very long time on those platforms. I tried to look around, but I did not find any mentions that CREATE_DUMB should only be used for RGB buffers. Is anyone outside the core developers even aware of it? If we don't use dumb buffers there, where do we get the buffers? Maybe from a v4l2 device or from a gpu device, but often you don't have those. DMA_HEAP is there, of course. So we have the option to get DMA_HEAP buffers, specifying just the size of the buffer. Here we only specify the size, so the userspace has to understand the requirements for the format and the platform. Or we can use CREATE_DUMB, specifying the width, height and bitsperpixel, and if we don't have any heuristics about figuring out the pixel format (as it has been), the end result is exactly the same as with DMA_HEAP (i.e. we essentially define the size of the buffer). So, on these platforms (omap, tidss, xilinx, rcar), the CREATE_DUMB has always been just "give me X amount of memory that can be used for scanout". With this series, the meaning of the ioctl changes, and it's now "give me an memory buffer buffer that works with an RGB format with this width, height, bpp". In practice I believe that doesn't cause regressions, as aligning buffers according to RGB pixel format rules happens to be fine for YUV formats too, but I'm not sure (and it already almost caused a regression with bpp=64). And I'm having trouble seeing the upside. Aligning video= and dumb buffers almost sounds like going backwards. video= parameter is bad, so let's also make dumb buffers bad? Harmonizing code is fine, but I think that can be done with a function that only does the fallback-case. So... I can only speak for the platforms I'm using and maintaining, but I'd rather keep the old behavior for CREATE_DUMB that we've had for ages. Tomi
Geert Uytterhoeven
2025-Jan-16 10:17 UTC
[PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with drm_mode_size_dumb()
On Thu, Jan 16, 2025 at 11:03?AM Tomi Valkeinen <tomi.valkeinen at ideasonboard.com> wrote:> On 16/01/2025 10:09, Thomas Zimmermann wrote: > > Am 15.01.25 um 15:20 schrieb Tomi Valkeinen: > > [...] > >> > >> My point is that we have the current UAPI, and we have userspace using > >> it, but we don't have clear rules what the ioctl does with specific > >> parameters, and we don't document how it has to be used. > >> > >> Perhaps the situation is bad, and all we can really say is that > >> CREATE_DUMB only works for use with simple RGB formats, and the > >> behavior for all other formats is platform specific. But I think even > >> that would be valuable in the UAPI docs. > > > > To be honest, I would not want to specify behavior for anything but the > > linear RGB formats. If anything, I'd take Daniel's reply mail for > > documentation as-is. Anyone stretching the UAPI beyond RGB is on their own. > > > >> Thinking about this, I wonder if this change is good for omapdrm or > >> xilinx (probably other platforms too that support non-simple non-RGB > >> formats via dumb buffers): without this patch, in both drivers, the > >> pitch calculations just take the bpp as bit-per-pixels, align it up, > >> and that's it. > >> > >> With this patch we end up using drm_driver_color_mode_format(), and > >> aligning buffers according to RGB formats figured out via heuristics. > >> It does happen to work, for the formats I tested, but it sounds like > >> something that might easily not work, as it's doing adjustments based > >> on wrong format. > >> > >> Should we have another version of drm_mode_size_dumb() which just > >> calculates using the bpp, without the drm_driver_color_mode_format() > >> path? Or does the drm_driver_color_mode_format() path provide some > >> value for the drivers that do not currently do anything similar? > > > > With the RGB-only rule, using drm_driver_color_mode_format() makes > > sense. It aligns dumb buffers and video=, provides error checking, and > > overall harmonizes code. The fallback is only required because of the > > existing odd cases that already bend the UAPI's rules. > > I have to disagree here. > > On the platforms I have been using (omap, tidss, xilinx, rcar) the dumb > buffers are the only buffers you can get from the DRM driver. The dumb > buffers have been used to allocate linear and multiplanar YUV buffers > for a very long time on those platforms. > > I tried to look around, but I did not find any mentions that CREATE_DUMB > should only be used for RGB buffers. Is anyone outside the core > developers even aware of it? > > If we don't use dumb buffers there, where do we get the buffers? Maybe > from a v4l2 device or from a gpu device, but often you don't have those. > DMA_HEAP is there, of course.Why can't there be a variant that takes a proper fourcc format instead of an imprecise bpp value? 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
Thomas Zimmermann
2025-Jan-20 07:49 UTC
[PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with drm_mode_size_dumb()
Hi Am 16.01.25 um 11:03 schrieb Tomi Valkeinen: [...]> Aligning video= and dumb buffers almost sounds like going backwards. > video= parameter is bad,Who told you that? Video= is still the way to specify an initial display mode to the kernel and it will remain so. Of course, it is better to auto-detect settings, but that's for a different use case. Best regards Thomas> > Harmonizing code is fine, but I think that can be done with a function > that only does the fallback-case. > > So... I can only speak for the platforms I'm using and maintaining, > but I'd rather keep the old behavior for CREATE_DUMB that we've had > for ages. > > ?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)
Thomas Zimmermann
2025-Jan-20 07:54 UTC
[PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with drm_mode_size_dumb()
Hi Am 16.01.25 um 11:03 schrieb Tomi Valkeinen: [...]> > Harmonizing code is fine, but I think that can be done with a function > that only does the fallback-case. > > So... I can only speak for the platforms I'm using and maintaining, > but I'd rather keep the old behavior for CREATE_DUMB that we've had > for ages.And we're not going to change that. I'll also include documentation of the intended behavior and semantics in the series' next update. Whatever else is being discussed here, such as new ioctls, is a topic for a different series. 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)
Maybe Matching Threads
- [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with drm_mode_size_dumb()
- [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with drm_mode_size_dumb()
- [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with drm_mode_size_dumb()
- [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with drm_mode_size_dumb()
- [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with drm_mode_size_dumb()