[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 #36 from Mario Kleiner <mario.kleiner@tuebingen.mpg.de> 2011-07-07 14:06:51 PDT ---
(In reply to comment #35)
> Hmm, but V_UPDATE irq is not supported on R500, if i look at the correct
> manual, which is still in widespread use for many serious applications (and on
> my main laptop for development and testing).

Hmm, and we can only use it to detect pageflip completion, not for programming
a pageflip outside of vblank, because at a regular vblank the double-buffered
display registers won't switch. Therefore we would need the vline irq anyway
for programming the flip, so maybe it is less implementation effort to only use
the vline irq? It is also supported on all asics, which is good.

At least on R500 and evergreen the vline irq is per crtc, and a crtc can either
display a fullscreen drawable, which would use page-flipping for bufferswaps,
or display a regular desktop where drawables use vline sync'ed ddx CopyRegion
blits for swapping. Offscreen blits (e.g., inside desktop compositor?) are not
vsync'ed, so maybe it can't happen that the ddx and pageflip code would make
simultaneous conflicting use of the vline irq's?

> Michel Daenzer wrote:
> Looks good, but note that we only need to avoid emitting the flip from
> the same vblank we were already in when the ioctl was called, to avoid
> flipping too early. After that, we can and probably want to emit the
> flip even from vblank, to avoid the flip being delayed by another frame.

We could use the vblank timestamping to solve this:

In ioctl() use drm_vblank_count_and_time() to get the timestamp of the
(predicted) end of the current/most recent vblank interval. If we are already
outside the "bad" vblank at ioctl() call time, this will be a timestamp in the
past. If we're inside the "bad" vblank, it will be the predicted time of the
end of the forbidden vblank. In any case, programming a flip at a
do_gettimeofday() time after that timestamp (plus maybe one or two scanline
durations for extra paranoia) would be save. We could just submit that this
deadline to the crtc->work item and check system time against it in the fence
irq handler to decide if it is safe to program the flip immediately.

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