From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@freedesktop.org
Subject: [Bug 38800] glXSwapBuffersMscOML is slow on AMD Fusion but not on
Intel 945 w/Atom
Date: Thu, 7 Jul 2011 07:11:43 -0700 (PDT)
Message-ID: <20110707141144.1397313004D@annarchy.freedesktop.org>
References:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path:
Received: from annarchy.freedesktop.org (annarchy.freedesktop.org
[131.252.210.176])
by gabe.freedesktop.org (Postfix) with ESMTP id 48B3B9E894
for ;
Thu, 7 Jul 2011 07:11:44 -0700 (PDT)
In-Reply-To:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org
Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org
To: dri-devel@lists.freedesktop.org
List-Id: dri-devel@lists.freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=38800
--- Comment #32 from Jerome Glisse 2011-07-07 07:11:43 PDT ---
Well i can think of similar bad case in the other way.
-wait for vblank
-wait for bo put us in next vblank
-program reg flip happen on this frame
-irq reporting report on next vblank
So we are off by one frame on the timestamp.
To me it seems more logic to first make sure that the potentialy longer wait
(bo_wait is unbound while vblank wait is bound for any human video mode) is
done first and then do the smaller one. Yes can we miss the next vblank but so
could we with bo wait after and with bo wait after we might do bad reporting on
the timestamp.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.