[Bug 33867] [bisected] Graphics corruption related to pageflip ioctl support in 2.6.38-rc*

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Sat Feb 5 14:15:29 PST 2011


https://bugs.freedesktop.org/show_bug.cgi?id=33867

--- Comment #9 from Mario Kleiner <mario.kleiner at tuebingen.mpg.de> 2011-02-05 14:15:29 PST ---
Looking at your description and the "look-alike bug" youtube video, i wonder if
it could be some synchronization bug in mesa, the ddx or a running desktop
compositor instead of a kernel bug. Something for which pageflipping is a
neccessary condition to show up.

This...

<https://www.crowproductions.de/repos/prboom/branches/prboom-plus-24/prboom2/src/gl_wipe.c>

...i believe is the code responsible for the wipe effect which goes wrong. They
take a screenshot of the start screen before the transition into a texture and
another screenshot of the end screen after the transition. Then they go through
a loop were they draw textured quads, first the fullscreen start-screen
texture, then little stripes with bits of the end screen texture.

If the wipe_scr_start_tex texture would contain all-black, you'd get the visual
artifacts you describe. That could be because they are capturing an all-black
framebuffer instead of the proper one, e.g., because mesa fails to synchronize
its framebuffer readback into textures properly with the pageflip, or because
it reads from the wrong buffer (pre-pageflip vs. post-pageflip).

Without pageflipping (enabled), there isn't any buffer exchange between front-
and backbuffer, so a possible bug in mesa would probably stay hidden.

I do remember that we had to fix some such bugs in the mesa classic driver,
also for the framebuffer readback path, i don't know about the status of the
gallium version.

You could disable page-flipping via the xorg.conf option "EnablePageFlip" "off"
(iirc) and see if that "fixes" the problem without removing any patches. Or if
disabling desktop composition makes a difference. One could also mess with that
file to see if something changes. E.g., adding a glFlush() or glFinish() or
some wait for a few hundred msecs before executing the screenshot makes a
difference. Or just display the screenshot texture for a few seconds to see if
it is indeed a black texture.

-mario

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the dri-devel mailing list