Re: How to test whether a buffer is in linear format
On 8/6/22, Hoosier, Matt wrote: > Any idea what’s up with some compositors adding code to infer > DRM_FORMAT_MOD_LINEAR semantics when the buffer’s modifiers are set to 0? > Wlroots, for example, added this as a “safety net for drm drivers not > announcing modifiers”. > > https://source.puri.sm/Librem5/wlroots/-/merge_requests/63 For the record, that's an old piece of code from a branch that hasn't been used for a long time already, so don't pay attention to it. See https://github.com/swaywm/wlroots/pull/2090 for details. Cheers, Sebastian
Re: How to test whether a buffer is in linear format
Oh, facepalm. I didn’t even think to look at the numeric value. Sorry for the confusion. From: Simon Ser Sent: Saturday, August 6, 2022 3:10:53 PM To: Hoosier, Matt Cc: Pekka Paalanen; dri-devel@lists.freedesktop.org; wayland-de...@lists.freedesktop.org Subject: Re: How to test whether a buffer is in linear format CAUTION - EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe. On Saturday, August 6th, 2022 at 21:56, Hoosier, Matt wrote: > Any idea what’s up with some compositors adding code to infer > DRM_FORMAT_MOD_LINEAR semantics when the buffer’s modifiers are set > to 0? What does that mean? A buffer only has a single modifier, and LINEAR == 0. > Wlroots, for example, added this as a “safety net for drm drivers not > announcing modifiers”. > > https://urldefense.com/v3/__https://source.puri.sm/Librem5/wlroots/-/merge_requests/63__;!!EJc4YC3iFmQ!RegnOCvgB8sugB2skP7I220urpYpvjg8fLOw4lDYr0BxH49vOvVoFTbpykg8Nvb5Wxn33tnxgLNRAW2eePiR$ This is not upstream wlroots. This change doesn't make sense to me at all. Either a driver supports modifiers and advertises support for it, either it doesn't and gbm_surface_create_with_modifiers fails. At any rate, forcing LINEAR in this code-path doesn't make sense. CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
Re: How to test whether a buffer is in linear format
On Saturday, August 6th, 2022 at 21:56, Hoosier, Matt wrote: > Any idea what’s up with some compositors adding code to infer > DRM_FORMAT_MOD_LINEAR semantics when the buffer’s modifiers are set > to 0? What does that mean? A buffer only has a single modifier, and LINEAR == 0. > Wlroots, for example, added this as a “safety net for drm drivers not > announcing modifiers”. > > https://source.puri.sm/Librem5/wlroots/-/merge_requests/63 This is not upstream wlroots. This change doesn't make sense to me at all. Either a driver supports modifiers and advertises support for it, either it doesn't and gbm_surface_create_with_modifiers fails. At any rate, forcing LINEAR in this code-path doesn't make sense.
Re: How to test whether a buffer is in linear format
Hi Pekka, Thanks. If I paraphrase, I think you’re telling me that gbm_bo_get_modifiers() == 0 is not strong enough then. That fits with the notes on the drm_fourcc.h declaration of the linear format flag: https://elixir.bootlin.com/linux/latest/source/include/uapi/drm/drm_fourcc.h#L448 Any idea what’s up with some compositors adding code to infer DRM_FORMAT_MOD_LINEAR semantics when the buffer’s modifiers are set to 0? Wlroots, for example, added this as a “safety net for drm drivers not announcing modifiers”. https://source.puri.sm/Librem5/wlroots/-/merge_requests/63 -Matt From: Pekka Paalanen Sent: Saturday, August 6, 2022 6:47:00 AM To: Hoosier, Matt Cc: wayland-de...@lists.freedesktop.org; dri-devel@lists.freedesktop.org Subject: Re: How to test whether a buffer is in linear format On Fri, 5 Aug 2022 12:32:01 + "Hoosier, Matt" wrote: > Suppose that I want to map a GPU buffer to the CPU and do image > analysis on it. I know all the usual cautions about this being a > poor performance option, etc. But suppose for the moment that the > use-case requires it. > > What's the right set of preconditions to conclude that the buffer > is in vanilla linear representation? In other words: no > compression, tiling, or any other proprietary GPU tricks that > would prevent accessing the pixel data in the same way you would > for a dumb buffer. > Hi Matt, whoever produced the buffer must *explicitly* tell you that the buffer is using the DRM format modifier DRM_FORMAT_MOD_LINEAR. > I think that requiring the modifiers to be 0x0 would suffice. But > is that overkill? Maybe there are situations when some modifiers > are set, but they don't affect the interpretation of the pixel > data. It is not overkill, it is strictly necessary. It is not sufficient though, you must know things like stride and offset for each plane as well in addition to width, height and pixel format. All those together should be enough. Note, that DRM_FORMAT_MOD_LINEAR must be explicit. If you lack a modifier, you cannot assume it is linear. No modifier can ever be ignored. If there is no modifier, or it is invalid, then you must use some originating-driver specific means to figure out what the "real modifier" is. Thanks, pq CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
Re: How to test whether a buffer is in linear format
On Fri, 5 Aug 2022 12:32:01 + "Hoosier, Matt" wrote: > Suppose that I want to map a GPU buffer to the CPU and do image > analysis on it. I know all the usual cautions about this being a > poor performance option, etc. But suppose for the moment that the > use-case requires it. > > What's the right set of preconditions to conclude that the buffer > is in vanilla linear representation? In other words: no > compression, tiling, or any other proprietary GPU tricks that > would prevent accessing the pixel data in the same way you would > for a dumb buffer. > Hi Matt, whoever produced the buffer must *explicitly* tell you that the buffer is using the DRM format modifier DRM_FORMAT_MOD_LINEAR. > I think that requiring the modifiers to be 0x0 would suffice. But > is that overkill? Maybe there are situations when some modifiers > are set, but they don't affect the interpretation of the pixel > data. It is not overkill, it is strictly necessary. It is not sufficient though, you must know things like stride and offset for each plane as well in addition to width, height and pixel format. All those together should be enough. Note, that DRM_FORMAT_MOD_LINEAR must be explicit. If you lack a modifier, you cannot assume it is linear. No modifier can ever be ignored. If there is no modifier, or it is invalid, then you must use some originating-driver specific means to figure out what the "real modifier" is. Thanks, pq pgp1ljYdPgBxl.pgp Description: OpenPGP digital signature
How to test whether a buffer is in linear format
Suppose that I want to map a GPU buffer to the CPU and do image analysis on it. I know all the usual cautions about this being a poor performance option, etc. But suppose for the moment that the use-case requires it. What's the right set of preconditions to conclude that the buffer is in vanilla linear representation? In other words: no compression, tiling, or any other proprietary GPU tricks that would prevent accessing the pixel data in the same way you would for a dumb buffer. I think that requiring the modifiers to be 0x0 would suffice. But is that overkill? Maybe there are situations when some modifiers are set, but they don't affect the interpretation of the pixel data. Thanks -Matt
