From 50a3632027002e4a93566205d8bf3a59b55d7522 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Vladim=C3=ADr=20Vondru=C5=A1?= Date: Tue, 15 Jul 2025 11:49:54 +0200 Subject: [PATCH] GL: expand notes for the "nv-broken-buffer-dsa" workaround. --- doc/changelog.dox | 3 ++- src/Magnum/GL/Implementation/driverSpecific.cpp | 9 +++++---- 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/doc/changelog.dox b/doc/changelog.dox index 041d0a40b..cef53ab6d 100644 --- a/doc/changelog.dox +++ b/doc/changelog.dox @@ -250,7 +250,8 @@ See also: @ref opengl-workarounds for more information. - A new @cpp "nv-broken-buffer-dsa" @ce workaround for a rendering corruption on NVidia 572.82 drivers happening when DSA codepaths for @ref GL::Buffer - are used. See @ref opengl-workarounds for more information. + are used. See @ref opengl-workarounds for more information. See also + [mosra/magnum#676](https://github.com/mosra/magnum/issues/676). - A new @cpp "nv-framebuffer-invalidation-wants-draw-binding" @ce workaround for @ref GL::Framebuffer::invalidate() affecting unrelated framebuffers on NVidia. See @ref opengl-workarounds for more information. diff --git a/src/Magnum/GL/Implementation/driverSpecific.cpp b/src/Magnum/GL/Implementation/driverSpecific.cpp index 49001bda9..c45f822b5 100644 --- a/src/Magnum/GL/Implementation/driverSpecific.cpp +++ b/src/Magnum/GL/Implementation/driverSpecific.cpp @@ -230,10 +230,11 @@ constexpr Containers::StringView KnownWorkarounds[]{ /* On NV driver 572.83 and likely 566.24 as well, DSA buffer APIs don't work. This was reported on Windows with a NVIDIA RTX 2000 ADA generation graphics - card, and downgrading to 556.39 fixes that. On Arch, RTX 3050 and 570.86 it - doesn't happen. Not sure if it's really specific to that GPU generation or - it's just a regression in the platform-independent GL frontend that affects - only some cards somehow. + card, and downgrading to 556.39 fixes that. A similar issue was reported + with A3000 on Windows. On Arch, RTX 3050 and 570.86 it doesn't happen. Not + sure if it's really specific to that GPU generation or it's just a + regression in the platform-independent GL frontend that affects only some + cards somehow. The behavior is similar to the one explained below in the "intel-windows-crazy-broken-buffer-dsa" workaround (ImGui rendering