From b628e3893e18e663b84694256f7f5f7ff73452df Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vladim=C3=ADr=20Vondru=C5=A1?= <mosra@centrum.cz>
Date: Sun, 6 Oct 2024 22:24:06 +0200
Subject: [PATCH] GL: new "mesa-broken-dsa-framebuffer-clear" workaround.

---
 doc/changelog.dox                                 |  4 ++++
 src/Magnum/GL/Implementation/FramebufferState.cpp |  6 +++++-
 src/Magnum/GL/Implementation/driverSpecific.cpp   | 14 +++++++++++++-
 3 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/doc/changelog.dox b/doc/changelog.dox
index f7e7eb8df..454b939c0 100644
--- a/doc/changelog.dox
+++ b/doc/changelog.dox
@@ -233,6 +233,10 @@ See also:
     rendering or even crash. See @ref opengl-workarounds and
     [mosra/magnum#618](https://github.com/mosra/magnum/issues/618) for more
     information.
+-   A new @cpp "mesa-broken-dsa-framebuffer-clear" @ce workaround for a crash
+    on exit happening with Mesa 24 when the DSA variants of
+    @ref GL::Framebuffer::clearColor() and related APIs are used.  See
+    @ref opengl-workarounds for more information.
 
 @subsubsection changelog-latest-new-math Math library
 
diff --git a/src/Magnum/GL/Implementation/FramebufferState.cpp b/src/Magnum/GL/Implementation/FramebufferState.cpp
index 78896a292..5ba91f0ee 100644
--- a/src/Magnum/GL/Implementation/FramebufferState.cpp
+++ b/src/Magnum/GL/Implementation/FramebufferState.cpp
@@ -182,9 +182,13 @@ FramebufferState::FramebufferState(Context& context, Containers::StaticArrayView
     #endif
 
     /* DSA/non-DSA implementation for framebuffer clearing. Yes, it's because
-       Intel Windows drivers are shit. */
+       Intel Windows drivers are shit, and Mesa 24 seems to be stealing bugs
+       from the wrong driver. Doesn't happen on 23 and will hopefully be fixed
+       on 25? */
     #ifndef MAGNUM_TARGET_GLES
     if(context.isExtensionSupported<Extensions::ARB::direct_state_access>()
+        && (!context.versionString().contains("Mesa 24.") ||
+            context.isDriverWorkaroundDisabled("mesa-broken-dsa-framebuffer-clear"_s))
         #ifdef CORRADE_TARGET_WINDOWS
         && (!(context.detectedDriver() & Context::DetectedDriver::IntelWindows) ||
             context.isDriverWorkaroundDisabled("intel-windows-broken-dsa-framebuffer-clear"_s))
diff --git a/src/Magnum/GL/Implementation/driverSpecific.cpp b/src/Magnum/GL/Implementation/driverSpecific.cpp
index 686366753..7c6e76136 100644
--- a/src/Magnum/GL/Implementation/driverSpecific.cpp
+++ b/src/Magnum/GL/Implementation/driverSpecific.cpp
@@ -377,7 +377,8 @@ constexpr Containers::StringView KnownWorkarounds[]{
 "intel-windows-broken-dsa-layered-cubemap-array-framebuffer-attachment"_s,
 
 /* DSA glClearNamedFramebuffer*() on Intel Windows drivers doesn't do anything.
-   Using the non-DSA code path as a workaournd. */
+   Using the non-DSA code path as a workaournd. See also
+   "mesa-broken-dsa-framebuffer-clear" below. */
 "intel-windows-broken-dsa-framebuffer-clear"_s,
 
 /* Using DSA glCreateQueries() on Intel Windows drivers breaks
@@ -411,6 +412,17 @@ constexpr Containers::StringView KnownWorkarounds[]{
 "intel-windows-explicit-uniform-location-is-less-explicit-than-you-hoped"_s,
 #endif
 
+#ifndef MAGNUM_TARGET_GLES
+/* Mesa 24 (or, 24.2 at least) crashes on exit deep inside X11 if the DSA
+   glClearNamedFramebuffer() APIs are used. Not sure what's up, couldn't find
+   any relevant changelog entry and unfortunately the previous version I had
+   was only 23.3.5, so it could be anything in between. My hunch is that it's
+   due to some new code that deals with framebuffer compression and which was
+   only correctly cleaned up in the non-DSA code path. Or something. See also
+   "intel-windows-broken-dsa-framebuffer-clear" above. */
+"mesa-broken-dsa-framebuffer-clear"_s,
+#endif
+
 #ifndef MAGNUM_TARGET_GLES
 /* NVidia seems to be returning values for the default framebuffer when
    GL_IMPLEMENTATION_COLOR_READ_FORMAT and _TYPE is queried using