On Fri, 2007-10-26 at 10:59 -0700, Jesse Barnes wrote:
diff --git a/src/glx/x11/glxcmds.c b/src/glx/x11/glxcmds.c
index 707e398..25eaccc 100644
--- a/src/glx/x11/glxcmds.c
+++ b/src/glx/x11/glxcmds.c
@@ -2919,8 +2928,10 @@ int __glXGetInternalVersion(void)
*any DRI
On 10/29/07, Michel Dänzer [EMAIL PROTECTED] wrote:
On Fri, 2007-10-26 at 10:59 -0700, Jesse Barnes wrote:
diff --git a/src/glx/x11/glxcmds.c b/src/glx/x11/glxcmds.c
index 707e398..25eaccc 100644
--- a/src/glx/x11/glxcmds.c
+++ b/src/glx/x11/glxcmds.c
@@ -2919,8 +2928,10 @@ int
On Thu, 2007-10-25 at 10:25 -0700, Jesse Barnes wrote:
On Thursday, October 25, 2007 2:02 am Michel Dänzer wrote:
It still has some bugs. When moving windows between screens, Mesa
seems to lose track of the right vblank count to sync against
sometimes, so my test app's calls to
On Friday, October 26, 2007 1:14 am Michel Dänzer wrote:
On Thu, 2007-10-25 at 10:25 -0700, Jesse Barnes wrote:
On Thursday, October 25, 2007 2:02 am Michel Dänzer wrote:
It still has some bugs. When moving windows between screens,
Mesa seems to lose track of the right vblank count to
On Wed, 2007-10-24 at 16:10 -0700, Jesse Barnes wrote:
On Tuesday, October 23, 2007 10:32 am Jesse Barnes wrote:
On Tuesday, October 23, 2007 10:03 am Jesse Barnes wrote:
On Tuesday, October 23, 2007 7:32 am Michel Dänzer wrote:
Thinking about this more, I think we can make the counter
On Thursday, October 25, 2007 2:02 am Michel Dänzer wrote:
It still has some bugs. When moving windows between screens, Mesa
seems to lose track of the right vblank count to sync against
sometimes, so my test app's calls to glXWaitVideoSyncSGI return
immediately. Moving the window back
On Tuesday, October 23, 2007 10:32 am Jesse Barnes wrote:
On Tuesday, October 23, 2007 10:03 am Jesse Barnes wrote:
On Tuesday, October 23, 2007 7:32 am Michel Dänzer wrote:
Thinking about this more, I think we can make the counter not
decrease, but I don't think we can avoid bad
Oops, this one fixes a couple of places where I was miscalculating the
actual MSC value.
Jesse
diff --git a/configs/default b/configs/default
index 620445f..3874dc7 100644
--- a/configs/default
+++ b/configs/default
@@ -79,8 +79,8 @@ APP_LIB_DEPS = -L$(TOP)/$(LIB_DIR) -l$(GLUT_LIB) -l$(GLU_LIB)
On Mon, 2007-10-22 at 16:00 -0700, Jesse Barnes wrote:
On Friday, September 28, 2007 1:06 pm Jesse Barnes wrote:
On Friday, September 28, 2007 12:51 pm Ian Romanick wrote:
No, in that case the MSC will change and possibly decrease. But
drivers can handle that case by tracking which
On Tuesday, October 23, 2007 7:32 am Michel Dänzer wrote:
Thinking about this more, I think we can make the counter not
decrease, but I don't think we can avoid bad behavior.
Why not, with something like the scheme Ian outlined above?
You snipped out the reasons: we'll get bad behavior of
On Tuesday, October 23, 2007 10:03 am Jesse Barnes wrote:
On Tuesday, October 23, 2007 7:32 am Michel Dänzer wrote:
Thinking about this more, I think we can make the counter not
decrease, but I don't think we can avoid bad behavior.
Why not, with something like the scheme Ian outlined
On Fri, 2007-09-28 at 12:31 -0700, Jesse Barnes wrote:
Ok, this version includes the changes suggested by Michel and Ian.
- update ABI version
- fixup glXGetVideoSyncSGI and glXWaitVideoSyncSGI semantics
Do you mean making sure the MSC never decreases for a given drawable? I
see you
On Monday, October 1, 2007 2:07:44 am Michel Dänzer wrote:
On Fri, 2007-09-28 at 12:31 -0700, Jesse Barnes wrote:
Ok, this version includes the changes suggested by Michel and Ian.
- update ABI version
- fixup glXGetVideoSyncSGI and glXWaitVideoSyncSGI semantics
Do you mean making
On Wed, 2007-09-26 at 11:41 -0700, Jesse Barnes wrote:
I'm not sure about the compatibility implications of these changes, it
seems like touching __DRIdrawableRec and __DriverAPIRec may affect
binary compatibility with existing drivers, is there anything else?
If compatibility isn't a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Barnes wrote:
On Wednesday, September 26, 2007 6:20 pm Ian Romanick wrote:
I do have one question now. What happens (or is intended to happen)
if the currently bound drawable is not a window?
Any thoughts on this?
Also, the current code
On Friday, September 28, 2007 11:02 am Ian Romanick wrote:
Jesse Barnes wrote:
On Wednesday, September 26, 2007 6:20 pm Ian Romanick wrote:
I do have one question now. What happens (or is intended to
happen) if the currently bound drawable is not a window?
Any thoughts on this?
No, I'm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Barnes wrote:
On Friday, September 28, 2007 11:02 am Ian Romanick wrote:
Jesse Barnes wrote:
On Wednesday, September 26, 2007 6:20 pm Ian Romanick wrote:
I do have one question now. What happens (or is intended to
happen) if the currently
On Friday, September 28, 2007 12:51 pm Ian Romanick wrote:
No, I'm not sure what should happen in this case. Doing a vblank
sync'd buffer swap or vblank wait on an offscreen drawable doesn't
make much sense does it? In what cases might those calls occur?
The spec doesn't say that an
On Wednesday, September 26, 2007 6:20 pm Ian Romanick wrote:
I have to admit that I haven't been keeping as up to date with this
thread as I should have. I've blocked off some time tomorrow morning
to fully review this patch and the discussion. I'll probably have
some questions for you, if
Per the discussion in the other vblank thread, this patch does several
things:
- adds a new getMSC hook to __DRIdrawableRec
- updates glXGetVideoSyncSGI to use the new hook if present
- adds new vblank fields to __DRIdrawablePrivateRec
- adds a new driDrawableGetMSC32 vblank.c routine
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Barnes wrote:
Per the discussion in the other vblank thread, this patch does several
things:
- adds a new getMSC hook to __DRIdrawableRec
- updates glXGetVideoSyncSGI to use the new hook if present
- adds new vblank fields to
21 matches
Mail list logo