On Wednesday, September 26, 2007 12:08:13 am Michel Dänzer wrote: > On Tue, 2007-09-25 at 13:32 -0700, Jesse Barnes wrote: > > On Monday, September 24, 2007 1:25 am Michel Dänzer wrote: > > > On Fri, 2007-09-21 at 12:46 -0700, Jesse Barnes wrote: > > > > On Friday, September 21, 2007 2:51 am Michel Dänzer wrote: > > > > > > - add code to Mesa so GetMSC/WaitForMSC set > > > > > > DRM_VBLANK_SECONDARY correctly > > > > > > > > > > One idea (with some handwaving :) would be the common code > > > > > keeping around a pointer to the driver's vblank_flags variable or > > > > > keeping track of the flags per drawable in some other sensible > > > > > way. > > > > > > > > I like the idea, here's something concrete. I put the vblank stuff > > > > into the screen private, but I'm not sure if that's the best place > > > > (logically the vblank counters are screen specific), > > > > > > The drawable private would seem more appropriate, as these are > > > drawable attributes. > > > > Here's a new version > > Where's that? :)
Oops. :) I'll resend when I get back to the machine with the code... > > that moves the new fields over to the drawable private. I added a new > > drawable hook to implement the callback, and in the process discovered > > that all the drivers I could find either set their MSC routines to > > NULL or used the generic calls. > > > > So I didn't bother creating a new driver API hook for the new call; I > > just set it directly to the version in vblank.c in > > driCreateNewDrawable(). > > > > Would it make sense to rip out all the wrappers in dri_util.c, set > > everything directly in driCreateNewDrawable() and > > driUtilCreateNewScreen()? > > What exactly do you mean by 'all the wrappers'? There are wrappers in dri_util.c for this code. The drivers then point their Driver API callbacks at them (rather than using the routines in vblank.c directly for example), so it's just an extra level of indirection that doesn't seem to buy us anything, though maybe there are out of tree drivers that take advantage of this setup... > > It seems that drivers that set their MSC routines to NULL will return > > GL_BAD_CONTEXT from calls like glXWaitVideoSyncSGI(), and if e.g. > > drmWaitVBlank() failed clients would get the same result, so > > compatibility would be preserved... > > Isn't the presence or absence of the driver hooks used to decide whether > or not to advertise the GLX extension(s) though? The driver hooks would still be there, they'd just directly use the appropriate call instead of calling the dri_util.c wrappers. Jesse ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
