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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #11 from Dave Witbrodt <dawitbro at sbcglobal.net> 2011-02-05 16:02:25 PST ---
(In reply to comment #9)
> 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.

In other words, because pageflipping is a feature that never existed before,
pre-existing code may simply fail to produce identical results.  There may not
be anything "wrong" at all, other than the cosmetic change in behavior.

FTR, I am not using a compositing window manager at the moment.  Actually,
strike that:  Xfce's WM, xfdesktop4, supports compositing features... but I
have always had them disabled.


> 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.

This file matches the corresponding file of the source I downloaded, built, and
installed on my system.

I have not (yet) done any GL programming.  Can you tell me whether you see a
difference between the way the effect is coded at the beginning of the game and
when a killed player is resurrected?  The reason I ask is this:  the
wipes/fades/melts at the beginning of the game and in the built-in demo have
always worked, in any combination of kernel, DDX, and Mesa I have tried.  Only
the wipe/melt effect after hitting the space bar to start over triggers
problems:  all-black wipe/melt transitions, or game hangs with kernels built at
certain commits (where no kernel should probably be built anyway).

If that is the only function used to do the wipe/melt transitions, why does it
work on some calls but not on others?


> 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.

If a Mesa sync problem is actually to blame, instead of a kernel bug or DDX
bug, then why is it so deterministic in behavior?  What I mean is, the
post-death wipe never succeeds, and the game-demo and game-start wipe never
fails.

BTW, if you folks discover that this is no kernel or DDX bug, then I'm
satisfied to have this classified as a wishlist bug:  no other aspect of the
game is affected, and, as can be see in that YouTube clip, other clones have
simply implemented the wipe effect in all black anyway.  My main concern was
that something more serious was going wrong underneath, possibly a clue to
other bug reports over the past few days.



> 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

1.  xorg.conf option:  I'll give it a try later
2.  desktop compositor:  disabled throughout
3.  experiments with gl_wipe.c:  having no experience with OpenGL coding, I am
not immediately able to perform these experiments.  I could consider this my
big chance to starting learning... but I'm not sure how quickly I can figure
out how to code those experiments.  If the code is quick and easy for you to
write, I could apply patches and test them!

Allow me to point out again (see Comments 2 and 6) that I am getting a DRM
error message which also (at least superficially) points us at kernel commit
6f34be50:

[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!

Admittedly, that message could be unrelated to the glitch I am seeing, but I've
got to admit to being tempted to believe there's a connection....

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