[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 01:47:50 -0700 (PDT)	[thread overview]
Message-ID: <20110707084750.239A513004D@annarchy.freedesktop.org> (raw)
In-Reply-To: <bug-38800-502@http.bugs.freedesktop.org/>

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

--- Comment #29 from Michel Dänzer <michel@daenzer.net> 2011-07-07 01:47:49 PDT ---
Thanks for explaining the problems with doing everything directly in the ioctl,
Mario. Guess it was too good to be true...

I agree it should be a good idea to defer to an interrupt triggered by
completion of rendering to the new front buffer. But I don't think a newly
created fence is suitable for that, as more, unrelated rendering might have
been queued since the last rendering to the new front buffer. The existing
fence bo->tbo.sync_obj should be used. However, there might be no
bo->tbo.sync_obj if rendering has already completed.

Also, I'm afraid we do need to wait for out of vblank first, otherwise the flip
might happen one frame earlier than expected by userspace, if it manages to
call the flip ioctl during the previous vblank.

In summary, how about something like this for the flip ioctl:

1. If we're in vblank, defer step 2 until after vblank. Maybe via a vsync or
vline interrupt, or if that's not reliable, maybe it's acceptable for the ioctl
to block for up to ~1ms.

2. If the new front buffer has a bo->tbo.sync_obj fence, defer step 3 until it
has signalled.

3. Emit flip. If the hardware doesn't take it immediately, defer step 4 until
the next vertical blank.

4. Signal flip completion to userspace.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel