[Bug 16243] [kernel modesetting] X crashed when run rendercheck
http://bugs.freedesktop.org/show_bug.cgi?id=16243 --- Comment #3 from Michel Dänzer [EMAIL PROTECTED] 2008-06-06 00:24:11 PST --- Created an attachment (id=16946) -- (http://bugs.freedesktop.org/attachment.cgi?id=16946) Possible fix Does this xserver patch fix it? -- 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. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 16243] [kernel modesetting] X crashed when run rendercheck
http://bugs.freedesktop.org/show_bug.cgi?id=16243 --- Comment #3 from Michel Dänzer [EMAIL PROTECTED] 2008-06-06 00:24:11 PST --- Created an attachment (id=16946) -- (http://bugs.freedesktop.org/attachment.cgi?id=16946) Possible fix Does this xserver patch fix it? --- Comment #4 from Michel Dänzer [EMAIL PROTECTED] 2008-06-06 00:24:46 PST --- Created an attachment (id=16947) -- (http://bugs.freedesktop.org/attachment.cgi?id=16947) Possible fix Does this xserver patch fix it? -- 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. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 16243] [kernel modesetting] X crashed when run rendercheck
http://bugs.freedesktop.org/show_bug.cgi?id=16243 Michel Dänzer [EMAIL PROTECTED] changed: What|Removed |Added Attachment #16946|0 |1 is obsolete|| --- Comment #5 from Michel Dänzer [EMAIL PROTECTED] 2008-06-06 00:26:44 PST --- (From update of attachment 16946) Whoops, forgot to clean up the patch on first attempt. -- 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. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Changes to 'libdrm-2_3-branch'
On Tue, 2008-06-03 at 21:12 -0700, Dave Airlie wrote: New branch 'libdrm-2_3-branch' available with the following commits: commit f892b4adf4021e82a7d4f2eb06256d6f4200ed15 Author: Dave Airlie [EMAIL PROTECTED] Date: Wed May 28 15:31:18 2008 +1000 remove include commit c28c1cf756979cebb67ffd64bc29ba371f1a9c4b Author: Dave Airlie [EMAIL PROTECTED] Date: Wed May 28 15:08:08 2008 +1000 libdrm: make a branch for libdrm which drops all the TTM apis. This will be the next release of libdrm as 2.3.1, Mesa needs to deal with this for 7.1. Dave, Does this mean Xserver 1.5 is going to ship without DRI2 as I've noted the --enable-ttm-api flag in mesa now ?? Alan. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: gallium (was Re: radeon r6xx DRM...)
On Fri, Jun 6, 2008 at 10:47 AM, Younes Manton [EMAIL PROTECTED] wrote: I think this would be a good time to speak up. My GSoC project involves writing a state tracker for XvMC, aside from the mesa state tracker I understand this is the only other public state tracker around. I don't have any complaints about the current gallium interface, but maybe someone could elaborate on what they have in mind as far as changes go, even if it's preliminary. One thing I've noticed about about winsys is that from my understanding, the state tracker is supposed to be OS and driver independent, The conclusion we're reaching is that while the bulk of the state tracker is OS independent (like current mesa state tracker is), there is a small part which will have some OS dependency (the part that will talk to DRI, GLX, WGL, etc.) but for XvMC and VAAPI the following situation exists: both are passed the drawable that will get rendered to late (after creation), and that forces me to pass the drawable to the winsys throught the state tracker as winsys-flush_frontbuffer(.., ..., drawable) when it seems that last param is intended for pipe_context-priv. Not sure what the intention behind the priv member is, so maybe this might be a bad idea when I target a HW driver instead of softpipe. We are also reaching the conclusion that the os-dependent part of the state tracker generally needs a special interface between the winsys. That At any rate it is impossible at the moment to guess how these changes will exactly turn out to be. So my suggestion is keep doing as you've been doing, and then this happens just make the similar move. I'm pretty sure that whatever works best for the existing state trackers should also works for your state tracker, but we can take a look at your code and ensure it does. As an aside, is there any preferred directory structure people would like to see for state trackers? Right now I'm using Nouveau's gallium but this isn't necessarily nouveau specific and may find a home elsewhere in the future. I'll be putting things in gallium/state_trackers/g3dvl (g3dvl being gallium3d video layer) with the following structure: src/ libXvMC/ tests/ libVAAPI/ tests/ vl/ tests/ winsys/ vl/ is where the state tracker stuff is, although since VAAPI and XvMC are somewhat similar (especially for mpeg2) I'm hoping to use the same state tracker. For that reason things don't look like they do in the mesa state tracker, I don't use XvMC types in the state tracker and don't necessarily map 1:1 with XvMC functions. Directory structure is not entirely consensual. But the general existing principles are: - standalone libraries (no gallium dependency) in src/ - gallium auxiliary libraries (gallium dependency) in src/gallium/auxiliary/ - in lack of better place, state trackers in src/gallium/state_trackers/ - pipe drivers in src/gallium/drivers/ - winsys in src/gallium/winsys/ So according to that above, your tree would be separated and go into - src/libXvMC/ - src/libVAAPI/ - src/gallium/state_trackers/vl - src/gallium/winsys/vl But I wouldn't worry too much about this. Especially if it would affect your productivity. We can always discuss this again if/when merging. (Another option is having state trackers out of the gallium source tree. We have done it, and it is nice because avoids merges back-n-forth, but still didn't wrote any howto instructions on this regard.) BTW, do you have your code available somewhere? Jose - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Changes to 'libdrm-2_3-branch'
Dave, Does this mean Xserver 1.5 is going to ship without DRI2 as I've noted the --enable-ttm-api flag in mesa now ?? I think it will have to not have DRI2 by default unless Kristian does the decoupling from the mm interface. 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://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Changes to 'libdrm-2_3-branch'
On Fri, 2008-06-06 at 11:23 +0100, Dave Airlie wrote: Dave, Does this mean Xserver 1.5 is going to ship without DRI2 as I've noted the --enable-ttm-api flag in mesa now ?? I think it will have to not have DRI2 by default unless Kristian does the decoupling from the mm interface. Ouch. It would be good to know Kristian's plans. Alan. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Small GEM core interface suggestion.
Hi! A small suggestion to the core GEM interface: Could you add a driver-private uint64_t member when a gem object is created? The primary purpose of this member would be to allow the implementation to choose the initial backing-store for a GEM object. This is for primarily for situations where a shmem object is not desirable. A caller that doesn't care (dri2) would simply pass zero. /Thomas - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: gallium (was Re: radeon r6xx DRM...)
On Fri, Jun 6, 2008 at 6:12 AM, José Fonseca [EMAIL PROTECTED] wrote: On Fri, Jun 6, 2008 at 10:47 AM, Younes Manton [EMAIL PROTECTED] wrote: As an aside, is there any preferred directory structure people would like to see for state trackers? Right now I'm using Nouveau's gallium but this isn't necessarily nouveau specific and may find a home elsewhere in the future. I'll be putting things in gallium/state_trackers/g3dvl (g3dvl being gallium3d video layer) with the following structure: src/ libXvMC/ tests/ libVAAPI/ tests/ vl/ tests/ winsys/ vl/ is where the state tracker stuff is, although since VAAPI and XvMC are somewhat similar (especially for mpeg2) I'm hoping to use the same state tracker. For that reason things don't look like they do in the mesa state tracker, I don't use XvMC types in the state tracker and don't necessarily map 1:1 with XvMC functions. Directory structure is not entirely consensual. But the general existing principles are: - standalone libraries (no gallium dependency) in src/ - gallium auxiliary libraries (gallium dependency) in src/gallium/auxiliary/ - in lack of better place, state trackers in src/gallium/state_trackers/ - pipe drivers in src/gallium/drivers/ - winsys in src/gallium/winsys/ So according to that above, your tree would be separated and go into - src/libXvMC/ - src/libVAAPI/ - src/gallium/state_trackers/vl - src/gallium/winsys/vl Assuming I had my own repo you mean, or in mesa? I was planning on using nouveau/mesa for the near future since Stephane is my mentor and nouveau is what I plan to move on to once things are working with softpipe, which would put libXvMC/ and libVAAPI/ alongside mesa/. Don't know how others would feel about non mesa libs at the top of the mesa tree, or if that's not a big deal. BTW, do you have your code available somewhere? Uploaded a copy to http://www.bitblit.org/gsoc/g3dvl/src/ and will soon commit current work to nouveau/mesa, http://www.bitblit.org/gsoc/g3dvl/ is where I keep general info and progress, etc. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Small GEM core interface suggestion.
On Fri, 2008-06-06 at 15:39 +0200, Thomas Hellström wrote: Hi! A small suggestion to the core GEM interface: Could you add a driver-private uint64_t member when a gem object is created? Please feel free to add a driver-specific ioctl to include whatever parameters you need. They're cheap, and it will let you customize it for your driver needs more easily than trying to add undefined data to an existing interface. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: gallium (was Re: radeon r6xx DRM...)
On Sat, Jun 7, 2008 at 12:07 AM, Younes Manton [EMAIL PROTECTED] wrote: On Fri, Jun 6, 2008 at 6:12 AM, José Fonseca [EMAIL PROTECTED] wrote: On Fri, Jun 6, 2008 at 10:47 AM, Younes Manton [EMAIL PROTECTED] wrote: As an aside, is there any preferred directory structure people would like to see for state trackers? Right now I'm using Nouveau's gallium but this isn't necessarily nouveau specific and may find a home elsewhere in the future. I'll be putting things in gallium/state_trackers/g3dvl (g3dvl being gallium3d video layer) with the following structure: src/ libXvMC/ tests/ libVAAPI/ tests/ vl/ tests/ winsys/ vl/ is where the state tracker stuff is, although since VAAPI and XvMC are somewhat similar (especially for mpeg2) I'm hoping to use the same state tracker. For that reason things don't look like they do in the mesa state tracker, I don't use XvMC types in the state tracker and don't necessarily map 1:1 with XvMC functions. Directory structure is not entirely consensual. But the general existing principles are: - standalone libraries (no gallium dependency) in src/ - gallium auxiliary libraries (gallium dependency) in src/gallium/auxiliary/ - in lack of better place, state trackers in src/gallium/state_trackers/ - pipe drivers in src/gallium/drivers/ - winsys in src/gallium/winsys/ So according to that above, your tree would be separated and go into - src/libXvMC/ - src/libVAAPI/ - src/gallium/state_trackers/vl - src/gallium/winsys/vl Assuming I had my own repo you mean, or in mesa? I was referring to mesa. I was planning on using nouveau/mesa for the near future since Stephane is my mentor and nouveau is what I plan to move on to once things are working with softpipe, which would put libXvMC/ and libVAAPI/ alongside mesa/. Don't know how others would feel about non mesa libs at the top of the mesa tree, or if that's not a big deal. BTW, do you have your code available somewhere? Uploaded a copy to http://www.bitblit.org/gsoc/g3dvl/src/ and will soon commit current work to nouveau/mesa, http://www.bitblit.org/gsoc/g3dvl/ is where I keep general info and progress, etc. It's looking good. Looking forward to see the final outcome. Jose - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
