https://bugs.freedesktop.org/show_bug.cgi?id=98993
Bug ID: 98993 Summary: dosbox artefacts when using opengl Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: aaronbpaden@gmail.com QA Contact: dri-devel@lists.freedesktop.org
Created attachment 128338 --> https://bugs.freedesktop.org/attachment.cgi?id=128338&action=edit 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.
https://bugs.freedesktop.org/show_bug.cgi?id=98993
--- Comment #1 from smoki smoki00790@gmail.com ---
Reproduced it on Kabini APU, does not happen under LIBGL_DRI3_DISABLE=1 variable... so one of those DRI3 issues.
https://bugs.freedesktop.org/show_bug.cgi?id=98993
--- Comment #2 from smoki smoki00790@gmail.com --- 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
https://bugs.freedesktop.org/show_bug.cgi?id=98993
--- Comment #3 from Aaron Paden aaronbpaden@gmail.com --- Created attachment 128352 --> https://bugs.freedesktop.org/attachment.cgi?id=128352&action=edit 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.
https://bugs.freedesktop.org/show_bug.cgi?id=98993
--- Comment #4 from smoki smoki00790@gmail.com ---
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 :)
https://bugs.freedesktop.org/show_bug.cgi?id=98993
Michel Dänzer michel@daenzer.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |NOTOURBUG
--- Comment #5 from Michel Dänzer michel@daenzer.net --- 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.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org