mesa merge requestshttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests2024-03-19T23:44:41Zhttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28139loader/zink: plumb through implicit load info to suppress error messages2024-03-19T23:44:41ZMike Blumenkrantzloader/zink: plumb through implicit load info to suppress error messagesWhen loading zink implicitly, don't print error messages on failure.
this should fix issues like https://gitlab.freedesktop.org/mesa/mesa/-/issues/10802When loading zink implicitly, don't print error messages on failure.
this should fix issues like https://gitlab.freedesktop.org/mesa/mesa/-/issues/10802https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27868egl/x11/sw: try hooking up SwapBuffersWithDamage2024-03-17T00:29:55ZMike Blumenkrantzegl/x11/sw: try hooking up SwapBuffersWithDamagethis is still kinda fucked and I can't figure out how to get putimage to update the right area based on the damage regionsthis is still kinda fucked and I can't figure out how to get putimage to update the right area based on the damage regionshttps://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27805lavapipe: Implement `VK_EXT_external_memory_dma_buf`2024-03-25T19:51:39ZLucas Fryzeklavapipe: Implement `VK_EXT_external_memory_dma_buf`Continuation of !16224 based on the feedback @zmike received to use `udmabuf`.
These changes modify zmike's MR to use the udmabuf driver to allocate a dmabuf in userspace for export. Additionally these changes will also try to actually ...Continuation of !16224 based on the feedback @zmike received to use `udmabuf`.
These changes modify zmike's MR to use the udmabuf driver to allocate a dmabuf in userspace for export. Additionally these changes will also try to actually import a dmabuf with mmap to read on the CPU. This will only work with a dmabuf representing a linear buffer that has be created with the same read/write flags as the mmap operation.
I rebased his changes against main and then modified the relevant commits to use udmabuf instead for allocation. I tested these changes with CTS, as well as using weston + weston-simple-dmabuf-egl.https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27607Draft: gallium/meson: Deconflate swrast/softpipe/llvmpipe2024-02-13T22:03:54ZAdam Jacksonajax@nwnk.netDraft: gallium/meson: Deconflate swrast/softpipe/llvmpipesoftpipe is fine I guess. But it's required even if you just want to build llvmpipe. I would prefer to build at least my enterprise OS without softpipe because I don't want to support it, given that I'm already compelled to support llvmp...softpipe is fine I guess. But it's required even if you just want to build llvmpipe. I would prefer to build at least my enterprise OS without softpipe because I don't want to support it, given that I'm already compelled to support llvmpipe, and that's challenge enough, and llvmpipe really ought to be preferable in almost every circumstance. I think it's especially goofy to include a copy of softpipe inside lavapipe, though at least there I am pretty sure lavapipe will fail to initialize.
Detangling this is pretty awful and this patch definitely needs some work, but the strategy is to add `llvmpipe` and `softpipe` as names to `gallium-drivers`, and treat `swrast` as a shorthand for both. We build `src/gallium/drivers/llvmpipe` if it is named as a gallium driver _or_ if lavapipe was explicitly requested. The lavapipe target always links only llvmpipe, and the other targets link either or both as requested. Other than the lavapipe thing, which I sincerely hope is NFC, this stops short of any CI/policy/default changes and simply makes `-Dgallium-drivers=llvmpipe` do what you wanted.
Building out softpipe saves about 133k of text on aarch64, which is about 1/60th of the size of the lavapipe binary, which ain't too shabby.https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25182Draft: dri: Remove the __DRI_DRI2 extension from some backends2023-09-12T17:59:36ZAdam Jacksonajax@nwnk.netDraft: dri: Remove the __DRI_DRI2 extension from some backendsThe `__DRI_DRI2` extension really does map to client-side support for the DRI2 X11 extension, AFAICT. Nobody should be doing Vulkan with DRI2 so we can drop that from kopper, and drisw does nothing special for swaps or buffer allocation ...The `__DRI_DRI2` extension really does map to client-side support for the DRI2 X11 extension, AFAICT. Nobody should be doing Vulkan with DRI2 so we can drop that from kopper, and drisw does nothing special for swaps or buffer allocation for DRI2 so we can drop that too.https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16224Draft: lavapipe: dmabuf2024-02-27T00:24:41ZMike BlumenkrantzDraft: lavapipe: dmabuf
fixes #5318
fixes #5318https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14864drisw: fix drawing to GL_FRONT after SwapBuffers2023-06-12T21:57:43ZPeter Harrisdrisw: fix drawing to GL_FRONT after SwapBuffersThe drisw_copy_to_front function copies the back buffer to the user's
display, but it does not copy the back buffer to drisw's front buffer.
This results in incorrect drawing if an application draws to GL_FRONT on
a double-buffered visua...The drisw_copy_to_front function copies the back buffer to the user's
display, but it does not copy the back buffer to drisw's front buffer.
This results in incorrect drawing if an application draws to GL_FRONT on
a double-buffered visual. Swap the drisw front and back texture
pointers to fix this problem.
This is fast (because it's only swapping pointers), but it is incorrect
if GLX_SWAP_COPY_OML is set. (AFAIK most (all?) swrast users set
GLX_SWAP_UNDEFINED_OML, so this should be an improvement on the status
quo).
Signed-off-by: Peter Harris <pharris@opentext.com>Adam Jacksonajax@nwnk.netAdam Jacksonajax@nwnk.net