Created attachment 128338 [details] example image I've got an OLAND era radeon card, and I'm using mesa-git. I can confirm the issue exists using both the radeonsi and amdgpu kernel drivers. I'm using the latest SVN revision for dosbox. Using these config options: [sdl] fullresolution=desktop output=opengl [render] aspect=true which should maintain the desktop's display mode, use opengl for the output and scale it to fit the screen while maintaining the correct aspect ratio. Using these options, there are flashing artefacts outside of where the application is rendering on my hardware. The artefacts are sometimes complete garbage and other times they are noticeably the garbled remnants of a previously opened application (for example, a youtube video or a previously opened dosbox game). The issue is far more pronounced on Xorg. Using wayland, I do occasionally get a 1-pixel-wide line at the edge of dosbox's framebuffer, but it isn't flashing. It's also unlikely to be an issue with Mutter, because I've tested it out in openbox and got the same problem. IRC said it was most likely an issue on mesa's end.
Reproduced it on Kabini APU, does not happen under LIBGL_DRI3_DISABLE=1 variable... so one of those DRI3 issues.
BTW i tried not with dosbox git and not just git mesa, dosbox package from Debian Sid, mesa currently there is 13.0.2, etc... I also have DRI3 flashing with rtcw game, this looks like same issue to me :) https://packages.debian.org/sid/dosbox https://packages.debian.org/sid/rtcw
Created attachment 128352 [details] with DRI3 disabled With DRI3 disabled, I don't get the flashing, but I do get a border around dosbox's framebuffer. This is similar to what you see in Wayland, but it seems more pronounced. Note that in the no-DRI3 case, it isn't reproducible 100 percent of the time, but its fairly frequent.
Yeah, that is separate issue... try output=openglnb instead of opengl, that disable billinear filtering and seems fixes that border around dosbox. But DRI3 flickering stays :)
This is a dosbox bug, please report it to the dosbox developers: Making an apitrace of the problem and analyzing it in qapitrace, one can see that as of the third frame, dosbox no longer calls glClear and only draws to the area covered by the DOS shell, not to the borders left and right of it. Clearly, dosbox assumes that there are at most two buffers and that their contents are preserved after glXSwapBuffers, but there are no such guarantees (not even with DRI2, e.g. xf86-video-intel supports triple buffering with that as well). What dosbox could do is use e.g. the GLX_EXT_buffer_age extension to find out which parts of the current back buffer don't need to be redrawn.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.