[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: Wed,  6 Jul 2011 20:07:59 -0700 (PDT)	[thread overview]
Message-ID: <20110707030759.0A94513004D@annarchy.freedesktop.org> (raw)
In-Reply-To: <bug-38800-502@http.bugs.freedesktop.org/>

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

--- Comment #28 from Alex Deucher <agd5f@yahoo.com> 2011-07-06 20:07:58 PDT ---
(In reply to comment #27)
> (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"?
> 

No apparent problems, but only lightly tested.

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

All current pageflipping and modesetting happens via MMIO.  I'm not even sure
it's a problem, just thinking out loud.

> >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 ;-)

I think it was mostly due to using the same well tested code across generations
since pre-r6xx asics didn't have the flip interrupts.  Things might have
changed since I last asked months ago.  I can check again.  I'm assuming the
flip interrupts were added for a reason...

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

All asics support vline interrupts.

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