02:14airlied: Company: in that gears demo that's failing, it's just vulkan on both sides with the dma-buf?
02:15Company: airlied: no, it's GL exporting via eglExportDMABUFImageMESA() and then Vulkan importing
02:15Company: airlied: see the other issue I linked
02:19Company: fwiw, I've spent the whole day reading mesa code trying to understand what's going on, and I've convinced myself that your patch is correct
02:20Company: and I think I've found a memleak in GTK
02:20Company: but I haven't figured out why lavapipe doesn't import the udmabuf from llvmpipe yet
02:31DavidHeidelberg: Someone knowledgeable about Neon + LLVM here? Since we can omit softpipe from the build now, I've noticed that on older Tegra 2 without Neon, the bug https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20766 is still valid. If we could keep ensure that llvmpipe will work properly on these non-Neon devices, dropping softpipe from the default 32-bit arm would be no-brainer.
02:34airlied: Company: found another minor bug, but doesn't seem to fix it
03:21airlied: Company: found the bug in llvmpipe
03:22Company: - whandle->handle = lpr->dmabuf_alloc->dmabuf_fd;
03:22Company: ?
03:24Company: I realized about 30s ago that allocate_memory_fd() has an out fd
03:25airlied: Company: nah missing storing of the row stirde
03:26Company: so I found a different thing maybe
03:28airlied: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30839 should fix the gears rendering at least
03:35Company: airlied: commented
03:44airlied: Company: fixed thanks
03:46Company: with that it looks like we will have the udmabuf introduction into GTK CI under control once https://gitlab.freedesktop.org/mesa/mesa/-/issues/11750 gets fixed
03:47Company: because I think that issue affects dmabuf'ed llvmpipe too
05:31DavidHeidelberg: company: how hard is to run only NGL tests? IMHO GTK is one of most used workloads and there are, for example, problems with Adreno 3xx series. Having it in our CI could be worth it
05:32DavidHeidelberg: also and how long these tests takes?
06:58MrCooper: DavidHeidelberg: he's not here
13:20DavidHeidelberg: Company: how hard is to run only NGL tests? IMHO GTK is one of most used workloads and there are, for example, problems with Adreno 3xx series. Having it in our CI could be worth it + how long these tests take approx.?
13:21Company: DavidHeidelberg: first question: What is "NGL tests"?
13:22Company: because our tests are usually more about functionality and then we (sometimes) plug different renderers into those
13:22Company: and theen there's the part that tests the renderers, but that part usully isn't what's finding the Mesa bugs
13:23DavidHeidelberg: ok
13:24Company: DavidHeidelberg: the one test that exposed 90% of Mesa bugs so far is https://gitlab.gnome.org/GNOME/gtk/-/blob/main/testsuite/gdk/memorytexture.c
13:24Company: I think that is self-contained (apart from requiring GTK)
13:25Company: that one just iterates over all our formats and creates a texture for all of our GdkTexture types and then tries to read them back
13:26Company: and some of those paths go through our renderers
13:27Company: but those paths essentially just do glTexImage2D() + glReadPixels() I think
13:29Company: we have a few similar tests that iterate over all formats and do glTexImage2D() + glBlitFrameBuffer() + glReadPixels() (which are mostly about making sure we don't do that when glBlitFramebuffer() doesn't work forma given format)
15:42jenatali: karolherbst: Are you sure it's expected to have writable images with LOD specified in the shader? For read-only that totally makes sense but I would be surprised if CL exposed that capability when VK only recently did and GL/D3D haven't yet
15:43karolherbst: jenatali: cl_khr_mipmap_image_writes
15:44jenatali: Ah, it's a dedicated extension?
15:44karolherbst: yeah
15:44jenatali: Ok, cool
15:44karolherbst: the ext is even kinda old
15:44karolherbst: at least 4 years
15:46karolherbst: anyway..
15:47karolherbst: I've implemented cl_khr_mipmap_image for rusticl here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30846
15:47karolherbst: it has weird interactions with gl_sharing I'm not 100% sure about... but whatever
16:12Company: MrCooper: re https://gitlab.freedesktop.org/mesa/mesa/-/issues/11750 - in current GTK git, everything's exploding rather randomly with RGB(A)16 and RGB(A)16/32f
16:13Company: MrCooper: since we enabled udmabufs - and with me plugging a bunch of texture leaks, it seems to have gotten worse???
16:17daniels: ooi are you synchronising properly?
16:18daniels: if you're going from ReadPixels to directly working on dmabufs, you're going to need to synchronise against the rendering
16:21MrCooper: I was wondering the same
16:27Company: daniels, MrCooper: that test doesn't even involve dmabufs
16:27MrCooper: how about PBOs?
16:29Company: it's creating an RGB16 texture, glTexImage2D()ing into it
16:30Company: then it creates a RGBA16 texture (because RGB16 can't be read from), drawing into it with a simple shader, and then tries a glReadPixel() from it
16:30Company: but that fails
16:31Company: actually, it uses a different (shared) GL context for that: so another glBindFramebuffer() + glReadPixels() and that one fails
16:32Company: which is indeed another recent change we did
16:34MrCooper: and glReadPixels doesn't use a PBO pack buffer?
16:35MrCooper: hmm, or if there are multiple GL contexts, maybe it's a synchronization issue between them
16:35Company: that would explain why things get worse when I plug all the leaks
16:36MrCooper: is it one thread using both contexts, or different threads?
16:37Company: same thread
16:37Company: but Mesa has threads ofc
16:39MrCooper: with a single application thread, *gl*MakeCurrent should handle synchronization I'd say
16:39MrCooper: does mesa_glthread=false make a difference for you?
16:44Company: doesn't look like it
16:46Company: I should figure out why it even fails
17:00Company: MrCooper: the new mess is a GTK bug
17:00Company: we don't clean up properly, so the mesa thread gets a deleted texture