[Bug 38800] glXSwapBuffersMscOML is slow on AMD Fusion but not on Intel 945 w/Atom

[bugzilla-daemon@freedesktop.org]

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

--- Comment #27 from Mario Kleiner <mario.kleiner@tuebingen.mpg.de> 2011-07-06 18:43:42 PDT ---
(In reply to comment #22)
> FWIW, the pageflip interrupts weren't too reliable at least on 6xx, but they
> seemed to work ok on 7xx+. 

Thanks for the info Alex. Can you define "work ok"? Is this "no apparent
problems, but only lightly tested" or more like "works nine out of ten times"?

> Also, I can see problems where you might not get
> interrupts for some flips if a later base update write comes in via the CP
> before the irq handler has acked the interrupt from the frame before it. 

When would this happen? During or close to a mode-set? Not during normal page
flipping, no? I thought that so far all crtc updates go directly via mmio
instead of the CP? Or does Atombios use the CP?

>FWIW, I asked internally and the closed driver uses vblanks. 

Ok, that's a bit scary. Do you know if it is because it is supposed to be "good
enough" or due to some real problems? I do know that the Catalyst drivers were
far from perfect wrt. vsync'ed swapping in the past. My own toolkit implements
a couple of crazy workarounds for some oddities i saw at least on Windows and
OS/X, can't remember if it was on Linux as well. So from my experience i'm not
sure if i personally would count that as a pro or contra argument against using
something else than vblank irq's ;-)

At least evergreen seems to also have vline interrupts? One could (ab)use them
as well to fake a home-grown pageflip completion interrupt, e.g., by triggering
one at scanline 1, immediately after end of vblank and then just checking in
the vline irq if the update_pending bit is clear -> pageflip completed.

-mario

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