Re: DRI2 direct rendering
On Wed, Apr 2, 2008 at 4:08 PM, Xiang, Haihao <[EMAIL PROTECTED]> wrote: > > On Tue, 2008-04-01 at 20:50 +0800, Kristian Høgsberg wrote: > > On Tue, Apr 1, 2008 at 5:25 AM, Jin, Gordon <[EMAIL PROTECTED]> > > wrote: > > > Kristian H?gsberg wrote on Tuesday, April 01, 2008 5:35 AM: > > > > > > > > > > Hi, > > > > > > > > I just committed the last big chunk of DRI2 work, the direct > > rendering > > > > support. With this, we can now do direct rendering to redirected > > > > windows and GLX_EXT_texture_from_pixmap even works, so compiz > > (and > > > > other Open GL compositing managers) can run in direct rendering > > mode > > > > too. > > > > > > > > I ended up rolling a couple of changes into the direct rendering > > work > > > > and the commits in mesa and xserver grew much bigger than what I > > would > > > > have liked. Short story is that the DRI2 interface and the > > legacy > > > > interface diverged and I had to break the DRI interface again. > > So I > > > > decided to make a couple of changes I'd been considering, most > > > > noticably, the GLX specifc, open coded __GLcontextModes struct is > > no > > > > longer part of the DRI driver interface, and with it glcore.h is > > also > > > > gone. This change is the cause of most of the code churn. I > > could > > > > have tried to split the commits up in a couple of independent > > commits, > > > > but it would be a lot of work and I figured it'd be nice to only > > have > > > > one commit that breaks the interface. > > > > > > > > The upshot is that git xserver AIGLX needs git mesa DRI driver > > and for > > > > DRI2, get the latest version of the xf86-video-intel > > intel-batchbuffer > > > > branch too. > > > > > > Is there an option to disable DRI2 (or say, switch to legacy DRI) > > for those who would stick to xf86-video-intel master branch (or 2.3) > > at this point? > > > > Yes, if you're not running the batchbuffer branch of the intel driver, > > none of this will kick in. The DRI2 code paths are triggered by the > > DDX driver initializing the DRI2 module in the X server, which then > > will allow the AIGLX code or libGL to initialize in DRI2 mode. If > > you're running the master intel driver or the batchbuffer branch with > > 'Option "DRI2" "off"', the DRI2 module won't get initialized and > > everything should work as before. If you see regressions in this > > case, I'd like to hear about them. > > > I'm running the master intel driver on 965 , the DRI2 will free an > invalid pointer if DRI2Connect fails. The following code fixes this > issue. > > Pushed. Thanks. Dave. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 direct rendering
On Tue, 2008-04-01 at 20:50 +0800, Kristian Høgsberg wrote: > On Tue, Apr 1, 2008 at 5:25 AM, Jin, Gordon <[EMAIL PROTECTED]> > wrote: > > Kristian H?gsberg wrote on Tuesday, April 01, 2008 5:35 AM: > > > > > > > Hi, > > > > > > I just committed the last big chunk of DRI2 work, the direct > rendering > > > support. With this, we can now do direct rendering to redirected > > > windows and GLX_EXT_texture_from_pixmap even works, so compiz > (and > > > other Open GL compositing managers) can run in direct rendering > mode > > > too. > > > > > > I ended up rolling a couple of changes into the direct rendering > work > > > and the commits in mesa and xserver grew much bigger than what I > would > > > have liked. Short story is that the DRI2 interface and the > legacy > > > interface diverged and I had to break the DRI interface again. > So I > > > decided to make a couple of changes I'd been considering, most > > > noticably, the GLX specifc, open coded __GLcontextModes struct is > no > > > longer part of the DRI driver interface, and with it glcore.h is > also > > > gone. This change is the cause of most of the code churn. I > could > > > have tried to split the commits up in a couple of independent > commits, > > > but it would be a lot of work and I figured it'd be nice to only > have > > > one commit that breaks the interface. > > > > > > The upshot is that git xserver AIGLX needs git mesa DRI driver > and for > > > DRI2, get the latest version of the xf86-video-intel > intel-batchbuffer > > > branch too. > > > > Is there an option to disable DRI2 (or say, switch to legacy DRI) > for those who would stick to xf86-video-intel master branch (or 2.3) > at this point? > > Yes, if you're not running the batchbuffer branch of the intel driver, > none of this will kick in. The DRI2 code paths are triggered by the > DDX driver initializing the DRI2 module in the X server, which then > will allow the AIGLX code or libGL to initialize in DRI2 mode. If > you're running the master intel driver or the batchbuffer branch with > 'Option "DRI2" "off"', the DRI2 module won't get initialized and > everything should work as before. If you see regressions in this > case, I'd like to hear about them. > I'm running the master intel driver on 965 , the DRI2 will free an invalid pointer if DRI2Connect fails. The following code fixes this issue. diff --git a/hw/xfree86/dri2/dri2ext.c b/hw/xfree86/dri2/dri2ext.c index ca2e029..d1d52a4 100644 --- a/hw/xfree86/dri2/dri2ext.c +++ b/hw/xfree86/dri2/dri2ext.c @@ -114,7 +114,7 @@ ProcDRI2Connect(ClientPtr client) ScreenPtr pScreen; int fd; const char *driverName; -char *busId; +char *busId = NULL; unsigned int sareaHandle; REQUEST_SIZE_MATCH(xDRI2ConnectReq); - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15203] r300 lockup
http://bugs.freedesktop.org/show_bug.cgi?id=15203 --- Comment #27 from Oliver McFadden <[EMAIL PROTECTED]> 2008-04-01 22:19:10 PST --- I would rather we just disable the writeback than adding some work around (increase the timeout, etc); we've got enough problems that I'd rather not add more work arounds. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14127] Qt4 SvgViewer Demo
http://bugs.freedesktop.org/show_bug.cgi?id=14127 Michael Fu <[EMAIL PROTECTED]> changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #3 from Michael Fu <[EMAIL PROTECTED]> 2008-04-01 19:48:35 PST --- ping for response from bug reporter... -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13409] [945GM] Killing compiz crashes Xorg
http://bugs.freedesktop.org/show_bug.cgi?id=13409 --- Comment #6 from Michael Fu <[EMAIL PROTECTED]> 2008-04-01 19:39:58 PST --- Ben, any response for Gordon's question in comment# 5? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10235] 2.6.25-rc5: Blank Screen with Intel 945
http://bugzilla.kernel.org/show_bug.cgi?id=10235 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] |bugs.osdl.org | -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. You are the assignee for the bug, or are watching the assignee. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15269] R200 crashes in glXMakeCurrent if GL_FRAGMENT_SHADER_ATI is enabled
http://bugs.freedesktop.org/show_bug.cgi?id=15269 --- Comment #4 from Stefan Dösinger <[EMAIL PROTECTED]> 2008-04-01 16:17:05 PST --- For what it's worth, I also see the same crash with 7.0.2 if I have a valid shader bound. So the problem is not the undefined shader. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15269] R200 crashes in glXMakeCurrent if GL_FRAGMENT_SHADER_ATI is enabled
http://bugs.freedesktop.org/show_bug.cgi?id=15269 --- Comment #3 from Stefan Dösinger <[EMAIL PROTECTED]> 2008-04-01 14:38:48 PST --- Wow, that was quick! I'll try to set up the git version of mesa to test if it works with my shiny new GL_ATI_fragment_shader wine code as well. Thanks, Stefan -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15269] R200 crashes in glXMakeCurrent if GL_FRAGMENT_SHADER_ATI is enabled
http://bugs.freedesktop.org/show_bug.cgi?id=15269 Roland Scheidegger <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15269] R200 crashes in glXMakeCurrent if GL_FRAGMENT_SHADER_ATI is enabled
http://bugs.freedesktop.org/show_bug.cgi?id=15269 --- Comment #2 from Roland Scheidegger <[EMAIL PROTECTED]> 2008-04-01 14:28:48 PST --- Fixed in git (master and mesa_7_0_branch), just a bogus check if ATI_fs is really enabled (that is, a valid program is bound). I've left the validation code when doing makecurrent though for now, until I understand why it's there - I've no idea what would fail if it's removed... -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15269] R200 crashes in glXMakeCurrent if GL_FRAGMENT_SHADER_ATI is enabled
http://bugs.freedesktop.org/show_bug.cgi?id=15269 --- Comment #1 from Roland Scheidegger <[EMAIL PROTECTED]> 2008-04-01 13:47:07 PST --- Hmm the driver can't handle an undefined shader, and we do state validation (why?) when a context is made current. Though I guess the same bug would happen if you'd just enable ATI_fragment_shader then try to render something without having the shader defined... -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15203] r300 lockup
http://bugs.freedesktop.org/show_bug.cgi?id=15203 --- Comment #26 from Roland Scheidegger <[EMAIL PROTECTED]> 2008-04-01 13:08:32 PST --- (In reply to comment #25) > I know now whats happening. If the ring buffer gets low on space > radeon_wait_ring is called. If writeback is enabled radeon_wait_ring can run > into the -EBUSY timeout, because it's possible that during the timeout the CP > won't update the ring pointer (few slow gpu commands in the ring buffer). Now > the -EBUSY timeout isn't handled at all, so the ring buffer gets overwritten, > with undefined result. > I'm still thinking of a clever way to fix this. Ahhh timeouts... This is actually tricky. Now, just ignoring the error and overwriting the ring clearly is a no-no, maybe should just repeat until there's no error (of course, not quite indefinitely as the chip may have locked up). Or could just increase the timeout but that's ugly too. Note that you could get the same error case even if you update the ring ptr for every quadword read, since a single command can run for a very, very long time (certainly with indirect buffers). Or if you'd want to submit a large chunk at once and the ring ptr simply didn't advance enough until it hits the timeout. (That's about what I had in mind when I mentioned it might just hide a real bug...) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15203] r300 lockup
http://bugs.freedesktop.org/show_bug.cgi?id=15203 --- Comment #25 from Markus Amsler <[EMAIL PROTECTED]> 2008-04-01 12:27:49 PST --- I know now whats happening. If the ring buffer gets low on space radeon_wait_ring is called. If writeback is enabled radeon_wait_ring can run into the -EBUSY timeout, because it's possible that during the timeout the CP won't update the ring pointer (few slow gpu commands in the ring buffer). Now the -EBUSY timeout isn't handled at all, so the ring buffer gets overwritten, with undefined result. I'm still thinking of a clever way to fix this. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15203] r300 lockup
http://bugs.freedesktop.org/show_bug.cgi?id=15203 --- Comment #24 from Markus Amsler <[EMAIL PROTECTED]> 2008-04-01 09:42:10 PST --- Disabling writeback with no_wb=1 also makes the lockup disappear. And no, it's not an april fools joke :). Resolving this should be easy now. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15203] r300 lockup
http://bugs.freedesktop.org/show_bug.cgi?id=15203 --- Comment #23 from Markus Amsler <[EMAIL PROTECTED]> 2008-04-01 07:49:50 PST --- You're right, it's the ring pointer update size. Values less than or equal 8 work fine, greater or equal 9 causes crashes. Perhaps increasing it further would cause crashes on other systems too. The fetch size has no effect on crashes. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 direct rendering
On Tue, Apr 1, 2008 at 5:25 AM, Jin, Gordon <[EMAIL PROTECTED]> wrote: > Kristian H?gsberg wrote on Tuesday, April 01, 2008 5:35 AM: > > > > Hi, > > > > I just committed the last big chunk of DRI2 work, the direct rendering > > support. With this, we can now do direct rendering to redirected > > windows and GLX_EXT_texture_from_pixmap even works, so compiz (and > > other Open GL compositing managers) can run in direct rendering mode > > too. > > > > I ended up rolling a couple of changes into the direct rendering work > > and the commits in mesa and xserver grew much bigger than what I would > > have liked. Short story is that the DRI2 interface and the legacy > > interface diverged and I had to break the DRI interface again. So I > > decided to make a couple of changes I'd been considering, most > > noticably, the GLX specifc, open coded __GLcontextModes struct is no > > longer part of the DRI driver interface, and with it glcore.h is also > > gone. This change is the cause of most of the code churn. I could > > have tried to split the commits up in a couple of independent commits, > > but it would be a lot of work and I figured it'd be nice to only have > > one commit that breaks the interface. > > > > The upshot is that git xserver AIGLX needs git mesa DRI driver and for > > DRI2, get the latest version of the xf86-video-intel intel-batchbuffer > > branch too. > > Is there an option to disable DRI2 (or say, switch to legacy DRI) for those > who would stick to xf86-video-intel master branch (or 2.3) at this point? Yes, if you're not running the batchbuffer branch of the intel driver, none of this will kick in. The DRI2 code paths are triggered by the DDX driver initializing the DRI2 module in the X server, which then will allow the AIGLX code or libGL to initialize in DRI2 mode. If you're running the master intel driver or the batchbuffer branch with 'Option "DRI2" "off"', the DRI2 module won't get initialized and everything should work as before. If you see regressions in this case, I'd like to hear about them. cheers, Kristian - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 direct rendering
On Tue, Apr 1, 2008 at 6:11 AM, Johannes Engel <[EMAIL PROTECTED]> wrote: > Thanks a lot for your work, Kristian! > Testing DRI2 on my 945GM I get > > ~> glxgears > calling DRI2CreateDrawable, XID 0x2c2, GLX ID 0x2c2 > success, head 0x30, handle 0x2 > DRM_I915_EXECBUFFER: -16 > glxgears: intel_context.c:1010: UNLOCK_HARDWARE: Assertion > `intel->batch->cliprect_mode != REFERENCES_CLIPRECTS' failed. > Aborted Hmm, I need to trim the debug output and test on i945 again :) thanks, Kristian - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 direct rendering
On Tue, Apr 1, 2008 at 6:18 AM, Xavier Bestel <[EMAIL PROTECTED]> wrote: > > On Tue, 2008-04-01 at 11:48 +0200, Xavier Bestel wrote: > > Hi Kristian, > > > > On Mon, 2008-03-31 at 17:34 -0400, Kristian Høgsberg wrote: > > > Hi, > > > > > > I just committed the last big chunk of DRI2 work, the direct rendering > > > support. With this, we can now do direct rendering to redirected > > > windows and GLX_EXT_texture_from_pixmap even works, so compiz (and > > > other Open GL compositing managers) can run in direct rendering mode > > > too. > > > > First, thanks for that work (I've been waiting for that for long). > > > > Second, does that work for people with a radeon yet, or is this still > > for testers with an Intel card ? > > OK nevermind, I just needed to read your post until the end ... Right now it's only working on intel hardware, but much of the work is chipset agnostic infrastructure. The missing piece is the memory manager for radeon card. Once that's done, much of this should fall in place for the radeon family of cards too. Kristian - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15203] r300 lockup
http://bugs.freedesktop.org/show_bug.cgi?id=15203 --- Comment #22 from Roland Scheidegger <[EMAIL PROTECTED]> 2008-04-01 05:23:51 PST --- I fail to see what's wrong with this commit. Clearly we shouldn't update the ring pointer for every command read (which just causes almost as much data traffic for writing the ring pointer as for reading commands at least in some cases), and increasing fetch size should be fine too - I'm sure fglrx does that too. Maybe you could try doing only one or the other to see what's problematic. I suspect though the reason this commit breaks things is somewhat more complicated (e.g. the small delays introduced by writing ring ptr could fix things). RADEON_CP_RB_CNTL is documented in older docs - I guess it's not in the new docs because it's not a 3d reg. There is a section on ring buffer management in the r5xx docs (which is likely exactly the same as for r3xx), though without the register defines it seems. Masks should be unnecessary (but certainly don't hurt) since the values calculated don't exceed the maximum anyway. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 direct rendering
Thanks a lot for your work, Kristian! Testing DRI2 on my 945GM I get ~> glxgears calling DRI2CreateDrawable, XID 0x2c2, GLX ID 0x2c2 success, head 0x30, handle 0x2 DRM_I915_EXECBUFFER: -16 glxgears: intel_context.c:1010: UNLOCK_HARDWARE: Assertion `intel->batch->cliprect_mode != REFERENCES_CLIPRECTS' failed. Aborted Greetings, Johannes - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GSOC '08 hardware accelerated video decoding
On Tue, Apr 01, 2008 at 12:50:08PM +0300, Pasi Kärkkäinen wrote: > On Fri, Mar 28, 2008 at 12:08:38AM -0400, Younes M wrote: > > Hi, > > > > I recently posted to the Nouveau mailing list about this, but for > > those who don't participate in that one I thought I would also post > > here since it seems to concern DRI as much as Nouveau. I intend to > > submit an application for a project that will attempt to implement > > XvMC in terms of Gallium3D. I've come up with a preliminary proposal > > and was hoping people would be willing to give it a quick read and > > give me some feedback; opinions, corrections, concerns, etc. An HTML > > version is here: http://www.bitblit.org/gsoc/gallium3d_xvmc.shtml and > > a text version is below. > > > > Hi! > > Link that I just happened to find a couple of days ago: > > http://people.freedesktop.org/~zhen/xds2007_xvmc.pdf > > Might be worth checking out.. > And forgot to mention that the pdf above is about: "XvMC for H.264/AVC" "Current work at 'h264' branch of git://people.freedesktop.org/~zhen/videoproto" -- Pasi - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 direct rendering
Hi Kristian, On Mon, 2008-03-31 at 17:34 -0400, Kristian Høgsberg wrote: > Hi, > > I just committed the last big chunk of DRI2 work, the direct rendering > support. With this, we can now do direct rendering to redirected > windows and GLX_EXT_texture_from_pixmap even works, so compiz (and > other Open GL compositing managers) can run in direct rendering mode > too. First, thanks for that work (I've been waiting for that for long). Second, does that work for people with a radeon yet, or is this still for testers with an Intel card ? Thanks, Xav - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 direct rendering
On Tue, 2008-04-01 at 11:48 +0200, Xavier Bestel wrote: > Hi Kristian, > > On Mon, 2008-03-31 at 17:34 -0400, Kristian Høgsberg wrote: > > Hi, > > > > I just committed the last big chunk of DRI2 work, the direct rendering > > support. With this, we can now do direct rendering to redirected > > windows and GLX_EXT_texture_from_pixmap even works, so compiz (and > > other Open GL compositing managers) can run in direct rendering mode > > too. > > First, thanks for that work (I've been waiting for that for long). > > Second, does that work for people with a radeon yet, or is this still > for testers with an Intel card ? OK nevermind, I just needed to read your post until the end ... Xav - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GSOC '08 hardware accelerated video decoding
On Fri, Mar 28, 2008 at 12:08:38AM -0400, Younes M wrote: > Hi, > > I recently posted to the Nouveau mailing list about this, but for > those who don't participate in that one I thought I would also post > here since it seems to concern DRI as much as Nouveau. I intend to > submit an application for a project that will attempt to implement > XvMC in terms of Gallium3D. I've come up with a preliminary proposal > and was hoping people would be willing to give it a quick read and > give me some feedback; opinions, corrections, concerns, etc. An HTML > version is here: http://www.bitblit.org/gsoc/gallium3d_xvmc.shtml and > a text version is below. > Hi! Link that I just happened to find a couple of days ago: http://people.freedesktop.org/~zhen/xds2007_xvmc.pdf Might be worth checking out.. -- Pasi - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[RFC] Intel OpRegion support for Intel post-965 graphics chips
ACPI OpRegion support for Intel Integrated Graphics is meant to improve
the communication mechanisms between graphcis driver and system/video BIOS.
The Intel graphics driver stack is composed of several different modules:
kernel drivers, user level drivers, the video BIOS, system BIOS,
and pre-programmed firmware tables. Communication between these various
components is complex and highly platform dependent in the past.
ACPI IGD OpRegion interface is intended to replace the various
inter-module communication schemes described above, particularly the
INT 10h and SMI mechanisms. With the new OpRegion interface,
system/video BIOS will send requests to kernel graphic driver for
configuring graphic hardware. With the graphic driver being the only
place to configure graphic hardware, many stability issues we encounter
in the current Linux graphics will be eliminated.
The patch is very simple now, we only enable the "driver ready" field in
the OpRegion memory. But it is needed by new platforms shipped with
intel-opregion-ready vbios. Otherwise hotkey may not work on these
platforms, since vbios will not do anything when "driver is not ready".
ACPI video driver will not receive any VGA notifications from vbios.
We can do more things when the kernel modesetting branch is ready.
Thanks,
Hong
---
linux-core/Makefile.kernel |2 +-
linux-core/i915_drv.c |4 +
linux-core/intel_opregion.c | 411 +++
shared-core/i915_dma.c |8 +
shared-core/i915_drv.h | 25 +++-
shared-core/i915_irq.c |5 +
6 files changed, 453 insertions(+), 2 deletions(-)
create mode 100644 linux-core/intel_opregion.c
diff --git a/linux-core/Makefile.kernel b/linux-core/Makefile.kernel
index f012262..2bdd57f 100644
--- a/linux-core/Makefile.kernel
+++ b/linux-core/Makefile.kernel
@@ -20,7 +20,7 @@ r128-objs := r128_drv.o r128_cce.o r128_state.o r128_irq.o
mga-objs:= mga_drv.o mga_dma.o mga_state.o mga_warp.o mga_irq.o
i810-objs := i810_drv.o i810_dma.o
i915-objs := i915_drv.o i915_dma.o i915_irq.o i915_mem.o i915_fence.o \
- i915_buffer.o i915_compat.o i915_execbuf.o
+ i915_buffer.o i915_compat.o i915_execbuf.o intel_opregion.o
nouveau-objs := nouveau_drv.o nouveau_state.o nouveau_fifo.o nouveau_mem.o \
nouveau_object.o nouveau_irq.o nouveau_notifier.o
nouveau_swmthd.o \
nouveau_sgdma.o nouveau_dma.o nouveau_bo.o nouveau_fence.o \
diff --git a/linux-core/i915_drv.c b/linux-core/i915_drv.c
index e18bc8d..bac07ce 100644
--- a/linux-core/i915_drv.c
+++ b/linux-core/i915_drv.c
@@ -392,6 +392,8 @@ static int i915_suspend(struct drm_device *dev,
pm_message_t state)
i915_save_vga(dev);
+ intel_opregion_free(dev);
+
if (state.event == PM_EVENT_SUSPEND) {
/* Shut down the device */
pci_disable_device(dev->pdev);
@@ -549,6 +551,8 @@ static int i915_resume(struct drm_device *dev)
i915_restore_vga(dev);
+ intel_opregion_init(dev);
+
return 0;
}
diff --git a/linux-core/intel_opregion.c b/linux-core/intel_opregion.c
new file mode 100644
index 000..5e64b51
--- /dev/null
+++ b/linux-core/intel_opregion.c
@@ -0,0 +1,411 @@
+#include
+
+#include "drmP.h"
+#include "i915_drm.h"
+#include "i915_drv.h"
+
+#define PCI_ASLE 0xe4
+#define PCI_ASLS 0xfc
+
+#define OPREGION_SZ(8*1024)
+#define OPREGION_HEADER_OFFSET 0
+#define OPREGION_ACPI_OFFSET 0x100
+#define OPREGION_SWSCI_OFFSET 0x200
+#define OPREGION_ASLE_OFFSET 0x300
+#define OPREGION_VBT_OFFSET0x1000
+
+#define OPREGION_SIGNATURE "IntelGraphicsMem"
+#define MBOX_ACPI (1<<0)
+#define MBOX_SWSCI (1<<1)
+#define MBOX_ASLE (1<<2)
+
+/* _DOD id definitions */
+#define OUTPUT_CONNECTOR_MSK 0xf000
+#define OUTPUT_CONNECTOR_OFFSET12
+
+#define OUTPUT_PORT_MSK0x00f0
+#define OUTPUT_PORT_OFFSET 4
+ #define OUTPUT_PORT_ANALOG 0
+ #define OUTPUT_PORT_LVDS 1
+ #define OUTPUT_PORT_SDVOB2
+ #define OUTPUT_PORT_SDVOC3
+ #define OUTPUT_PORT_TV 4
+
+#define OUTPUT_DISPLAY_MSK 0x0f00
+#define OUTPUT_DISPLAY_OFFSET 8
+ #define OUTPUT_DISPLAY_OTHER 0
+ #define OUTPUT_DISPLAY_VGA 1
+ #define OUTPUT_DISPLAY_TV2
+ #define OUTPUT_DISPLAY_DIGI 3
+ #define OUTPUT_DISPLAY_FLAT_PANEL4
+
+/* predefined id for integrated LVDS and VGA connector */
+#define OUTPUT_INT_LVDS0x0110
+#define OUTPUT_INT_VGA 0x8100
+
+struct opregion_header {
+ u8 signature[16];
+ u32 size;
+ u32 opregion_ver;
+ u8 bios_ver[32];
+ u8 vbios_ver[16];
+ u8 driver_ver[16];
+ u32 mboxes;
+ u8 reserved[164];
+} __attribute__((packed));
+
+/* OpRegion mailbox #1: public ACPI methods */
+struct opregion_acpi {
+ u32 drdy; /* driver readiness */
+ u32 csts; /* notification status */
+ u32 cevt;
RE: DRI2 direct rendering
Kristian H?gsberg wrote on Tuesday, April 01, 2008 5:35 AM: > Hi, > > I just committed the last big chunk of DRI2 work, the direct rendering > support. With this, we can now do direct rendering to redirected > windows and GLX_EXT_texture_from_pixmap even works, so compiz (and > other Open GL compositing managers) can run in direct rendering mode > too. > > I ended up rolling a couple of changes into the direct rendering work > and the commits in mesa and xserver grew much bigger than what I would > have liked. Short story is that the DRI2 interface and the legacy > interface diverged and I had to break the DRI interface again. So I > decided to make a couple of changes I'd been considering, most > noticably, the GLX specifc, open coded __GLcontextModes struct is no > longer part of the DRI driver interface, and with it glcore.h is also > gone. This change is the cause of most of the code churn. I could > have tried to split the commits up in a couple of independent commits, > but it would be a lot of work and I figured it'd be nice to only have > one commit that breaks the interface. > > The upshot is that git xserver AIGLX needs git mesa DRI driver and for > DRI2, get the latest version of the xf86-video-intel intel-batchbuffer > branch too. Is there an option to disable DRI2 (or say, switch to legacy DRI) for those who would stick to xf86-video-intel master branch (or 2.3) at this point? Gordon - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15203] r300 lockup
http://bugs.freedesktop.org/show_bug.cgi?id=15203 --- Comment #21 from Markus Amsler <[EMAIL PROTECTED]> 2008-04-01 01:15:59 PST --- The mask patch didn't help With 318157.. reverted texsub runs fine with tris=1000. I notice the pattern in the triangles too. I looked at RADEON_CP_RB_CNTL With 318157..: 0x00040911 Without 318157.. : 0x0011 I searched the documentation for RADEON_CP_RB_CNTL but didn't found it. In fact I didn't found any ring buffer related registers. I'm also wondering where the shift/mask values come from. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15297] Bug opengl (incorect display)
http://bugs.freedesktop.org/show_bug.cgi?id=15297 --- Comment #2 from Dmitriy <[EMAIL PROTECTED]> 2008-04-01 00:44:55 PST --- Created an attachment (id=15596) --> (http://bugs.freedesktop.org/attachment.cgi?id=15596) Example code for test this bug -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15297] Bug opengl (incorect display)
http://bugs.freedesktop.org/show_bug.cgi?id=15297 --- Comment #1 from Dmitriy <[EMAIL PROTECTED]> 2008-04-01 00:44:14 PST --- Created an attachment (id=15595) --> (http://bugs.freedesktop.org/attachment.cgi?id=15595) If use vesa drv -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15297] New: Bug opengl (incorect display)
http://bugs.freedesktop.org/show_bug.cgi?id=15297
Summary: Bug opengl (incorect display)
Product: Mesa
Version: 6.5
Platform: Other
OS/Version: Linux (All)
Status: NEW
Severity: major
Priority: high
Component: Drivers/DRI/Unichrome
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: [EMAIL PROTECTED]
Created an attachment (id=15594)
--> (http://bugs.freedesktop.org/attachment.cgi?id=15594)
BugOpenshrome
Please look attachment
Incorect display Xtree (if use vesa drv - ok, openchrome - no display) , for
example code :
main.cpp
#include
#include "myglwidget.h"
int main(int argc,char** argv)
{
QApplication app(argc,argv);
MyGLWidget myglw;
myglw.setFixedSize(500,500);
myglw.show();
app.setMainWidget(&myglw);
return app.exec();
}
myglwidget.h
#ifndef _myglwidget_h_
#define _myglwidget_h_
#include
class MyGLWidget:public QGLWidget
{
Q_OBJECT
protected:
virtual void paintGL();
virtual void initializeGL();
virtual void resizeGL(int nWidth,int nHeight);
};
#endif //_myglwidget_h_
myglwidget.cpp
#include "myglwidget.h"
void MyGLWidget::initializeGL()
{
qglClearColor(white);
}
void MyGLWidget::resizeGL(int nWidth,int nHeight)
{
glViewport(0,0,(GLint)nWidth,(GLint)nHeight);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrtho(0,100,0,100,-1,1);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
}
void MyGLWidget::paintGL()
{
glClear(GL_COLOR_BUFFER_BIT);
glColor3f(0.0,0.0,0.0);
glEnable(GL_LINE_STIPPLE);
GLint linepattern=0xFF18;
glLineStipple(2,linepattern);
glLineWidth(2.0f);
glBegin(GL_LINE_LOOP);
glVertex2f(5,5);
glVertex2f(5,95);
glVertex2f(95,95);
glVertex2f(95,5);
glEnd();
glDisable(GL_LINE_STIPPLE);
glColor3f(0.5,0.2,0.2);
glBegin(GL_TRIANGLES);
glVertex2f(50,90);
glVertex2f(46,10);
glVertex2f(54,10);
glVertex2f(30,10);
glVertex2f(50,15);
glVertex2f(70,10);
glEnd();
glColor3f(0.0,1.0,0.0);
glEnable(GL_POLYGON_STIPPLE);
GLubyte rightpattern[]=
{
0xFF,0xF0,0xFF,0xFF,
0xFF,0x0F,0xFF,0x0F,
0xFF,0xFF,0xF0,0xFF,
0x0F,0xFF,0x0F,0xFF,
0xFF,0xFF,0xFF,0xF0,
0xFF,0x0F,0xFF,0x0F,
0xF0,0xFF,0xFF,0xFF,
0x0F,0xFF,0x0F,0xFF,
0xFF,0xF0,0xFF,0xFF,
0xFF,0x0F,0xFF,0x0F,
0xFF,0xFF,0xF0,0xFF,
0x0F,0xFF,0x0F,0xFF,
0xFF,0xFF,0xFF,0xF0,
0xFF,0x0F,0xFF,0x0F,
0xF0,0xFF,0xFF,0xFF,
0x0F,0xFF,0x0F,0xFF,
0xFF,0xF0,0xFF,0xFF,
0xFF,0x0F,0xFF,0x0F,
0xFF,0xFF,0xF0,0xFF,
0x0F,0xFF,0x0F,0xFF,
0xFF,0xFF,0xFF,0xF0,
0xFF,0x0F,0xFF,0x0F,
0xF0,0xFF,0xFF,0xFF,
0x0F,0xFF,0x0F,0xFF,
0xFF,0xF0,0xFF,0xFF,
0xFF,0x0F,0xFF,0x0F,
0xFF,0xFF,0xF0,0xFF,
0x0F,0xFF,0x0F,0xFF,
0xFF,0xFF,0xFF,0xF0,
0xFF,0x0F,0xFF,0x0F,
0xF0,0xFF,0xFF,0xFF,
0x0F,0xFF,0x0F,0xFF
};
glPolygonStipple(rightpattern);
glBegin(GL_TRIANGLES);
glVertex2f(50,70);
glVertex2f(60,70);
glVertex2f(50,90);
glVertex2f(50,50);
glVertex2f(70,50);
glVertex2f(50,80);
glVertex2f(50,30);
glVertex2f(80,30);
glVertex2f(50,70);
glEnd();
GLubyte leftpattern[]=
{
0xFF,0xFF,0x0F,0xFF,
0xF0,0xFF,0xF0,0xFF,
0xFF,0x0F,0xFF,0xFF,
0xFF,0xF0,0xFF,0xF0,
0x0F,0xFF,0xFF,0xFF,
0xF0,0xFF,0xF0,0xFF,
0xFF,0xFF,0xFF,0x0F,
0xFF,0xF0,0xFF,0xF0,
0xFF,0xFF,0x0F,0xFF,
0xF0,0xFF,0xF0,0xFF,
0xFF,0x0F,0xFF,0xFF,
0xFF,0xF0,0xFF,0xF0,
0x0F,0xFF,0xFF,0xFF,
0xF0,0xFF,0xF0,0xFF,
0xFF,0xFF,0xFF,0x0F,
0xFF,0xF0,0xFF,0xF0,
0xFF,0xFF,0x0F,0xFF,
0xF0,0xFF,0xF0,0xFF,
0xFF,0x0F,0xFF,0xFF,
0xFF,0xF0,0xFF,0xF0,
0x0F,0xFF,0xFF,0xFF,
0xF0,0xFF,0xF0,0xFF,
0xFF,0xFF,0xFF,0x0F,
0xFF,0xF0,0xFF,0xF0,
0xFF,0xFF,0x0F,0xFF,
0xF0,0xFF,0xF0,0xFF,
0xFF,0x0F,0xFF,0xFF,
0xFF,0xF0,0xFF,0xF0,
0x0F,0xFF,0xFF,0xFF,
0xF0,0xFF,0xF0,0xFF,
0xFF,0xFF,0xFF,0x0F,
0xFF,0xF0,0xFF,0xF0
};
glPolygonStipple(leftpattern);
glBegin(GL_TRIANGLES);
glVertex2f(40,70);
glVertex2f(50,70);
glVertex2f(50,90);
glVertex2f(30,50);
glVertex2f(50,50);
glVertex2f(50,80);
glVertex2f(20,30);
glVertex2f(50,30);
glVertex2f(50,70);
glEnd();
glDisable(GL_POLYGON_STIPPLE);
}
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
