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

From: bugzilla-daemon@freedesktop.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 38800] glXSwapBuffersMscOML is slow on AMD Fusion but not on Intel 945 w/Atom
Date: Thu,  7 Jul 2011 14:51:17 -0700 (PDT)	[thread overview]
Message-ID: <20110707215117.1B7BA13004D@annarchy.freedesktop.org> (raw)
In-Reply-To: <bug-38800-502@http.bugs.freedesktop.org/>

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

--- Comment #38 from Mario Kleiner <mario.kleiner@tuebingen.mpg.de> 2011-07-07 14:51:16 PDT ---
(In reply to comment #37)
> Maybe we should try and sort out why there is so much latency in the interrupt
> handler for Simon rather than rewriting the entire thing.  Or we could just use
> the pflip interrupts where they are working and use the existing code on older
> asics.

Yes. I think that delay needs to be sorted out anyway - it would also kill
dynamic clock switching which needs to happen within vblank afaik and any kind
of realtime performance, e.g., with preempt_rt kernels, if not fixed. Then the
immediate problem of Simon would go away. iirc correctly, the numbers should be
closer to 10-30 usecs, instead of close to 400 usecs, tested on Core2Duo 2.2
Ghz rv530, and ancient Athlon 1.2 Ghz with r600.

But the proposed new design could make sense for a future pageflip ioctl v2
implementation to add robustness and some headroom for things like synchronized
swaps across crtc's, swap groups, frame-sequential stereo, or lower latency
flips. I will probably toy around with this in my spare time if we choose not
to rewrite the entire thing now - which i would sort of prefer, given that the
current implementation is tested to be pretty reliable on r500+ and i have
actual users now starting to use/rely on the radeon timestamping being precise
and reliable.

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