[Bug 10761] mga dri locks up on resume from disk
http://bugs.freedesktop.org/show_bug.cgi?id=10761 --- Comment #3 from [EMAIL PROTECTED] 2007-09-18 03:36 PST --- I switched to radeon cards exactly because the suspend worked for them but not for mga. I still have some mga cards around so I could test when I get to installing them into something. Note that the default suspend code does switch to console. In the second scenario the resume worked, the system only locked up when an OpenGL application was started after resume. I use desktop systems so I don't do suspend to ram (I have never heared of a mobile mga card). I might try it but I would not be surprised if it was broken. -- 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
VIA DRM on FreeBSD
Hi, I have just read your post ( http://marc.info/?l=dri-devel&m=117661713510780) about VIA DRM on FreeBSD. It seems that you have made it work, if I'm not mistaken. I have a PCChips M791G v1.0a motherboard, which has a VIA CLE266 (unichrome) chip, and am running FreeBSD 6.2-RELEASE and X.org 7.2 on it. The only problem is that I don't have DRI on that machine, since (as far as I could find by searching mailing lists and reading wikis on dri.freedesktop.org), DRM for VIA is not still supported on FreeBSD. Could you please tell me how you managed to make the VIA drm kernel module run on 6.2-RELEASE? I am willing to do some testing if you need any help to make this work. Thanks a lot - 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
Vblanks, CRTCs and GLX, oh my!
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. 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?). 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. Any other thoughts? 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!
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
[Bug 12263] Some stencil op failed when draw bitmap
http://bugs.freedesktop.org/show_bug.cgi?id=12263 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|VERIFIED -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - 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
