05:27 <mriesch> i seem to be running into stride alignment issues on the g52. are the alignment requirements documented somewhere?

08:05 <mriesch> alyssa maybe? i found this related merge request: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19620

09:25 <daniels> mriesch: what are you seeing exactly?

09:26 <daniels> are you seeing imports being rejected for not being sufficiently aligned, or mis-sampling, or misrendering, or?

09:27 <mriesch> daniels: "MESA: error: panfrost: rejecting image due to unsupported offset or stride alignment.

09:27 <mriesch> gleglimage gsteglimage.c:683:gst_egl_image_from_dmabuf: eglCreateImage failed: EGL_BAD_ALLOC"

09:29 <mriesch> this is a 1400x1050x2 image and we figure that the 2800 bytes per line are not divisible by 64

09:32 <daniels> assuming that means you're a YUV format, the alignment requirement on G52 is 16 bytes (it's still 64 for RGB)

09:32 <daniels> that's a hardware requirement that we can't work around

09:33 <daniels> so you need to make sure whatever's allocating is doing so with sufficient padding, not just w*bpp

09:33 <mriesch> daniels: yes, that's a yuv format. nv61, to be precise

09:33 <daniels> yep, stride needs to be aligned to 16b then

09:34 <mriesch> ok, 2800 is divisible by 16. does this mean we can relax the rejection condition a bit?

09:39 <bbrezillon> robclark: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30756

09:41 <daniels> mriesch: I guess you must have a downstream tree, since there's no NV61 support in upstream Mesa, but it's probably missing the check for PIPE_FORMAT_R8_G8B8_422_UNORM in src/panfrost/lib/pan_layout.c:format_minimum_alignment()

09:45 <mriesch> daniels: it's mainline, actually. however, i think the gstreamer glupload element handles nv61 as two textures

09:47 <daniels> mriesch: ah, well in that case the hardware does require 64-byte alignment for each ...

09:48 <mriesch> daniels: ah ok. are those requirements documented somewhere or did you folks RE them?

09:49 <daniels> mriesch: they're documented, but the docs aren't public

09:50 <mriesch> daniels: ok, thanks for the information then

09:51 <mriesch> daniels: now fortunately we are able to add padding in our source hardware block. but what is the way to negotiate such constraints?

10:06 <daniels> that would be https://lpc.events/event/5/contributions/592/attachments/449/704/Allocator-discussion.pdf which never really happened

10:06 <daniels> also https://lpc.events/event/5/contributions/335/attachments/426/677/Generic_Allocator_in_Nouveau.pdf

10:09 <mriesch> daniels: so we get to decide between implementing nv61 support in mesa and implementing a generic allocator infrastructure? tough call.

10:09 <mriesch> could there be a workaround solution around this? what do people usually do in such situations?

12:26 <robclark> bbrezillon: thx and a-b (I can rely on MR later)