Re: Vblanks, CRTCs and GLX, oh my!
Jesse Barnes wrote: > Both the generic DRM vblank-rework and Intel specific pipe/plane > swapping have uncovered some vblank related problems which we discussed > at XDS last week. Unfortunately, no matter what we do (including > the "do nothing" option), some applications will break some of the time > in the new world order. > > Basically we have a few vblank related bits of code: > 1) DRM_IOCTL_WAIT_VBLANK - core DRM vblank wait ioctl > 2) driver interrupt code - increments appropriate vblank counter > 3) DRM_I915_VBLANK_SWAP - Intel specific scheduled swap ioctl > 4) SAREA private data - used for tracking which gfx plane to swap > 5) glX*VideoSyncSGI - GL interfaces for sync'ing to vblank events > > As it stands, DRM_IOCTL_WAIT_VBLANK is downright broken in the new world > of dyanmically controlled outputs and CRTCs (at least for i915 and > radeon): a client trying to sync against the second CRTC that doesn't > pass _DRM_VBLANK_SECONDARY will only work if one CRTC is enabled, due > to the way current interrupt handlers increment the respective vblank > counters (i.e. they increment the correct counter if both CRTCs are > generating events, but only the primary counter if only one CRTC vblank > interrupt is enabled). > > The Intel specific DRM_I915_VBLANK_SWAP is a really nice interface, and > is the only reliable way to get tear free vblank swap on a loaded > system. However, what it really cares about is display planes (in the > Intel sense), so it uses the _DRM_VBLANK_SECONDARY flag to indicate > whether it wants to flip plane A or B. Whether or not to pass the > _DRM_VBLANK_SECONDARY flag is determined by DRI code based on the SAREA > private data that describes how much of a given client's window is > visible on either pipe. This should work fine as of last week's mods > and only the DDX and DRM code have to be aware of potential pipe->plane > swapping due to hardware limitations. > > The vblank-rework branch of the DRM tree tries to address (1) and (2) by > splitting the logic for handling CRTCs and their associated vblank > interrupts into discrete paths, but this defeats the original purpose > of the driver interrupt code that tries to fall back to a single > counter, which is due to limitations in (5), namely that the > glX*VideoSyncSGI APIs can only handle a single pipe. > > So, what to do? One way of making the glX*VideoSyncSGI interfaces > behave more or less as expected would be to make them more like > DRM_I915_VBLANK_SWAP internally, i.e. using SAREA values to determine > which pipe needs to be sync'd against by passing in the display plane > the client is most tied to (this would imply making the Intel specific > SAREA plane info more generic), letting the DRM take care of the rest. If the SGI glx extensions aren't matching the hardware capabilities, I think it's appropriate to start talking about new extensions exposing behaviour we can support... It might be worth taking a look over the fence at the wgl world and see if there's anything useful there that might be adapted. Keit - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
On Tuesday, September 18, 2007 3:10 pm Torgeir Veimo wrote: > On 18 Sep 2007, at 22:54, Jesse Barnes wrote: > > Any other thoughts? > > Please do add the option of retrieving a serial number of the vsync > irq. It is very handy when debugging video playback that suffers from > judder. This should be possible already using glXGetVideoSyncSGI. Does that not work for you? Jesse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
On 18 Sep 2007, at 22:54, Jesse Barnes wrote: Any other thoughts? Please do add the option of retrieving a serial number of the vsync irq. It is very handy when debugging video playback that suffers from judder. -- Torgeir Veimo [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
On Tue, 2007-09-18 at 14:54 -0700, Jesse Barnes wrote: > > As it stands, DRM_IOCTL_WAIT_VBLANK is downright broken in the new world > of dyanmically controlled outputs and CRTCs (at least for i915 and > radeon): a client trying to sync against the second CRTC that doesn't > pass _DRM_VBLANK_SECONDARY will only work if one CRTC is enabled, due > to the way current interrupt handlers increment the respective vblank > counters (i.e. they increment the correct counter if both CRTCs are > generating events, but only the primary counter if only one CRTC vblank > interrupt is enabled). Yes, I made it that way to allow old Mesa drivers that don't know anything about secondary vblank to work. The trouble is that at least xf86-video-intel currently never enables vblank interrupts for pipe B only, which defeats that purpose. It's really too bad I screwed up trying to make all this backwards compatible, so I'm afraid it looks like we have to bite the bullet and make incompatible changes again to hopefully make things right finally. > The vblank-rework branch of the DRM tree tries to address (1) and (2) by > splitting the logic for handling CRTCs and their associated vblank > interrupts into discrete paths, but this defeats the original purpose > of the driver interrupt code that tries to fall back to a single > counter, which is due to limitations in (5), namely that the > glX*VideoSyncSGI APIs can only handle a single pipe. Right, it would be nice if we could preserve the above with vblank-rework. Or, I guess another option would be to stop caring about old Mesa drivers that don't know about secondary vblank and to just make sure things work as well as possible when vblank interrupts are enabled for both pipes. But note that 'old drivers' currently includes i965 and all Radeon drivers. > One way of making the glX*VideoSyncSGI interfaces behave more or less > as expected would be to make them more like DRM_I915_VBLANK_SWAP > internally, i.e. using SAREA values to determine which pipe needs to > be sync'd against by passing in the display plane the client is most > tied to (this would imply making the Intel specific SAREA plane info > more generic), Not necessarily - the driver could provide its own versions of the GetMSC and WaitForMSC hooks, or we could make the generic ones use a new driver hook to determine whether to use secondary vblank. > letting the DRM take care of the rest. Yes, this has been my idea, but I haven't got around to actually playing with it. > And no matter the outcome, we should encourage people to use interfaces > like DRM_I915_VBLANK_SWAP rather than glXWaitVideoSyncSGI, otherwise > they'll be highly susceptible to unpredictable scheduling hiccups. Right, i.e. right now use GLX_SGI_swap_control instead of GLX_SGI_video_sync whenever possible. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
On Wednesday, September 19, 2007 3:52 am Michel Dänzer wrote: > On Tue, 2007-09-18 at 14:54 -0700, Jesse Barnes wrote: > > As it stands, DRM_IOCTL_WAIT_VBLANK is downright broken in the new > > world of dyanmically controlled outputs and CRTCs (at least for > > i915 and radeon): a client trying to sync against the second CRTC > > that doesn't pass _DRM_VBLANK_SECONDARY will only work if one CRTC > > is enabled, due to the way current interrupt handlers increment the > > respective vblank counters (i.e. they increment the correct counter > > if both CRTCs are generating events, but only the primary counter > > if only one CRTC vblank interrupt is enabled). > > Yes, I made it that way to allow old Mesa drivers that don't know > anything about secondary vblank to work. The trouble is that at least > xf86-video-intel currently never enables vblank interrupts for pipe B > only, which defeats that purpose. It's really too bad I screwed up > trying to make all this backwards compatible, so I'm afraid it looks > like we have to bite the bullet and make incompatible changes again > to hopefully make things right finally. Well I'm not sure you screwed it up, before we had randr1.2 enabled drivers that scheme made a lot of sense. :) > > The vblank-rework branch of the DRM tree tries to address (1) and > > (2) by splitting the logic for handling CRTCs and their associated > > vblank interrupts into discrete paths, but this defeats the > > original purpose of the driver interrupt code that tries to fall > > back to a single counter, which is due to limitations in (5), > > namely that the glX*VideoSyncSGI APIs can only handle a single > > pipe. > > Right, it would be nice if we could preserve the above with > vblank-rework. > > Or, I guess another option would be to stop caring about old Mesa > drivers that don't know about secondary vblank and to just make sure > things work as well as possible when vblank interrupts are enabled > for both pipes. But note that 'old drivers' currently includes i965 > and all Radeon drivers. Given that some of this will break no matter what, I like this option better. > > One way of making the glX*VideoSyncSGI interfaces behave more or > > less as expected would be to make them more like > > DRM_I915_VBLANK_SWAP internally, i.e. using SAREA values to > > determine which pipe needs to be sync'd against by passing in the > > display plane the client is most tied to (this would imply making > > the Intel specific SAREA plane info more generic), > > Not necessarily - the driver could provide its own versions of the > GetMSC and WaitForMSC hooks, or we could make the generic ones use a > new driver hook to determine whether to use secondary vblank. Yeah, common code would be best. So: - use the vblank-rework tree to make per-CRTC vblank counters (as you say, this breaks some setups but will fix others) - add code to Mesa so GetMSC/WaitForMSC set DRM_VBLANK_SECONDARY correctly That should make the current stack work fairly well. And when there's a real need, we can look at adding multipipe aware extensions. I can finish up the Intel bits, but the vblank-rework tree still needs mach64, mga, r128 and via updated. And the Mesa parts of those drivers need updating to handle multiple pipes. Anyone have time to tackle those? Thanks, Jesse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Barnes wrote: > Both the generic DRM vblank-rework and Intel specific pipe/plane > swapping have uncovered some vblank related problems which we discussed > at XDS last week. Unfortunately, no matter what we do (including > the "do nothing" option), some applications will break some of the time > in the new world order. > > Basically we have a few vblank related bits of code: > 1) DRM_IOCTL_WAIT_VBLANK - core DRM vblank wait ioctl > 2) driver interrupt code - increments appropriate vblank counter > 3) DRM_I915_VBLANK_SWAP - Intel specific scheduled swap ioctl > 4) SAREA private data - used for tracking which gfx plane to swap > 5) glX*VideoSyncSGI - GL interfaces for sync'ing to vblank events > > As it stands, DRM_IOCTL_WAIT_VBLANK is downright broken in the new world > of dyanmically controlled outputs and CRTCs (at least for i915 and > radeon): a client trying to sync against the second CRTC that doesn't > pass _DRM_VBLANK_SECONDARY will only work if one CRTC is enabled, due > to the way current interrupt handlers increment the respective vblank > counters (i.e. they increment the correct counter if both CRTCs are > generating events, but only the primary counter if only one CRTC vblank > interrupt is enabled). We basically implemented DRM_IOCTL_WAIT_VBLANK as an easy way to migrate existing driver swap code to support glXSwapIntervalSGI. > The Intel specific DRM_I915_VBLANK_SWAP is a really nice interface, and > is the only reliable way to get tear free vblank swap on a loaded > system. However, what it really cares about is display planes (in the > Intel sense), so it uses the _DRM_VBLANK_SECONDARY flag to indicate > whether it wants to flip plane A or B. Whether or not to pass the > _DRM_VBLANK_SECONDARY flag is determined by DRI code based on the SAREA > private data that describes how much of a given client's window is > visible on either pipe. This should work fine as of last week's mods > and only the DDX and DRM code have to be aware of potential pipe->plane > swapping due to hardware limitations. > > The vblank-rework branch of the DRM tree tries to address (1) and (2) by > splitting the logic for handling CRTCs and their associated vblank > interrupts into discrete paths, but this defeats the original purpose > of the driver interrupt code that tries to fall back to a single > counter, which is due to limitations in (5), namely that the > glX*VideoSyncSGI APIs can only handle a single pipe. glXVideoSyncSGI and glXSwapIntervalSGI really are crappy interfaces. OpenML supplanted them with glXWaitForMscOML and glXSwapBuffersMscOML. The newer interfaces are a superset of the old, and we should look to implementing them as such. > So, what to do? One way of making the glX*VideoSyncSGI interfaces > behave more or less as expected would be to make them more like > DRM_I915_VBLANK_SWAP internally, i.e. using SAREA values to determine > which pipe needs to be sync'd against by passing in the display plane > the client is most tied to (this would imply making the Intel specific > SAREA plane info more generic), letting the DRM take care of the rest. > > Another option (which could be done in addition to the above) would be > to add some new CRTC-aware interfaces along with ways at getting at > current CRTC/display plane for a client (does GL already have this?). No. Core GL doesn't even know about windows or screens. GLX knows about displays and drawables, and that's it. > And no matter the outcome, we should encourage people to use interfaces > like DRM_I915_VBLANK_SWAP rather than glXWaitVideoSyncSGI, otherwise > they'll be highly susceptible to unpredictable scheduling hiccups. Right. Something like DRM_I915_VBLANK_SWAP should be used to implement either glXSwapIntervalSGI or glXSwapBuffersMscOML. To be honest, I'm not sure what real-world use an application could have for the glXWait interfaces. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG8VpBX1gOwKyEAw8RAmmfAJ0eq1B1CEkp/ofo86kvGBgIK5MptwCffpHA vaBiGHXYPuh9wi0MS+Zttk0= =U+Cb -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
On Wed, 2007-09-19 at 09:59 -0700, Jesse Barnes wrote: > On Wednesday, September 19, 2007 3:52 am Michel Dänzer wrote: > > On Tue, 2007-09-18 at 14:54 -0700, Jesse Barnes wrote: > > > As it stands, DRM_IOCTL_WAIT_VBLANK is downright broken in the new > > > world of dyanmically controlled outputs and CRTCs (at least for > > > i915 and radeon): a client trying to sync against the second CRTC > > > that doesn't pass _DRM_VBLANK_SECONDARY will only work if one CRTC > > > is enabled, due to the way current interrupt handlers increment the > > > respective vblank counters (i.e. they increment the correct counter > > > if both CRTCs are generating events, but only the primary counter > > > if only one CRTC vblank interrupt is enabled). > > > > Yes, I made it that way to allow old Mesa drivers that don't know > > anything about secondary vblank to work. The trouble is that at least > > xf86-video-intel currently never enables vblank interrupts for pipe B > > only, which defeats that purpose. It's really too bad I screwed up > > trying to make all this backwards compatible, so I'm afraid it looks > > like we have to bite the bullet and make incompatible changes again > > to hopefully make things right finally. > > Well I'm not sure you screwed it up, before we had randr1.2 enabled > drivers that scheme made a lot of sense. :) Except I was assuming Intel LVDS panels were driven by pipe A... > > > One way of making the glX*VideoSyncSGI interfaces behave more or > > > less as expected would be to make them more like > > > DRM_I915_VBLANK_SWAP internally, i.e. using SAREA values to > > > determine which pipe needs to be sync'd against by passing in the > > > display plane the client is most tied to (this would imply making > > > the Intel specific SAREA plane info more generic), > > > > Not necessarily - the driver could provide its own versions of the > > GetMSC and WaitForMSC hooks, or we could make the generic ones use a > > new driver hook to determine whether to use secondary vblank. > > Yeah, common code would be best. > > So: > - use the vblank-rework tree to make per-CRTC vblank counters (as > you > say, this breaks some setups but will fix others) Out of curiosity, what setups are you thinking of that this will fix on its own? Can't think of any offhand. > - 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. > That should make the current stack work fairly well. And when there's a > real need, we can look at adding multipipe aware extensions. My gut feeling is we'd be better off without apps or even toolkits dealing with this directly. So long as everything's keyed off the drawable, the GLX implementation should mostly be able to do the right thing on its own. One exception being cloned (or at least overlapping) setups where the CRTC modes aren't in sync. My idea for that has been a driconf option to choose which CRTC to sync to in case the drawable is visible on both CRTCs). -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
On Friday, September 21, 2007 2:51:02 am Michel Dänzer wrote: > > So: > > - use the vblank-rework tree to make per-CRTC vblank counters (as > > you > > say, this breaks some setups but will fix others) > > Out of curiosity, what setups are you thinking of that this will fix on > its own? Can't think of any offhand. It should fix the case where a client is waiting on pipe B when vblank interrupts on pipe A go from off to on. Currently, that'll cause the client to switch to the wrong vblank counter after pipe A's interrupts become active. In the vblank rework tree, it'll either not work in the first place (because it's using the wrong counter) or it'll work and keep working due to passing in DRM_VBLANK_SECONDARY. I think this is the correct behavior. > > - 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. Yeah, if it can be kept generic I think that would be good. > > That should make the current stack work fairly well. And when there's a > > real need, we can look at adding multipipe aware extensions. > > My gut feeling is we'd be better off without apps or even toolkits > dealing with this directly. So long as everything's keyed off the > drawable, the GLX implementation should mostly be able to do the right > thing on its own. One exception being cloned (or at least overlapping) > setups where the CRTC modes aren't in sync. My idea for that has been a > driconf option to choose which CRTC to sync to in case the drawable is > visible on both CRTCs). Yeah, makes sense. If we get this right there shouldn't be much need for exposing clients to the pipe layouts directly. Jesse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
On Fri, 2007-09-21 at 07:59 -0700, Jesse Barnes wrote: > On Friday, September 21, 2007 2:51:02 am Michel Dänzer wrote: > > > So: > > > - use the vblank-rework tree to make per-CRTC vblank counters (as > > > you > > > say, this breaks some setups but will fix others) > > > > Out of curiosity, what setups are you thinking of that this will fix on > > its own? Can't think of any offhand. > > It should fix the case where a client is waiting on pipe B when vblank > interrupts on pipe A go from off to on. Currently, that'll cause the client > to switch to the wrong vblank counter after pipe A's interrupts become > active. In the vblank rework tree, it'll either not work in the first place > (because it's using the wrong counter) or it'll work and keep working due to > passing in DRM_VBLANK_SECONDARY. I think this is the correct > behavior. Unless I'm missing something, this would only be true if xf86-video-intel ever enabled vblank interrupts for pipe B only, which it doesn't (with a DRM that supports vblank interrupts on both pipes independently). It always leaves them enabled for pipe A, even when pipe A is actually disabled. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
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), are there X
compatibility issues with changing that structure?
Porting over other drivers should be trivial...
Thanks,
Jesse
diff --git a/src/mesa/drivers/dri/common/dri_util.h b/src/mesa/drivers/dri/common/dri_util.h
index 539d28d..a1b2a1d 100644
--- a/src/mesa/drivers/dri/common/dri_util.h
+++ b/src/mesa/drivers/dri/common/dri_util.h
@@ -468,6 +468,15 @@ struct __DRIscreenPrivateRec {
/[EMAIL PROTECTED]/
/**
+ * \name Vertical blank tracking information
+ * Used for waiting on vertical blank events.
+ */
+/[EMAIL PROTECTED]/
+unsigned int vblSeq;
+unsigned int vblFlags;
+/[EMAIL PROTECTED]/
+
+/**
* \name Device-dependent private information (stored in the SAREA).
*
* This data is accessed by the client driver only.
diff --git a/src/mesa/drivers/dri/common/vblank.c b/src/mesa/drivers/dri/common/vblank.c
index e7ed545..307c957 100644
--- a/src/mesa/drivers/dri/common/vblank.c
+++ b/src/mesa/drivers/dri/common/vblank.c
@@ -63,6 +63,8 @@ int driGetMSC32( __DRIscreenPrivate * priv, int64_t * count )
vbl.request.type = DRM_VBLANK_RELATIVE;
vbl.request.sequence = 0;
+ if ( priv->vblFlags & VBLANK_FLAG_SECONDARY )
+ vbl.request.type |= DRM_VBLANK_SECONDARY;
ret = drmWaitVBlank( priv->fd, &vbl );
*count = (int64_t)vbl.reply.sequence;
@@ -124,6 +126,8 @@ int driWaitForMSC32( __DRIdrawablePrivate *priv,
vbl.request.type = dont_wait ? DRM_VBLANK_RELATIVE :
DRM_VBLANK_ABSOLUTE;
vbl.request.sequence = next;
+ if ( priv->driScreenPriv->vblFlags & VBLANK_FLAG_SECONDARY )
+ vbl.request.type |= DRM_VBLANK_SECONDARY;
if ( drmWaitVBlank( priv->driScreenPriv->fd, &vbl ) != 0 ) {
/* FIXME: This doesn't seem like the right thing to return here.
@@ -257,7 +261,13 @@ void driDrawableInitVBlank( __DRIdrawablePrivate *priv, GLuint flags,
{
if ( priv->pdraw->swap_interval == (unsigned)-1 ) {
/* Get current vertical blank sequence */
- drmVBlank vbl = { .request={ .type = DRM_VBLANK_RELATIVE, .sequence = 0 } };
+ drmVBlank vbl;
+
+ vbl.request.type = DRM_VBLANK_RELATIVE;
+ if ( flags & VBLANK_FLAG_SECONDARY ) {
+ vbl.request.type |= DRM_VBLANK_SECONDARY;
+ }
+ vbl.request.sequence = 0;
do_wait( &vbl, vbl_seq, priv->driScreenPriv->fd );
priv->pdraw->swap_interval = (flags & (VBLANK_FLAG_THROTTLE |
diff --git a/src/mesa/drivers/dri/i965/intel_blit.c b/src/mesa/drivers/dri/i965/intel_blit.c
index f88cbb2..96689c2 100644
--- a/src/mesa/drivers/dri/i965/intel_blit.c
+++ b/src/mesa/drivers/dri/i965/intel_blit.c
@@ -76,7 +76,8 @@ void intelCopyBuffer( const __DRIdrawablePrivate *dPriv,
if (!rect)
{
UNLOCK_HARDWARE( intel );
- driWaitForVBlank( dPriv, &intel->vbl_seq, intel->vblank_flags, & missed_target );
+ driWaitForVBlank( dPriv, &dPriv->driScreenPriv->vblSeq,
+ dPriv->driScreenPriv->vblFlags, &missed_target );
LOCK_HARDWARE( intel );
}
diff --git a/src/mesa/drivers/dri/i965/intel_buffers.c b/src/mesa/drivers/dri/i965/intel_buffers.c
index d155c03..a2e2128 100644
--- a/src/mesa/drivers/dri/i965/intel_buffers.c
+++ b/src/mesa/drivers/dri/i965/intel_buffers.c
@@ -33,6 +33,8 @@
#include "context.h"
#include "framebuffer.h"
#include "macros.h"
+#include "utils.h"
+#include "vblank.h"
#include "swrast/swrast.h"
GLboolean intel_intersect_cliprects( drm_clip_rect_t *dst,
@@ -172,6 +174,7 @@ static void intelSetBackClipRects( struct intel_context *intel )
void intelWindowMoved( struct intel_context *intel )
{
__DRIdrawablePrivate *dPriv = intel->driDrawable;
+ __DRIscreenPrivate *sPriv = intel->driScreen;
if (!intel->ctx.DrawBuffer) {
intelSetFrontClipRects( intel );
@@ -190,6 +193,46 @@ void intelWindowMoved( struct intel_context *intel )
}
}
+ /* Get updated plane info so we sync against the right vblank counter */
+ if (intel->intelScreen->driScrnPriv->ddxMinor >= 7) {
+ drmI830Sarea *sarea = intel->sarea;
+ drm_clip_rect_t drw_rect = { .x1 = dPriv->x, .x2 = dPriv->x + dPriv->w,
+ .y1 = dPriv->y, .y2 = dPriv->y + dPriv->h };
+ drm_clip_rect_t planeA_rect = { .x1 = sarea->planeA_x, .y1 = sarea->planeA_y,
+ .x2 = sarea->planeA_x + sarea->planeA_w,
+ .y2 = sarea->planeA_y + sarea->planeA_h };
+ drm_clip_rect_t planeB_rect = { .x1 = sarea->planeB_x, .y1 = sarea-
Re: Vblanks, CRTCs and GLX, oh my!
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. > are there X compatibility issues with changing that structure? AFAICT no - the __DRI*Private* types seem opaque outside of *_dri.so . -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
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. Ok, I'll move it over to the drawable private, assuming there's a way to get at that structure from all the paths we care about. > > are there X compatibility issues with changing that structure? > > AFAICT no - the __DRI*Private* types seem opaque outside of *_dri.so Great. I'll go ahead and push after I test again. There's no hurry on converting the other drivers; their respective maintainers can move them over when they have time. Thanks, Jesse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
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 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()? 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... Or should I add a new driver hook for the new per-drawable getMSC function and update every driver? Thanks, Jesse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
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? :) > 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'? > 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? -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
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/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
On Wed, 2007-09-26 at 07:53 -0700, Jesse Barnes wrote: > 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: > > > > > > 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, [...] AFAICT all drivers point the DriverAPI callbacks to the vblank.c functions, so I'm still not sure what you're getting at, but maybe your patch will clarify. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
On Wednesday, September 26, 2007 8:11:19 am Michel Dänzer wrote: > On Wed, 2007-09-26 at 07:53 -0700, Jesse Barnes wrote: > > 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: > > > > 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, [...] > > AFAICT all drivers point the DriverAPI callbacks to the vblank.c > functions, so I'm still not sure what you're getting at, but maybe your > patch will clarify. Err yeah I was describing it backwards. The __DRIscreen hooks for the MSC stuff all point to dri_util.c wrapper functions that end up calling the driver hooks. However, drivers always set their hooks to either NULL or to the routines in vblank.c. So we could just set the __DRIscreen hooks to point to vblank.c directly since none of the drivers appear to have custom hooks for these calls... Jesse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
On Wed, 2007-09-26 at 08:31 -0700, Jesse Barnes wrote: > On Wednesday, September 26, 2007 8:11:19 am Michel Dänzer wrote: > > On Wed, 2007-09-26 at 07:53 -0700, Jesse Barnes wrote: > > > 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: > > > > > 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, [...] > > > > AFAICT all drivers point the DriverAPI callbacks to the vblank.c > > functions, so I'm still not sure what you're getting at, but maybe your > > patch will clarify. > > Err yeah I was describing it backwards. The __DRIscreen hooks for the MSC > stuff all point to dri_util.c wrapper functions that end up calling the > driver hooks. However, drivers always set their hooks to either NULL or to > the routines in vblank.c. So we could just set the __DRIscreen hooks to > point to vblank.c directly since none of the drivers appear to have custom > hooks for these calls... I see, thanks for clarifying. Ian Romanick can probably tell us more about this. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
On Wednesday, September 26, 2007 9:39 am Michel Dänzer wrote:
> > Err yeah I was describing it backwards. The __DRIscreen hooks for
> > the MSC stuff all point to dri_util.c wrapper functions that end up
> > calling the driver hooks. However, drivers always set their hooks
> > to either NULL or to the routines in vblank.c. So we could just
> > set the __DRIscreen hooks to point to vblank.c directly since none
> > of the drivers appear to have custom hooks for these calls...
>
> I see, thanks for clarifying. Ian Romanick can probably tell us more
> about this.
And for reference, here's the updated patch.
Jesse
diff --git a/include/GL/internal/dri_interface.h b/include/GL/internal/dri_interface.h
index 8d24e31..bd898d2 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -512,6 +512,17 @@ struct __DRIdrawableRec {
*/
void (*copySubBuffer)(__DRInativeDisplay *dpy, void *drawablePrivate,
int x, int y, int w, int h);
+
+/**
+ * Like the screen version of getMSC, but also takes a drawable so that
+ * the appropriate pipe's counter can be retrieved.
+ *
+ * Get the number of vertical refreshes since some point in time before
+ * this function was first called (i.e., system start up).
+ *
+ * \since Internal API version 20070925.
+ */
+int (*getMSC)(__DRInativeDisplay *dpy, void *drawablePrivate, int64_t *msc);
};
#endif
diff --git a/src/glx/x11/glxcmds.c b/src/glx/x11/glxcmds.c
index f52b71f..134afac 100644
--- a/src/glx/x11/glxcmds.c
+++ b/src/glx/x11/glxcmds.c
@@ -1889,14 +1889,32 @@ static int __glXGetVideoSyncSGI(unsigned int *count)
if ( (gc != NULL) && gc->isDirect ) {
__GLXscreenConfigs * const psc = GetGLXScreenConfigs( gc->currentDpy,
gc->screen );
- if ( __glXExtensionBitIsEnabled( psc, SGI_video_sync_bit )
- && psc->driScreen.private && psc->driScreen.getMSC) {
- int ret;
- int64_t temp;
-
- ret = psc->driScreen.getMSC( psc->driScreen.private, & temp );
- *count = (unsigned) temp;
- return (ret == 0) ? 0 : GLX_BAD_CONTEXT;
+ if ( __glXExtensionBitIsEnabled( psc, SGI_video_sync_bit )
+ && psc->driScreen.private ) {
+ __DRIdrawable * const pdraw =
+ (*psc->driScreen.getDrawable)(gc->currentDpy,
+ gc->currentDrawable,
+ psc->driScreen.private);
+ /*
+ * Try to use the drawable's getMSC first so we get the right
+ * counter
+ */
+ if ( (pdraw != NULL) && (pdraw->getMSC != NULL) ) {
+ int ret;
+ int64_t temp;
+
+ ret = (*pdraw->getMSC)( psc->driScreen.private, pdraw->private,
+ & temp);
+ *count = (unsigned) temp;
+ return (ret == 0) ? 0 : GLX_BAD_CONTEXT;
+ } else if ( psc->driScreen.getMSC ) { /* fallback to screen */
+ int ret;
+ int64_t temp;
+
+ ret = psc->driScreen.getMSC( psc->driScreen.private, & temp );
+ *count = (unsigned) temp;
+ return (ret == 0) ? 0 : GLX_BAD_CONTEXT;
+ }
}
}
#else
diff --git a/src/mesa/drivers/dri/common/dri_util.c b/src/mesa/drivers/dri/common/dri_util.c
index c30e66f..ae2db0a 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -31,6 +31,7 @@
#include "dri_util.h"
#include "drm_sarea.h"
+#include "vblank.h"
#ifndef GLX_OML_sync_control
typedef GLboolean ( * PFNGLXGETMSCRATEOMLPROC) (__DRInativeDisplay *dpy, __DRIid drawable, int32_t *numerator, int32_t *denominator);
@@ -639,6 +640,8 @@ static void *driCreateNewDrawable(__DRInativeDisplay *dpy,
pdp->numBackClipRects = 0;
pdp->pClipRects = NULL;
pdp->pBackClipRects = NULL;
+pdp->vblSeq = 0;
+pdp->vblFlags = 0;
pdp->display = dpy;
pdp->screen = modes->screen;
@@ -663,6 +666,7 @@ static void *driCreateNewDrawable(__DRInativeDisplay *dpy,
pdraw->swapBuffersMSC = driSwapBuffersMSC;
pdraw->frameTracking = NULL;
pdraw->queryFrameTracking = driQueryFrameTracking;
+pdraw->getMSC = driDrawableGetMSC;
if (driCompareGLXAPIVersion (20060314) >= 0)
pdraw->copySubBuffer = driCopySubBuffer;
diff --git a/src/mesa/drivers/dri/common/dri_util.h b/src/mesa/drivers/dri/common/dri_util.h
index 539d28d..cb3c5d3 100644
--- a/src/mesa/drivers/dri/common/dri_util.h
+++ b/src/mesa/drivers/dri/common/dri_util.h
@@ -308,6 +308,15 @@ struct __DRIdrawablePrivateRec {
/[EMAIL PROTECTED]/
/**
+ * \name Vertical blank tracking information
+ * Used for waiting on vertical blank events.
+ */
+/[EMAIL PROTECTED]/
+unsigned int vblSeq;
+unsigned int vblFlags;
+/[EMAIL PROTECTED]/
+
+/**
* Pointer to context to which this drawable is currently bound.
*/
__DRIcontextPrivate *driContextPriv;
diff --git a/src/mesa/drivers/dri/common/vblank.c b/src/mesa/drivers/dri/common/vblank.c
index e7ed545..6ab72b3 100644
--- a/src/mesa/drivers/dri/common/vblank.c
+++ b/src/mesa/drivers/dri/common/vblank.c
@@
Re: Vblanks, CRTCs and GLX, oh my!
On 9/26/07, Michel Dänzer <[EMAIL PROTECTED]> wrote: > > On Wed, 2007-09-26 at 08:31 -0700, Jesse Barnes wrote: > > On Wednesday, September 26, 2007 8:11:19 am Michel Dänzer wrote: > > > On Wed, 2007-09-26 at 07:53 -0700, Jesse Barnes wrote: > > > > 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: > > > > > > 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, [...] > > > > > > AFAICT all drivers point the DriverAPI callbacks to the vblank.c > > > functions, so I'm still not sure what you're getting at, but maybe your > > > patch will clarify. > > > > Err yeah I was describing it backwards. The __DRIscreen hooks for the MSC > > stuff all point to dri_util.c wrapper functions that end up calling the > > driver hooks. However, drivers always set their hooks to either NULL or to > > the routines in vblank.c. So we could just set the __DRIscreen hooks to > > point to vblank.c directly since none of the drivers appear to have custom > > hooks for these calls... > > I see, thanks for clarifying. Ian Romanick can probably tell us more > about this. I think the point was that a driver that didn't implement the vblank counting using the ioctl could implement that by setting the DriverAPI hooks to point to its own implementation of those functions. No driver does this, though. cheers, Kristian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michel Dänzer wrote: > On Tue, 2007-09-25 at 13:32 -0700, Jesse Barnes wrote: >> 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? Not currently. The driver has to set the callback and tell libGL to enable the extension. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG+vxAX1gOwKyEAw8RAmOpAJwIbNfioXXEX2QOT0SkXDjIe8878gCfUZY5 1wl1bl7w0jTvC6vsaA0RfEY= =L060 -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
