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
XDS: Intel i965 docs
Just FYI, one of the things that came up at xds is that Intel is now making a scrubbed version of the i965 docs available under NDA. Dave Airlie has been working with them at redhat, for instance. Keith - 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
XDS: Gallium slides
Gallium slides from XDS (including all the typos) now available at: http://www.tungstengraphics.com/wiki/index.php/Gallium3D Keith - 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
[Bug 12444] Black screen on Mobility Radeon 9600 M10
http://bugs.freedesktop.org/show_bug.cgi?id=12444 --- Comment #7 from [EMAIL PROTECTED] 2007-09-19 12:16 PST --- Tested today with latest git, and it still gives me a black screen on my laptop. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
[Bug 12444] Black screen on Mobility Radeon 9600 M10
http://bugs.freedesktop.org/show_bug.cgi?id=12444 --- Comment #8 from [EMAIL PROTECTED] 2007-09-19 12:22 PST --- does reverting commit dc333884c540d536bffe51a5ebfaf1822af6a91c help? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
[Bug 12444] Black screen on Mobility Radeon 9600 M10
http://bugs.freedesktop.org/show_bug.cgi?id=12444 --- Comment #9 from [EMAIL PROTECTED] 2007-09-19 22:47 PST --- Yes, it worked! :) Thank you very much! Do I leave this bug open or do you close it when it is fixed proper? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
