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
t
-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 __DR
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, i
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
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?
-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 t
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
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 ch
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 ma
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 trac
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 behavio
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
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
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 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 t
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
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 t
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
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,
21 matches
Mail list logo
