New Content from Gallium3D Workshop Available
Three new topics are available from the Gallium3D Workshop: VMware SVGA Status (Keith Whitwell and Jose Fonseca) State Tracker Overview (Zack Rusin) OpenGL-ES State Tracker Status (Brian Paul) http://www.lunarg.com/wordpress/technologies/gallium-3d/gallium3d-online-developers-workshop/ -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Gallium3D Developers Workshop Now Online
Gallium3D Developers, The videos and slide decks from the Gallium3D Developers Workshop hosted by VMware on Nov 13th are now being posted online at: http://www.lunarg.com/wordpress/technologies/gallium-3d/gallium3d-online-developers-workshop/ More of the presentations will be posted to this page as they become available. Don't hesitate to contact me directly if you have any questions about the workshop material. Regards, Jens Owen -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Gallium3D Technical Session
Well...it will be a miracle if we can stream it live; but we are going to try. I apologize for the last minute notice, but this just came together today. If you or anyone in the community would like to join the event via WebEx, please send me an e-mail and I will forward an invite. We plan on making video available as well, so if you can't make it tomorrow...that should be okay, too. Regards, Jens On Oct 2, 2009, at 9:45 AM, RALOVICH, Kristóf wrote: On Fri, Oct 2, 2009 at 09:07, Joakim Sindholt b...@zhasha.com wrote: To at least give some feedback: I think this is a great initiative and I wish I could be there. You should do this in northern Europe more often. VMWare has offices in Sweden, right? ;) In any case, if you can get it on video it would be fantastic, and if you could live stream it, I would consider it a miracle. On Fri, 2009-10-02 at 06:22 -0600, Jens Owen wrote: Uros, Capturing this event on video is something we want to do. Thank you for your feedback. Regards, Jens On Oct 1, 2009, at 11:37 AM, Uros Nedic wrote: It'd be very nice if you could record session for people who are unable to attend this significant event. I'd be one of the first persons who would like to hear as much as possible about Gallium3D. Thanks, Uros Nedic --- Every kind of peaceful cooperation among men is primarily based on mutual trust and only secondarily on institutions such as courts of justice and police. - Albert Einstein (1879 - 1955) From: j...@stormpeakinnovations.com To: mesa3d-...@lists.sourceforge.net; dri- de...@lists.sourceforge.net Subject: Gallium3D Technical Session Date: Wed, 30 Sep 2009 07:58:32 -0600 The developers of Gallium3D are hosting a full day, in depth, technical session on Nov 13th at VMware's campus in Palo Alto, California. Please contact me directly to reserve your seat. Regards, Jens Owen -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel See all the ways you can stay connected to friends and family -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list mesa3d-...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list mesa3d-...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev I also believe having the video recording of the sessions is very useful. Please advertise the location of the videos so that people will find it easily. Thanks, Kristof -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Gallium3D Technical Session
Uros, Capturing this event on video is something we want to do. Thank you for your feedback. Regards, Jens On Oct 1, 2009, at 11:37 AM, Uros Nedic wrote: It'd be very nice if you could record session for people who are unable to attend this significant event. I'd be one of the first persons who would like to hear as much as possible about Gallium3D. Thanks, Uros Nedic --- Every kind of peaceful cooperation among men is primarily based on mutual trust and only secondarily on institutions such as courts of justice and police. - Albert Einstein (1879 - 1955) From: j...@stormpeakinnovations.com To: mesa3d-...@lists.sourceforge.net; dri- de...@lists.sourceforge.net Subject: Gallium3D Technical Session Date: Wed, 30 Sep 2009 07:58:32 -0600 The developers of Gallium3D are hosting a full day, in depth, technical session on Nov 13th at VMware's campus in Palo Alto, California. Please contact me directly to reserve your seat. Regards, Jens Owen -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel See all the ways you can stay connected to friends and family -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Gallium3D Technical Session
On Oct 2, 2009, at 9:45 AM, RALOVICH, Kristóf wrote: On Fri, Oct 2, 2009 at 09:07, Joakim Sindholt b...@zhasha.com wrote: To at least give some feedback: I think this is a great initiative and I wish I could be there. You should do this in northern Europe more often. VMWare has offices in Sweden, right? ;) In any case, if you can get it on video it would be fantastic, and if you could live stream it, I would consider it a miracle. On Fri, 2009-10-02 at 06:22 -0600, Jens Owen wrote: Uros, Capturing this event on video is something we want to do. Thank you for your feedback. Regards, Jens On Oct 1, 2009, at 11:37 AM, Uros Nedic wrote: It'd be very nice if you could record session for people who are unable to attend this significant event. I'd be one of the first persons who would like to hear as much as possible about Gallium3D. Thanks, Uros Nedic --- Every kind of peaceful cooperation among men is primarily based on mutual trust and only secondarily on institutions such as courts of justice and police. - Albert Einstein (1879 - 1955) From: j...@stormpeakinnovations.com To: mesa3d-...@lists.sourceforge.net; dri- de...@lists.sourceforge.net Subject: Gallium3D Technical Session Date: Wed, 30 Sep 2009 07:58:32 -0600 The developers of Gallium3D are hosting a full day, in depth, technical session on Nov 13th at VMware's campus in Palo Alto, California. Please contact me directly to reserve your seat. Regards, Jens Owen -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel See all the ways you can stay connected to friends and family -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list mesa3d-...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list mesa3d-...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev I also believe having the video recording of the sessions is very useful. Please advertise the location of the videos so that people will find it easily. Thank you for the feedback. I will look into what is available and follow up over the next two weeks. Regards, Jens -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Gallium3D Technical Session
The developers of Gallium3D are hosting a full day, in depth, technical session on Nov 13th at VMware's campus in Palo Alto, California. Please contact me directly to reserve your seat. Regards, Jens Owen -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Introduce DRI_VERSION?
Thomas Winischhofer wrote: Would you DRI guys mind adding a #define for DRI_VERSION_CURRENT in the same style as XORG_VERSION_CURRENT so that changes like the types from drmHandle - drm_handle_t can be handled smoothly with the C preprocessor for older versions? Point being: I would like to compile my DDX driver with both XFree86 and X.org as I don't have time to maintain two or more versions. Since the preprocessor can't check for typedefs (AFAIK...) a DRI_VERSION_CURRENT would come extremely handy. That shouldn't cause too much hassle... Thomas, Versioning has always been a tricky issue for DRI developers, and consequently keeping version numbering simple and up to date is important. I'd encourage you to considering using/enhancing the existing DRI and DRM versioning. For example, I'm wondering if the runtime version already built into DRM would help. It could be extended to use compile time #define's in places where we currently hard code constants, for example in drmGetLibVersion it looks like the minor version was just bumped to 2. The source for the linux version of this example be seen at: xc/programs/Xserver/hw/xfree86/drivers/os-support/linux/drm/xf86drm.c -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Introduce DRI_VERSION?
Thomas Winischhofer wrote: Jens Owen wrote: Thomas Winischhofer wrote: Would you DRI guys mind adding a #define for DRI_VERSION_CURRENT in the same style as XORG_VERSION_CURRENT so that changes like the types from drmHandle - drm_handle_t can be handled smoothly with the C preprocessor for older versions? Point being: I would like to compile my DDX driver with both XFree86 and X.org as I don't have time to maintain two or more versions. Since the preprocessor can't check for typedefs (AFAIK...) a DRI_VERSION_CURRENT would come extremely handy. That shouldn't cause too much hassle... Thomas, Versioning has always been a tricky issue for DRI developers, and consequently keeping version numbering simple and up to date is important. I'd encourage you to considering using/enhancing the existing DRI and DRM versioning. For example, I'm wondering if the runtime version already built into DRM would help. It could be extended to use compile time #define's in places where we currently hard code constants, for example in drmGetLibVersion it looks like the minor version was just bumped to 2. The source for the linux version of this example be seen at: xc/programs/Xserver/hw/xfree86/drivers/os-support/linux/drm/xf86drm.c Jens, thanks for your response. Just to avoid a misunderstanding: This version definition is not meant as an ABI/API/whatever number; I'd just need that for compilation reasons. If it is complicated for the DRI folks, why not keep such a version #definition in the x.org tree which is updated each time a merge from the DRI tree happens? For example, in xf86drm.h just add #define DRI_DATE 20040616 That would solve my particular problem quite easily. The name of the #define is entirely up to you... choose freely. The date format should be in a form suitable for comparison. That isn't too much work, is it? Thomas Thomas, Adding the define is easy, what's difficult is cleaning up these little hacks later without breaking binary compatability. As Keith W. suggested earlier this week, there is a good chance the X portion of the DRI development could end up in the X.org project. What would you set the DRI_DATE string to then? Perhaps it's time to bump the XORG_VERSION_CURRENT string to differentiate between the last release of X.org and the next. Would that help you? -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] new API/DRM/fb discsusion..
Jon, This issue of whether or not to use kgi goes all the way back to design decisions we made in 1998. Based on my recollection, I believe these were the top issues: 1) kgi was Linux specific. We needed a kernel level module that was more portable. 2) We wanted the bare minimum services in the kernel layer for efficient and fast graphics support, and felt as much of the driver code as possible should stay in user space. 3) GPL License. We needed a BSD style license to allow IHV's the option of a closed source driver. These are the issues I remember from 1998. I'm sure our requirements have evolved since then, but hopefully this short list will give a little insight into our thinking at that time. Jon Smirl wrote: Another request is that this work be compared to the kgi work so that we don't repeat the same mistakes. I wasn't around for that debate, can someone explain what was learned from attempt? I'll start reworking the proposal to include the feedback I have so far and get it ready for the next round. I suspect the next round on the DRI/FB lists will generate a lot more flames. The graphic driver issue is heating up because MS Longhorn is focusing on accelerated graphics as a major feature. --- Dave Airlie [EMAIL PROTECTED] wrote: why do I get the impression we are discussing kgi or at least the goals of kgi? without mentioning it ..is kgi a bad word around these parts? :-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] new API/DRM/fb discsusion..
John, You can think of me as Old School, and take my feedback in that context. My main reason for participating in this discussion is to give some historical perspective. Jon Smirl wrote: --- Jens Owen [EMAIL PROTECTED] wrote: 2) We wanted the bare minimum services in the kernel layer for efficient and fast graphics support, and felt as much of the driver code as possible should stay in user space. Linux kernel people are strongly in favor of changing Xfree to never touch the hardware except through device drivers. I have to agree with that, Xfree is doing a lot of things that are never going to work in a hotplug system. The only way to make hotplug work is for Xfree to tell the kernel what it is doing. Six years ago, most devices could not handle this type of restriction efficiently. Things have improved on the high end; but the low end devices, are still very similar to what we had back in the day. Even today, I would be very cautious of deploying an architecture where no devices can be touched from user space. This will really box many driver developers into a corner they can't get out of. Is that worth it for support of graphics pipeline hot plugging? If you would like to get a flavor for the issue I'm writing about, simply unmap the framebuffer from your Mesa-solo 3D driver and give it a go. I think you'll find many difficult issues crop up related to software fall backs and efficient readback pixel data. 3) GPL License. We needed a BSD style license to allow IHV's the option of a closed source driver. Top proposal right now is to merge FB and DRM. FB has the GPL license with too many developers so it probably can't be converted to BSD. There are many advatanges to merging FB/DRM. Top ones include SAK, secure attention key, kdbg support, OOPS while X is running, mode support for mesa-solo, etc I guess it really just depends on who your target user base is for your architecture. I'm a strong supporter of open source, especially at the infrastructure level; but I have a pragmatic view of IHV's and their need (or perceived need) to withold sources at the module level. If you're not targetting an all inclusive base of IHV's and kernels, then life is much easier for you, and you don't have to worry about the licensing issue. What is the state of the FB equivalent on BSD? It's certainly further along than it was in 1998, but I'm not the right person to ask. If you don't make any progress on their kernel lists, contact me directly, and I can put you in touch with my BSD contacts. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] new API/DRM/fb discsusion..
Jon Smirl wrote: Framebuffer access follows the rules; kernel calls are used to map it into user space. The major violations in X are in PCI bus and graphics chip probing. If mmapping is okay, then we're still able to touch hardware from user space drivers. I'm fine with that. I don't see any problem with requiring probing to be handled by a kernel space driver, especially since this isn't done a performance critical times. BTW, the mesa-solo radeon driver does not map the framebuffer from the driver or user space. The original radeon Mesa Subset driver that Keith W. wrote didn't have any software fallbacks. If you re-enable a full Mesa driver, I think you'll find it very challenging to support all the necessary software fallbacks without a memory map of the framebuffer...but luckly it doesn't sound like memory mapping the device is a problem. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
Ian Romanick wrote: That aside, I think we should be able to remove xf86drmCompat.c now. Unless I'm mistaken, libdrm.a is statically linked into the *_dri.so. If that's the case, and all of the client-side drivers have been updated to not use the functions in xf86drmCompat.c, why do we need it? I looked at the mga driver with nm, and it doesn't reference any of the drmMGA* symbols. If you have access to an XF4.2 system are older, you should check for drmMGA*, drmR128*, drmRadeon*, drmI810* and drmI830* in the 2D drivers...it's these 2D routines we're providing compatability for with the XFree86 server side libdrm.a module that's distributed with our binary packages. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
Ian Romanick wrote: Michel Dnzer wrote: On Wed, 2003-10-22 at 20:38, Ian Romanick wrote: Eric Anholt wrote: Would we ever be setting pointers through a setparam interface? I think making it an int makes it relatively clear that it's a 32-bit value, though it might be valuable to use [u]intXX_t for the drm (and dri screen private?) sruct definitions everywhere to make things clear. Also, yes, alpha, amd64, ia64, and sparc64 all have 32-bit ints and 64-bit longs and pointers. Isn't the FB_LOCATION a pointer? :) Admittedly it will always be in the first 4GB today, but when PCI Express comes, I don't think that will always be the case. I'd hate to have to invent a new ioctl to support PCI Express when that day comes. That won't be necessary in any case; once there is a chip (which we support...) with a 64 bit address space, just add a parameter to set the high 32 bits. :) I don't mind either way, but I don't feel like figuring out which type to use for a 64 bit value and dealing with the build problems it might cause right now. I added Keith's proposed struct with int64_t as the value, and I added '#include inttypes.h' to xf86drmCompat.c. Everything compiled fine. As a side note, at what time will we be able to deprecate xf86drmCompat? Are we intending to maintain the old client-side drivers forever? I seem to remember there being problems with the really old client-side drivers and the newer kernel modules anyway. We can definitely remove the xf86drmCompat layer for XFree86 5.0. I believe it's well understood that major version changes will break existing binary interfaces. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Question: Intel 855GM
Ian Romanick wrote: Jacek Blizinski wrote: Which package do I use for the new 855GM, or is it not yet supported? Thanks a lot! You *should* be able to use the i830 driver. AFAIK, the i830M/i845G/i845GE/i855GM/i865G all use the same graphics core, so the 3D driver should just work. Ian is correct. If you're interested in tracking the DRI project and helping with the latest development version of the drivers, you're at the right place. If you simply want the stable driver, you'll find that in any distribution using XFree86 4.3. You can also find a downloadable version of the stable drivers for XFree86 4.2 at: http://support.intel.com/support/graphics/linux/graphics.htm -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Observations about dynamic extension registration
Felix Kühling wrote: On Tue, 29 Jul 2003 13:58:58 -0700 Ian Romanick [EMAIL PROTECTED] wrote: Felix Kühling wrote: Hi, as I'm going to clean up vsync related stuff on the config-0-0-1-branch I read the code for dynamic glx extension registration in xc/lib/GL/dri/dri_glx.c and xc/lib/GL/glx/glxextensions.[ch]. I stumbled over this comment in front of __glXRegisterExtensions: ** In older versions of libGL (prior to October 2002) we _always_ ** called this function during libGL start-up. Now, we only call ** it from glXGetProcAddress() as a last resort. However, __glXRegisterExtensions is still called in driCreateDisplay. Hmm, on the other hand I found this comment in radeon_screen.c in front of __driRegisterExtensions: /* This function is called by libGL.so as soon as libGL.so is loaded. * This is where we'd register new extension functions with the dispatcher. Do the __driRegisterExtensions functions in the drivers rely on being called during initialisation? In fact I believe it could be dangerous if __driRegisterExtensions was called later as it may override extensions disabled in e.g. CreateContext due to lacking hardware support. Fortunately __glXRegisterExtensions returns immediately if it is called the second or later time. Maybe it's just a matter of updating a few comments after all. I'm inclined to believe that the comments in dri_glx.c are just wrong. __glXRegisterExtensions has to be called before a call to glXGetProcAddress. The app can query that string via glXQueryExtensionsString long before calling glXGetProcAddress. In fact, it may never call glXGetProcAddress. I'm sure glxinfo doesn't. :) So this does influence which extensions are listed in the extension string, contradicting what Keith wrote? In that case I have one more question. How can this work with multi-head configurations where you can have multiple different cards (different screens) on one display. Then each driver will add or readd extensions. But they should never disable any extensions, right? You don't want drivers to disable each others extensions, do you? Consequently __glXDisableExtension should never be called (or better not even exist ;-). And the only way to disable an extension is to not enable it. Thus, if you don't want to enable the swap-interval extensions if the hardware can't support them (no IRQs) then you have to know whether IRQs work at the time __driRegisterExtensions is called. Is that possible? Just my thoughts. I hope I'm wrong ;-) Felix, Keep in mind that regular X11 extension (which the DRI itself uses) are on a per server basis and apply to all displays on the server. Consequently for heads that don't support direct rendering we still advertise the DRI extension, but upon a second level query a 3D client side driver would find that extension disabled. OpenGL extension need something different as they may only be supported for specific visual configurations...but I can't remember how this is handled off the top of my head. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: sched_yield()
Ian Romanick wrote: The real difference comes at the unlock. When a thread wants to release the futex, it increments the variable. If the value is greater than zero, the thread happily continues on. If the value is zero or negative, the thread calls into the kernel to wake-up the next waiting thread. It is this last part that differentiates the futex from the existing DRI lock. It is also this last part that gives the behavior we were trying to achieve by calling sched_yield after releasing the DRI lock. I wonder if we didn't throw out the baby with the bathwater when we reorganized the kernel side DMA buffer management. To be more specific, we do call the kernel unlock routine when there is lock contention, but it's not clear which compile time code paths are used by Linux in the supporting DRM code responsible for waking up the contending thread. Check out DRM(unlock) in xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_drv.h This is precisely where Linux specific support for wake-up the next waiting thread should reside. I see calls to wake_up_interruptible(dev-lock.lock_queue), but they are ifdef'ed by __HAVE_KERNEL_CTX_SWITCH. I'm not certain which compile time paths we're using in this code these days...but somebody is waking up the clients that are waiting for the lock and this is precisely where it should be happening. When it does happen here, this behavior would appear to be almost identical to the behavior of the futex you describe. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Brian Paul wrote: Denis Oliver Kropp wrote: What do you mean by drivers not based on Mesa? ATI, for example, has Linux OpenGL drivers that use the DRI but don't use Mesa. It seems to be common misconception that the DRI was designed around Mesa, but it's not. Right, and the PowerVR driver as well. If we can account for DRI interfaces being used in the Mesa tree but outside of the mesa subdirectory proper, then it should be easier for IHV's to follow our changes possibly allowing for their OpenGL drivers to more easily plug into the various DRI window system bindings (GLX, mini-GLX, DirectFB futures). -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Brian Paul wrote: Denis Oliver Kropp wrote: Quoting Brian Paul ([EMAIL PROTECTED]): src/ mesa/ glapi/ glapi*.[ch]- dispatcher files APIspec file gl*.py- Python API scripts main/- core Mesa sources attrib.c context.c enable.c ... CPU detection code transform/- was tnl t_*.[ch] X86/3Dnow code math/- math/vector routines m_*.[ch] swrast/- s/w rasterization s_*.[ch] mmx_blend.S swsetup/- was swrast_setup ss_*.[ch] arraycache/- vertex array stuff ac_*.[ch] drivers/ common/- reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/- OSMesa driver swfbdev/- software fbdev driver radeon/- DRI/fbdev driver radeon-es/- subset radeon fbdev driver r200/ ... mga/- DRI/fbdev driver windows/ beos/ ggi/ glide/- was FX driver dos/ dri/- es dri code Oops, dri/ is indented one tab too far, and probably not named very well. It should be probably be src/dri-es/ since it implements DRI facilities for the embedded subset. I think the DRI drivers should be moved into the dri/ directory which itself should be in the drivers/ directory, because drivers/ contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc. The dri/ directory will contain windowing system independent code as a public interface to the DRI drivers. The DRI drivers won't be used by applications directly. My suggestion: drivers/ common/- reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/- OSMesa driver swfbdev/- software fbdev driver windows/ beos/ ggi/ glide/- was FX driver dos/ dri/- dri driver interface common/- reusable driver code radeon/- DRI/fbdev driver r200/- DRI/fbdev driver mga/- DRI/fbdev driver Where do you propose that the files currently in Mesa/src/dri/ (such as dri_glx.c, glxclient.h, etc) belong? src/dri-es/ is the place I was planning on. I'm trying to keep the tree fairly shallow (one of the things that intimidates people about the XFree86/DRI tree is its size and depth) so I'm not sure we need drivers/dri/ yet. Also, I want to try to keep all source files as leaves in the tree. That is, a directory foo/ won't contain both files and subdirs; just one or the other. Brian, One thing that would help me understand how this new tree structure (and how having the Mesa DRI driver in the tree) will work would be to understand where the resulting binary files would end up *after* a build. Specifically, can a radeon DRI driver module be built from this standalone tree? Where will it reside? Where will an embedded Mesa radeon driver module reside? and finally, future window system bindings, for example a DirectFB Mesa driver module. Where would that live? -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Jose Fonseca wrote: CVSROOT:/cvsroot/dri Module name:xc Repository: xc/xc/lib/GL/mesa/src/drv/r200/ Changes by: [EMAIL PROTECTED] 03/05/31 15:42:18 Log message: Add a newline at end of file - believe it or not, this was the culprit for all the build problems lately... Modified files: xc/xc/lib/GL/mesa/src/drv/r200/: Imakefile.inc Revision ChangesPath 1.5 +1 -1 xc/xc/lib/GL/mesa/src/drv/r200/Imakefile.inc After doing a little digging in the DRI and XFree86 CVS trees, it looks like this was originally fixed 6 months ago in the XFree86 repository and then synced 5 months ago into the mesa-4-0-4-branch of the DRI repository, but it never made it to the DRI trunk. Ugh. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-users] Problem with latest trunk and i810?
My apologies for sending my first reply to dri-devel. This is really a dri-users configuration issue. However, there is one aspect to this posting that may be very relevant to dri-devel. Jens Owen wrote: I remember a recent change to support a 32 bit depth buffer and I wonder if that's on by default. Looking the the back buffer allocation code in i810_dri.c, it doesn't look like 32bit back buffers are supported. Ian, is my memory failing me, or were you looking at this a few months ago? -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-users] Problem with latest trunk and i810?
R Deepak wrote: Hi, I use RedHat 9 with a custom compiled 2.4.21-rc4 and the latest DRI (checked out two hours back :). But DIR doesn't seem to work with my i810 chipset. I'm attaching my 'dmesg' and 'XFree86.0.log'. Any help would be nice. :) (logs compressed because of the 40kb limit!) glxinfo says direct rendering is disabled. These are the relevant portions from my XF86Config file. -- Section Module Load dbe Load extmod Load fbdevhw Load glx Load record Load freetype Load type1 Load dri EndSection VideoRam16384 Either increase this value or... EndSection Section Screen Identifier Screen0 Device Videocard0 MonitorMonitor0 DefaultDepth 16 SubSection Display Depth 16 Modes1280x1024 1024x768 800x600 640x480 drop the 1280x1024 mode. There simply isn't enough memory to support the DRI running in this mode. EndSubSection EndSection Section DRI Group0 Mode 0666 EndSection --- Thanks Did this configuration work with the default X Server installed with Red Hat 9? I remember a recent change to support a 32 bit depth buffer and I wonder if that's on by default. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] Problem with latest trunk and i810?
Keith Whitwell wrote: Jens Owen wrote: Keith Whitwell wrote: Jens Owen wrote: My apologies for sending my first reply to dri-devel. This is really a dri-users configuration issue. However, there is one aspect to this posting that may be very relevant to dri-devel. Jens Owen wrote: I remember a recent change to support a 32 bit depth buffer and I wonder if that's on by default. Looking the the back buffer allocation code in i810_dri.c, it doesn't look like 32bit back buffers are supported. The i810 only supports 3d at 16bpp color depths. Right, my mistake in the description. Does the current i810 driver support 32bit *depth* buffering? I don't think so. You right. I found the old e-mail from Ian on depth buffer changes and it was to support 16-bit depth on the R128 driver... Sorry for the noise. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] Problem with latest trunk and i810?
Keith Whitwell wrote: Jens Owen wrote: My apologies for sending my first reply to dri-devel. This is really a dri-users configuration issue. However, there is one aspect to this posting that may be very relevant to dri-devel. Jens Owen wrote: I remember a recent change to support a 32 bit depth buffer and I wonder if that's on by default. Looking the the back buffer allocation code in i810_dri.c, it doesn't look like 32bit back buffers are supported. The i810 only supports 3d at 16bpp color depths. Right, my mistake in the description. Does the current i810 driver support 32bit *depth* buffering? -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [forum] Notes from a teleconference held 2003-3-27
Michel, You're bring in issues that effect more than just the X development community here, so I'm copying the DRI and Mesa developers. Michel Dänzer wrote: On Don, 2003-04-03 at 22:03, Alan Cox wrote: From the DRI people's point of view, it leads to more work as we'd want our drivers to work with both trees -- but that's pretty much life, and we'll have to do what we can to minimize the effects on us. Perhaps a test of Keith's theory is that DRI should be able to be -part- of not just working with his tree. I think we should first discuss (more) the pros and cons of folding the DRI tree into other trees. I do find the potential benefits (for merges in particular) compelling, but there's e.g. the danger of making it harder to get it integrated with other components like e.g. DirectFB or other OpenGL implementations. Folding the X specific work into an X project makes alot of sense from a technical perspective. My biggest concern would be losing developer momentum by removing this work from a developer friendly project like the DRI. The Mesa specific parts and the supporting kernel driver parts could be pushed into the Mesa tree (this has already been done for the embedded branch). Currently, the Mesa project is very focused on the API and the full software stack that supports that API in a wide range of windowing environments while the DRI project is focused on hardware acceleration in the X environment. It's technically feasible to transition the development of the Mesa hardware drivers (currently done in DRI) to the Mesa project. However, we still need to worry about developer momentum as two focuses would now be in the Mesa project (API and 3D HW). I think the following block diagram illustrates the key areas of 3D development focus, and the transition that's being suggested: Now: Mesa Tree - DRI Tree - XFree86 Tree - API Focus - 3D HW Focus - Complete Window System Focus - X/3D Integration Possible Future: Mesa Tree -+-- XFree86 Tree - API Focus|- X/3D Integration - 3D HW Focus |- Complete Window System Focus | +-- Alternate X Tree |- Duplicate X/3D Integration |- Possibly more 3D developer | friendly, who knows? | +-- FBDev Subset |- FBDev/3D Integration |- Embedded Focus | +-- DirectFB |- DFB/3D Integration V Other Window Systems: DirectFB, WGL, AGL and new ones that haven't been invented, yet. I would like to hear the concerns from the developers that support the API, 3D HW and X/3D Integration before considering any kind of transition. IMHO, supporting the community of open source developers that make 3D happen is much more important than control over any one project. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Server-side GLX / DRI issues
Suzy Deffeyes wrote: Jens- I agree with you, supporting HW accelerated indirect rending would be a good thing. Take a look at the DRI high level design doc: http://dri.sourceforge.net/doc/design_high_level.html In section 4.3, Indirect Rendering, there's a section on Multi-rendering in a single address space. Caution, newbie question! Indirect rendering doesn't currently get its own thread, does it? No. It does affect interactivity, but I'm curious how much of the benefit you'd gain would be from making it direct, and how much of the benefit would be from moving GLX requests to a second thread. Without threads, there is a definite tradeoff between X interactivity and 3D performance/latency. My leaning years ago when we designed the DRI was towards doing a daemon process and taking the 3D hit in favor of portability, but threading supporting in most modern OS's has improved considerably since then. I would definitely lean towards using a local thread in the server today. [KHLS94] Mark J. Kilgard, Simon Hui, Allen A Leinwand, and Dave Spalding. X Server Multi-rendering for OpenGL and PEX. 8th Annual X Technical Conference, Boston, Mass., January 25, 1994. Available from http://reality.sgi.com/opengl/multirender/multirender.html. I sent Kilgard a note asking him if he knows of an archived copy. It's a damn shame reality.sgi.com went down before it got into the google cache. Thanks Karl and Alan for the pointers to the cached copies. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 4.3.0 merge
Keith Whitwell wrote: Alan Hourihane wrote: I'm going to start the 4.3.0 merge. Be prepared for breakage. I'll post another followup when I'm finished. Thanks for doing this, Alan. Definitely. Thanks, Alan. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Final new code in texmem-0-0-1 branch (take 2)
Ian, Looks like you've been busy. Here are some comments from the 10,000' level. Keep in mind I haven't looked at your branch, yet. So feel free to point me at the code if my comments are way off base. Ian Romanick wrote: Most of the changes that were in my previous Final new code in texmem-0-0-1 branch patch are in this patch as well. Some of the code, such as the Radeon code-gen updates, has already been committed. http://www.mail-archive.com/[EMAIL PROTECTED]/msg09490.html In addition, a few fixes were made to the device-independent vertical-retrace code. Michal Daenzer pointed out a couple problems with the code, and I've made some work-arounds. The biggest problem was that the user-mode API has to use 64-bit counters for buffer-swaps and retraces, but the kernel ioctls only provide 32-bit counters. I put a small has in vblank.c that should work around most of the problems here. The bulk of the changes were in the GLX support in libGL.so. As mentioned with my previous patch, the current reporting mechanism is wrong. The extensions returned by glXGetClientString(dpy,GLX_EXTENSIONS) is the set of extensions supported by libGL.so. It has *nothing* to do with the server or and direct rendering driver. Keep in mind the spec says string describing some aspect of the client library. So, I believe it's correct to not include server information. You might be able to make a case for including direct rendering driver information, since that's technically part of the client library, but the extensions would need to only list extensions that were supported by all heads, since there is no screen parameter to this entry point. Given that limitation, I think an application developer would use the glXQueryExtensionsString to query the screen specific extensions, and only rely on glXGetClientString to figure out which libGL.so they were dealing with. The extensions returned by glXQueryExtensionsString is the intersection of the set of extensions supported by the client (libGL.so) and the server, plus any client-side extensions (such as GLX_ARB_get_proc_address). I have extended this to include any extensions that are direct rendering only that are supported by the direct rendering driver. This includes extensions like GLX_NV_vertex_array_range. How would you cope with Applications that query a capability, but force indirect rendering? Wouldn't they be misguided into thinking GLX_NV_vertex_array_range was present in the server, when it's probably not available? I believe the DRI is the first project where HW accellerated direct rendering was implemented, but indirect rendering fell back to a software renderer. If we had HW accellerated indirect rendering, I believe these Query functions would work the way they were intended...i.e. the GLX_NV_vertex_array_range would work on an indirect rendering context and should then be advertised by glXQueryExtensionsString. In glxextensions.c I track 5 bits for each extension. Each bit represents one of the following: 1. Is the extension supported by libGL.so? 2. Is the extension supported by the server? 3. Is the extension supported by the direct rendering driver? 4. Is the extension client-side only? 5. Is the extension for direct rendering only? By looking at the state of those five bits, the function __glXGetUsableExtensions can determine which extensions should be exposed by glXQueryExtensionString. If you can figure out a way to add direct rendering only extensions to glXQueryExtensionString without breaking existing applications (something that's hard to qualify) then that sounds like a nice improvement. However, I wouldn't say the existing reporting mechanism is wrong. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] patch for function naming consistency
Philip Brown wrote: On Wed, Mar 12, 2003 at 10:21:17PM +0100, Michel Dänzer wrote: On Mit, 2003-03-12 at 19:15, Philip Brown wrote: I just noticed that in drivers/ati, every single function related to DRI initialization,etc. is named RADEONDRIXxxxYyyy ... except RADEONPreInitDRI() Here's a patch to fix that, and R128PreInitDRI() This change doesn't seem obvious to me; the RADEONDRIxxx() functions are in radeon_dri.c and directly related to the DRI, whereas RADEONPreInitDRI() (along with other RADEONPreInitxxx() functions) is in radeon_driver.c Maybe it belongs in radeon_dri.c, then? Coincidence of current location, should not be a reason for avoiding logical naming and grouping. If you like, I'll submit patches for doing the move AND rename. and mainly processes the DRI related driver options. Consistency is a Good Thing. It is nice and easy to do grep RADEONDRI tags to get a list of all DRI-related functions for radeon. [The fact that you can get more complicated with grep RADEON | grep DRI should not excuse the lack of consistency in naming] So RADEONPreInitDRI() doesnt actually do any rendering; So what. It is still DRI related. I agree w/ Ian. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] patch for function naming consistency
Jens Owen wrote: Philip Brown wrote: On Wed, Mar 12, 2003 at 10:21:17PM +0100, Michel Dänzer wrote: On Mit, 2003-03-12 at 19:15, Philip Brown wrote: I just noticed that in drivers/ati, every single function related to DRI initialization,etc. is named RADEONDRIXxxxYyyy ... except RADEONPreInitDRI() Here's a patch to fix that, and R128PreInitDRI() This change doesn't seem obvious to me; the RADEONDRIxxx() functions are in radeon_dri.c and directly related to the DRI, whereas RADEONPreInitDRI() (along with other RADEONPreInitxxx() functions) is in radeon_driver.c Maybe it belongs in radeon_dri.c, then? Coincidence of current location, should not be a reason for avoiding logical naming and grouping. If you like, I'll submit patches for doing the move AND rename. and mainly processes the DRI related driver options. Consistency is a Good Thing. It is nice and easy to do grep RADEONDRI tags to get a list of all DRI-related functions for radeon. [The fact that you can get more complicated with grep RADEON | grep DRI should not excuse the lack of consistency in naming] So RADEONPreInitDRI() doesnt actually do any rendering; So what. It is still DRI related. I agree w/ Ian. I mean Michael... -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon Depth buffer
Felix Kühling wrote: On Fri, 07 Mar 2003 08:30:56 + Keith Whitwell [EMAIL PROTECTED] wrote: Jonathan Thambidurai wrote: I was looking at the source for the radeon driver and noticed that the depth buffer is always set to 32 bits if a 24 bpp color depth is selected. Is this a hardware limitation, or might it be possible to change it to 16 bpp? It's possible to do this with a small amount of coding. That coding would touch several parts of the tree, but not actually be too difficult, except in terms of getting to know the very large source tree we have to deal with. Try downloading the CVS see if you still want to play. This is yet another thing that could become a configuration option with the new configuration scheme. Besides radeon and r200, would this also be possible with other drivers? Currently the depth buffer is a static allocation made at X Server init time by the 2D driver. If the new configuration scheme is not available to the 2D driver, it may be better to use the XF86Config file. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: future of DRI? - why no one plays with Glide3.
Allen Akin wrote: Microsoft bears a lot of the burden for D3D by collecting and maintaining the common code (as well as nontechnical stuff like patent licensing and sublicensing). SGI didn't do that for OpenGL in the early days, and by the time it understood the problem, most hardware vendors had already invested in independent driver code bases for OpenGL. So today there's not as much sharing in the OpenGL world as there might have been. Some improvements are possible, though, and are being discussed in the ARB. Allen, This is encouraging to hear. Have you heard any rumblings about where the common code base would come from? -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] drm-filp-0-1-branch and radeon
Linus Torvalds wrote: On Sun, 2 Mar 2003, Linus Torvalds wrote: The _second_ DRI-enabled X startup caused problems, even if I had done multiple non-DRI X sessions in between. This is what makes me think that the DRI kernel modules keep some history around that they shouldn't. And maybe the problem is hidden if you actually unload and re-load the modules (is that what most people do?) Ok, I went in and looked for suspicious behaviour, and I found some. Look at AGP and MTRR behaviour: both of them are initialized by drm_init() at module load time. Both of them are _de-initialized_ by the DRM(takedown)() code, and never re-initialized by the DRM(setup)() code. So an example of badness would be: - load DRM modules (in my case as part of kernel bootup, since they are compiled in): - initialize MTRR and AGP mappings - run X with DRI. - Everything is happy. - exit DRI X - we are the last close case for DRI, so DRM(release)() calls DRM(takedown)(), which frees AGP and MTRR - restart non-DRI X - nothing happens - kill non-DRI X - nothing happens - run X with DRI again - oops. We now have neither AGP nor MTRR's set up, even though the code looks like it is assuming it. Yeah, maybe I'm missing where somebody else re-initializes AGP and MTRR, but my point is that these things do not seem to nest correctly. That mtrr_del() in particular seems to be wrong, and I do indeed get a mtrr: MTRR 2 not used when shutting down X normally. Comments? I haven't really gone through the whole path of what happens at open()/release() time, and these are really nothing more than that looks suspicious, maybe somebody who knows the code better than I can take a better look at it. Linus, Sounds like you may be on to something. Server recycles are common with display managers. An easy way to test (and debug) this scenario would be to bring up a raw X server (no window manager, display manager or clients), then run glxinfo, xdpyinfo or start and stop any X client (this will cause the server to recycle when they exit...if they are the only client), and then you should be in a state where you can try running gears or some other simple 3D application on an X server that has recycled. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] C++ Framework Concern
Jose, I've been on the road for the last few days, so I haven't had a chance to express my concern for porting the DRI to C++. Please take these concerns with a grain of salt as I am definitely in the old fuddy duddy class (as Keith calls it) in that I'm not fluent in C++. Concern #1: Acceptance into XFree86, etc. Creating dependencies on C++ compilers could be a big issue for some of the major projects that utilize our code. Concern #2: As a driver writer, I prefer looking at C and thinking in terms of the machine transactions that are likely to take place based on that code. C++ code tends to hide that level of detail for me and I don't feel like I've got a strong grip on the various machine transactions when using it. Concern #3: Readability by the active contributors. I'm not the only old fuddy duddy in this group of developers. How much readability time do you figure the young C++ whipper snappers will save by investing in this transition to C++? Thanks for your consideration of these issues and thanks for all your excellent contributions to the DRI project. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] module release method, threads, pids
Charl P. Botha wrote: If by server-recycle you mean stopping and starting X, I haven't seen any lockups with that. An X Server recycle is something the X Server does automatically when the last client disconnects. It basically goes thrue shutdown and cleanup of everything, then reinitializes everything, all within the original process. Typically shutdown and cleanup bugs showup when trying to do an X Server recycle. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Dual-head
Sven Luther wrote: On Mon, Feb 24, 2003 at 07:58:55AM -0700, Jens Owen wrote: A short cut to this whole thing would be to work on getting a second head supported on a single X11 screen. Then 3D comes for free: http://www.tungstengraphics.com/dri/Simple_Xinerama_DH.txt This solution provides Xinerama functionality without actually using the Xinerama wrapper. Mmm, i am curious about this, how does it get handled in the XFree86 configuration file. Possibly by adding a secondary monitor line to the screens section. Also, i guess this would facilitate the memory management in dual head configurations. Yes, the driver would need to handle how the memory is shared. In general, dual head configuration is pretty poor in the current X server, at least in the documented part. There is no way from specifying mirrored or zoomed window output, or to be able to change the configuration dynamically, but this would probably not be achievable without an extension, or maybe incorporated with the RandR stuff. If you want things to be dynamic, you will need to stay away from X's notion of a second X11 screen. That's is static and persistant by definition. However, a secondary monitor to the primary screen could be as dynamic as you want to make it. I think that matrox did something such in their proprietary drivers. There are other proprietary drivers that have also done similar functionality. However, I haven't seen anything in open source. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Streaming video through glTexSubImage2D
Morten Hustveit wrote: Currently, the performance when streaming video through glTexSubImage2D is very low. In my test program and with mplayer, I get approximately 8 fps in 720x576 on my Radeon 7500 with texmem-branch from a couple of weeks ago. glDrawPixels is equally slow. I assume glTexSubImage2D is supposed to be able to process realtime video, since it handles extensions like EXT_422_pixels (for 4:2:2 Y'CbCr) and EXT_interlace. Using OpenGL for streaming video is useful for creating nonlinear video editing applications (I think Apple's Shake use OpenGL), because you will be able to preview many of the most common effects in realtime. Is there any work in progress to make texture sub-image uploading faster? Which changes need to be done? Morten, The R200 driver supports an AGP allocator, but that's for the Radeon 8500 and 9000. You would need to port the allocator (APPLE_client_storage) to the Radeon driver if you wanted to use it on the Radeon 7500. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] The next round of texture memory management...
completes), the back-buffer can be swapped-out. There may be other situations where can-swap is cleared, but that's all I could think of. Similar rules would exist for vertex buffers (for ARB_vertex_array_object, EXT_compiled_vertex_array, optimized display lists, etc.). Only a single bit per block is needed in the SAREA. That bit is the union of the bits for each object that is part of that block. This union must be calculated by the user-space driver. This presents a possible problem of user-space clients failing to update the can-swap bits for some reason (process hung on blocking IO call?). The current implementation avoids this problem by forcing all bocks to be swappable at all times. At this point I'm left with a few questions. 1. In a scheme like this, how could processes be forced to update the can-swap bits on blocks that they own? 2. What is the best way for processes to be notified of events that could cause can-swap bits to change (i.e., rendering completion, asynchronous buffer-swap completion, etc.)? Signals from the kernel? Polling age variables? 3. If some sort of signal based notification is used, could it be used to implement NV_fence and / or APPLE_fence? 4. How could the memory manager handle objects that span multiple blocks? In other words, could the memory manager be made to prefer to swap-out blocks that wholly contain all of the objects that overlap the block? Are there other useful metrics? Prefer to swap-out blocks that are half full over blocks that are completely full? 5. What other things I have I missed that might prevent this system from working? :) --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel I hope I'm bringing in some food for thought...and not unnecesarily complicating an already difficult and important DRI improvement. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] The next round of texture memory management...
Dieter Nützel wrote: Am Freitag, 17. Januar 2003 18:37 schrieb Jens Owen: Ian, I had a chance to read your ideas on memory managment last night. First off, I'd like to thank you for doing a very good job of collecting requirements and then seperating out your ideas for implementation. This level of discipline really helps me understand where you are constrained by requirements vs. where you are exploring solutions. As you address the very complex issue of virtualizing graphics subsystem resources, I'm going to attempt to influence your thinking to include the concept of a 3D desktop compositing engine. You've make references to capabilities that Apple is supporting, yet to me the ultimate challenge that the Apple desktop paradigm provides today is the 3D and composoting effects they are doing with Genie bottle window iconfication and multilevel window transparancy. Starting to address these capabilities in open source will put additional requirements on the resource management requirements. Does this all fits with a video editing system? Something like integration of the GATOS project (video in/out/DVI/TV) that we can base video cutting systems upon Linux/*BSD? Not directly. The video streaming capabilities would tax the used use of rendering contexts and backbuffers similar to an active 3D application. I'm referring more to how the desktop's compositing engine would generate special effects while still supporting the load of active 3D, 2D and video rendering contexts. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] CyberBlade/i1 drivers (Was: Freeing...)
Ian Romanick wrote: Keith Whitwell wrote: José Fonseca wrote: I've been following this thread very closely because I just order a VIA Mini-ITX motherboard (see http://www.viavpsd.com/products/epia_mini_itx_spec.jsp ) for making a MP3/VCD/DVD TvOut media player + router + ... Eventually I also want to turn it into a Linux video game console! ;-) And guess what? It comes with a onboard Trident CyberBlade i1. It seems that Trident has no Linux 3D drivers, so there is no fish to give, but they happily supply a fishing stick, as the chip specification is freely available from http://www.viavpsd.com/products/Manual/DS8601A182.pdf . Ack. That looks like a pretty difficult document to work from -- a challenge of the mach64 order to say the least... Seems to be a g400/r128/tnt/i810 type chip, though. It's hard to tell from the document, but there really did seem to be a lot of detail missing. I would put it at the low end of that group. No stencil buffer, 256x256 max texture, single texture unit (!), no support for MODULATE, DECAL, ADD, or COMBINE (unless some of these are possible w/the undocumented ROP3 code). I noticed in the document that it supports DirectX, but there is NO mention of OpenGL. Hmm... I noticed on page 4 (pdf file page 10) under General Graphics Capabilities, the last item refers to an OpenGL ICD API. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] linux, Xfree86-4.2.99.3 cvs, i810, drm and drmAddMap()
Clemens Kirchgatterer wrote: i have allready asked on the Xfree86 mailing list, but got no reponse. i don't know what's the reason for this, most likely that were the wrong place to ask, so i try again here. Clemens, I'll respond to this on the dri-users list... -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa SIGSEGV's due to broken common_x86_asm.S
Linus Torvalds wrote: Actually, you should just remove it entirely, since the LEAVE will do the right thing (which is why it worked AT ALL originally That answers the big question in my mind...why it worked originally. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Michel Dänzer wrote: On Die, 2003-01-07 at 23:00, Jens Owen wrote: Michel Daenzer wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/ Changes by: mdaenzer@sc8-pr-cvs1. 03/01/07 13:21:52 Log message: Use shadowfb instead of mi shadow to fix 2D corruption when page flipping is enabled. Wow, you found the source of the corruption? That's worthy of a posting to dri-devel... True, I posted about it on December 14th and asked for testing, sadly I didn't receive any reports. This doesn't help mixed OpenGL and X11 rendering in the same window, but that supposedly doesn't work with the traditional method of drawing to the back buffer and then copying it over the front buffer either, so enable page flipping by default. I'm a little confused here. By traditional method are you referring to not using page flipping? Yes. What doesn't work in that method? The X server always renders to the front buffer, so when you mix OpenGL and X11 rendering, the former clobbers the latter when rendering to the back buffer. What clobbering is allowed can be inferred from the GLX specification. If you overlook DBE for a second, I believe we are meeting the requirements of the spec, so I wouldn't say we're broken. Now, if you want to include DBE, then the current traditional implementation is technically broken. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
magenta wrote: On Tue, Jan 07, 2003 at 03:00:10PM -0700, Jens Owen wrote: Michel Daenzer wrote: This doesn't help mixed OpenGL and X11 rendering in the same window, but that supposedly doesn't work with the traditional method of drawing to the back buffer and then copying it over the front buffer either, so enable page flipping by default. I'm a little confused here. By traditional method are you referring to not using page flipping? What doesn't work in that method? I thought that the glX spec said that mixing X11 and OpenGL within a single drawable wasn't guaranteed anyway, and only gave hints about things that might or might not work on certain implementations. AFAIK the rendering is guaranteed. GLX Version 1.3, Section 2.2, Paragraphs 3 4 gives a good description of how the X and OpenGL rendering pipelines are expected to interact: Issuing OpenGL commands may cause the X buffer to be flushed, In particular, calling glFlush when indirect rendering is occuring, will flush both the X and OpenGL rendering streams. Some state is shared between the OpenGL and X. The pixel values in the X frame buffer are shared. The X double buffer extension (DBE) has a definition for which buffer is currently the displayed buffer. This information is shared with GLX. The state of which buffer is displayed tracks in both extensions, independent of which extension initiates a buffer swap. There is a description of the synchronization expectations in Section 2.7, paragraph 5: Synchronization is in the hands of the client. If can be maintained with moderate cost with the judicious use of the glFinish, glXWaitGL, glXWaitX, and XSync commands. OpenGL and X rendering can be done in parallel as long as the client does not preclude it with explicit synchronization calls. This is true even when the rendering is being done by the X server. and again in Section 3.3.10, paragraph 3: All GLX rendering context share the same notion of which are front buffers and which are back buffers for a given drawable. This notion is also shared with the X double buffer extension (DBE). This last section really tweaked my memory. I had forgotten, but indirect rendering in our traditional implementation isn't compliant. For indirect contexts, we're not sharing the contents of the back buffer with direct rendering contexts. There's some real interesting work that still needs to be done for indirect rendering, DBE and page flipping. If anyone's interested in improving this stuff, just speak up. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Michel Daenzer wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/ Changes by: mdaenzer@sc8-pr-cvs1. 03/01/07 13:21:52 Log message: Use shadowfb instead of mi shadow to fix 2D corruption when page flipping is enabled. Wow, you found the source of the corruption? That's worthy of a posting to dri-devel... This doesn't help mixed OpenGL and X11 rendering in the same window, but that supposedly doesn't work with the traditional method of drawing to the back buffer and then copying it over the front buffer either, so enable page flipping by default. I'm a little confused here. By traditional method are you referring to not using page flipping? What doesn't work in that method? Modified files: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: radeon_dri.c radeon_driver.c Revision ChangesPath 1.41 +23 -29xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c 1.53 +9 -9 xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] What happened to www.mesa3d.org?
Andreas Stenglein wrote: What happend to the mesa3d website? www.mesa3d.org doesnt work as expected since a few days: It only shows a text mesa3d.org is a parked domain Looks like a problem with the domain name. You can still find that site at: http://mesa3d.sourceforge.net/ -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon PCI patch
C. Brewer wrote: I would like to beg for the inclusion of #define PCIGART_ENABLED in radeon_dri.c, radeon_cp.c and the applied ring buffer tweak to the XFree86 CVS. The pci changes shouldnt affect any other system and do allow rather stable 3D accelerated environment, with a properly configured XF86Config-4 file. I have been running these as such for a while,and I proposed to get them in through regular XFree86, and was told they were forwarded to you guys. That ws at the end of 4.1.0. I am submitting directly to you now in hopes of faster response. The attached ring buffer tweak is not entirely my own, the bulk of it being released publically on the Internet by [EMAIL PROTECTED], whom I have been unable to contact for some time. All other minor tweaking is my own,and the whole patch should be GPL. Thank you for your consideration. Chuck, I just want to point out the XFree86 only accepts BSD style licensing, not GPL. The code from the DRI project get's merged into XFree86 (we're a subproject, if you will), so we need to follow that licensing as well. See http://www.xfree86.org/legal/licence.html for more details. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.NET email is sponsored by: The Best Geek Holiday Gifts! Time is running out! Thinkgeek.com has the coolest gifts for your favorite geek. Let your fingers do the typing. Visit Now. T H I N K G E E K . C O Mhttp://www.thinkgeek.com/sf/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Joining development
Rudnev A.D. wrote: Hello! My name if Rudnev Alexey, I have been developing Linux OpenGL-based (and also writing my own graphics engines,independent of Mesa) applications for quite a long time .I also have some expirience in developing(adapting existing to my configuration) video drivers for Linux platform. So I think I could be useful for futher development of DRI and Mesa. Please,Send me conditions of joining development or some other place, where I could find such information. Rundev A.D. ,[EMAIL PROTECTED] Rudnev, No conditions. The sources are available from Source Forge. Post any patches you make to this list. There is lots of good developer documentation at http://dri.sf.net -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-devel][PATCH] Segfault in DRI Xserver extension
(xXF86DRIGetDrawableInfoReq);
REQUEST_SIZE_MATCH(xXF86DRIGetDrawableInfoReq);
+if (stuff-screen = screenInfo.numScreens) {
+ client-errorValue = stuff-screen;
+ return BadValue;
+}
+
rep.type = X_Reply;
rep.length = 0;
rep.sequenceNumber = client-sequence;
@@ -483,6 +527,11 @@
REQUEST(xXF86DRIGetDeviceInfoReq);
REQUEST_SIZE_MATCH(xXF86DRIGetDeviceInfoReq);
+if (stuff-screen = screenInfo.numScreens) {
+ client-errorValue = stuff-screen;
+ return BadValue;
+}
+
rep.type = X_Reply;
rep.length = 0;
rep.sequenceNumber = client-sequence;
@@ -528,6 +577,11 @@
DrawablePtr pDrawable;
REQUEST_SIZE_MATCH(xXF86DRIOpenFullScreenReq);
+if (stuff-screen = screenInfo.numScreens) {
+ client-errorValue = stuff-screen;
+ return BadValue;
+}
+
rep.type = X_Reply;
rep.length = 0;
rep.sequenceNumber = client-sequence;
@@ -554,6 +608,11 @@
DrawablePtr pDrawable;
REQUEST_SIZE_MATCH(xXF86DRICloseFullScreenReq);
+if (stuff-screen = screenInfo.numScreens) {
+ client-errorValue = stuff-screen;
+ return BadValue;
+}
+
rep.type = X_Reply;
rep.length = 0;
rep.sequenceNumber = client-sequence;
Index: glx/glxcmds.c
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/GL/glx/glxcmds.c,v
retrieving revision 1.8
diff -u -r1.8 glxcmds.c
--- glx/glxcmds.c 25 Nov 2002 19:58:38 - 1.8
+++ glx/glxcmds.c 13 Dec 2002 15:52:01 -
@@ -761,7 +761,7 @@
int i, p;
screen = req-screen;
-if (screen screenInfo.numScreens) {
+if (screen = screenInfo.numScreens) {
/* The client library must send a valid screen number. */
client-errorValue = screen;
return BadValue;
@@ -1466,7 +1466,7 @@
ClientPtr client = cl-client;
xGLXQueryExtensionsStringReq *req = (xGLXQueryExtensionsStringReq *) pc;
xGLXQueryExtensionsStringReply reply;
-GLint screen;
+GLuint screen;
size_t n, length;
const char *ptr;
char *buf;
@@ -1475,7 +1475,7 @@
/*
** Check if screen exists.
*/
-if ((screen 0) || (screen = screenInfo.numScreens)) {
+if (screen = screenInfo.numScreens) {
client-errorValue = screen;
return BadValue;
}
@@ -1511,7 +1511,7 @@
xGLXQueryServerStringReq *req = (xGLXQueryServerStringReq *) pc;
xGLXQueryServerStringReply reply;
int name;
-GLint screen;
+GLuint screen;
size_t n, length;
const char *ptr;
char *buf;
@@ -1521,7 +1521,7 @@
/*
** Check if screen exists.
*/
-if ((screen 0) || (screen = screenInfo.numScreens)) {
+if (screen = screenInfo.numScreens) {
client-errorValue = screen;
return BadValue;
}
--
/\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
Dave Jones wrote: On Thu, Dec 12, 2002 at 12:49:37PM +, Keith Whitwell wrote: It seems that changes get inserted to the drm code in the kernel from time to time. Is the expectation that we monitor the kernel drm and periodically merge (or otherwise) those random or worthy changes back to this repository? I personally don't want to subscribe to lkml or attempt to fully monitory the traffic there. There should at the least be one person on the DRI team who looks at each new kernel releases with a Are there any changes here I need to push into DRI CVS mindset. This job doesn't need you to even monitor l-k, just keep an eye on each release Linus does. Dave, I expect the changes Linus makes will run with the kernels he releases, but my question is, will they work with older kernels, too? The DRI cvs sources need to support those as well? Supporting DRM under stable and development XFree86 as well as stable and development Linux Kernel seems like a large job when your consider compatability with older releases (of XFree86 and kernel), the number of drivers, and the code being shared with other operating systems. My point is this may require more of an effort than simply merging Linus' changes back into the DRI tree. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRI Resume - quo vadis?
Keith Whitwell wrote: Charl P. Botha wrote: Dear list, In spite of some issues with binary snapshots, the DRI resume patches seem to work well. They have been available and in use on several different kinds of laptops for a few months now. What are the chances of this patch being accepted into the DRI CVS repository? How should I go about getting these small changes off my hands and eventually into XFree86? As I recall the X people on this list had some specific issues with the patches (David? Alan?) Resolving these would be the first step. Or am I lagging behind actual events? I have no concerns about the implications on the DRI with Charl's approach. He's kept everything in the driver at the mode init level, which I think is good. I'll defer any review of the actual Radeon specifics to the Radeon maintainers. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Smoother graphics with 16bpp on radeon
magenta wrote: I basically see three camps in this discussion: 1. Users should be able to configure default behavior using configuration files (which would be selected based on argv[0] or similar) 2. Users should be able to configure default behavior using environment variables (which would be configured on a per-application basis using wrapper scripts or a launcher program or similar) 3. Users should not be able to configure default behavior; applications should specify all behavior explicitly if it matters, and expose this as an application-level configuration option to the user Personally, I'm torn between camps 1 and 3. I'm squarely in camp 3 based on Allen's rationale and his experience. Actually, I just thought of a solution which could possibly satisfy all three camps: have a libGL wrapper library (loaded via LD_PRELOAD) which overrides functionality as needed. Want to force FSAA to be enabled? Put it into glXCreateContext(). Want to force GL_RGB8 when the application chooses GL_RGB? Do it in glTexImage(). Hey, if you want to force GL_RGB4 when the application chooses GL_RGB8, you could do that too! Basically, I see no reason to put this configuration into the drivers themselves, as it could easily be done using an LD_PRELOADed library. The Chromium project has been doing this for a while. At SigGraph, I saw a demo of quake3 running in wire frame mode using this type of trick. Let's strive to keep as much unneeded complexity as we can out of the drivers. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by: Microsoft Visual Studio.NET comprehensive development tool, built to increase your productivity. Try a free online hosted session at: http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] full box lockup.
Keith Whitwell wrote: Michel Dänzer wrote: On Son, 2002-11-24 at 18:39, Andreas Stenglein wrote: Nov 23 20:18:13 buche kernel: [drm:radeon_irq_emit] *ERROR* radeon_irq_emit called without lock held Nov 23 20:18:13 buche kernel: [drm:radeon_lock_take] *ERROR* 6 holds heavyweight lock A friend of mine reported something like this (haven't seen it myself). For him, killing the DRI client(s) resumes normal operation. Can you confirm that? If so, that's not an actual lockup. I still can't really imagine what a 'heavyweight lock' is, can one of the traditional developers explain? It's really just the lock. The locking process is two stage, with a cmpxcg in userspace which can handle the trivial case (if the same context wants to get a lock and it was the last context to hold it) without kernel intervention. If that fails, the process has to do an ioctl to get the lock. This is where this message comes from -- maybe saying that '6' already has the lock it is asking for. Michel, If you want more technical information on the lock, check out: http://dri.sourceforge.net/doc/hardware_locking_low_level.html -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Merge of mesa-41 branch to trunk
Brian Paul wrote: Adam K Kirchhoff wrote: On Fri, 22 Nov 2002, Brian Paul wrote: My plan is to merge the mesa-41 branch into the DRI trunk this weekend. Let me know if there are any concerns. I would be worried that whatever is causing the server from the mesa-41 branch to crash under FreeBSD is going to make it way into the trunk. I'll do another merge from the trunk. After the last one, I did a complete diff of the two branches and IIRC there were no server-side differences, except in the server-side indirect GLX code. Adam, Have you checked to see if the problem exists in the trunk already? -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Merge of mesa-41 branch to trunk
Adam K Kirchhoff wrote: On Fri, 22 Nov 2002, Jens Owen wrote: Brian Paul wrote: Adam K Kirchhoff wrote: On Fri, 22 Nov 2002, Brian Paul wrote: My plan is to merge the mesa-41 branch into the DRI trunk this weekend. Let me know if there are any concerns. I would be worried that whatever is causing the server from the mesa-41 branch to crash under FreeBSD is going to make it way into the trunk. I'll do another merge from the trunk. After the last one, I did a complete diff of the two branches and IIRC there were no server-side differences, except in the server-side indirect GLX code. Adam, Have you checked to see if the problem exists in the trunk already? It definately does not (at least, not as of earlier this week). Do any of the developer's running FreeBSD have time to isolate this problem (or at least confirm it)? We don't want to hold up the Mesa 5.0 merge as the XFree86 feature freeze is coming very soon. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
Ian Romanick wrote: Hmmm...would adding it as a hard-coded extension make life easier for IHVs that want to provide binary-only drivers but not necessarilly their own libGL.so? I'm thinking ATI and PowerVR... Oddly enough, ATI provides a libGL.so replacement in their package. I'm not sure why they do this. The Linux user base would really benefit from driver packages that didn't interfere with each other. Replacing a critical library like libGL.so has a major impact on the other drivers loaded on the system. I'm not just picking on ATI, here...NVidia does this, too. PowerVR is a good example of a well thought out install package. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: mesa-4-1-branch)
Brian Paul wrote: Keith Whitwell wrote: Brian Paul wrote: CVSROOT:/cvsroot/dri Module name:xc Repository:xc/xc/lib/GL/mesa/src/drv/tdfx/ Changes by:brianp@usw-pr-cvs1.02/11/15 16:13:59 Log message: Modified functions in __DriverAPIRec to remove unneeded Display * parameters, etc. Generally try to reduce number of X dependencies within the driver code. Added driMajor/Minor/Patch fields to __DRIscreenPrivateRec and call XF86DRIQueryVersion in dri_util.c instead of in all the drivers. Lots of #include clean-ups. Brian, Are there any forward/backward compatibility issues raised by this change? We currently don't distribute libGL.so in the snapshots. However, I'm not averse to doing so, as long as new libGL.so's can be made to work with old driver.so's. I have some concerns w/ doing this...see my earlier posting re:ATI and NVidia... There are no compatibility issues. All the changes I made were to the code that's compiled into each DRI driver, at a level below the libGL/ driver interface layer. Great. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding GLX extensions?
Ian Romanick wrote: Can I get a quick run-down of the GLX code so that I can know where to begin? Most of the server side support for GLX proper is in: xc/programs/Xserver/GL/glx This provides the main extension for indirect rendering and interfaces with the ../dri and another glue piece ../mesa/src/X, I think, to complete the server side support. The client side support is in: xc/lib/GL/glx AFAIK, Brian uses lot's of magic and a couple of Newt's tails along with this module to build libGL.so Once I get started, I should be able to figure out the details submit some additions to the developer's FAQ. :) That would be great. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] doh...
Keith Whitwell wrote: Missed the meeting last night. Can anyone summarize or post a log? Keith, I got their late, but the report was that it was slow the whole time. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Blank screen when switching VT
Christophe Saout wrote: Any ideas? Problem with the kernel? Problem with a buggy XFree module lying around? Problem with me? Another problem? Does this still happen when the DRI is disabled? -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Xpert]Savage and nVidia DRI drivers
José Fonseca wrote: Actually my main interest is the learning experience of making a DRI driver from ground up - experience which I plan to share by writing a thorough HOWTO describing the steps and explaining the working of a driver from the high-level structure to the low-level implementation details. (You already can see the very first writings on http://dri.sf.net/doc/howto/) Great! -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200-20021030 CRT not detected on Powercolor EvilMaster II (8500 QL)
Jeroen, If you're having problems w/ 2D functionality (stuff that runs even when the DRI is disabled), then you should post to [EMAIL PROTECTED] However, the stuff in your PS section is useful information. Thanks! Jeroen Roodhart wrote: Hello, I have a problem getting XFree86 to accept that my monitor is connected to the VGA-socket instead of the DVI-socket. Somehow it thinks the primary display interface is the DVI socket and there is no convincing it with any XF86config option I've found (CRTScreen, PanelDisplay ). The one thing that helps is to edit $SRCROOT/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c and force MT_CTR to be set, bypassing the DDC detection code. Im a bit pressed for time, but if I can provide you with any information to maybe help you fix this, I'll do my best to help. Please ask if needed. (The code works for me now, so if I'm the obly one having this problem, please ignore ;) ) The r200-20021030 snapshot has the problem as well (As you'd expect) My configuration is: Linux Redhat 8.0 with stock kernel (thus gcc 3.2 based distro) DRI-CVS tree updated as of 10 minutes ago and patched to force MT_CRT Gigabyte A7VRXP mobo AMD Athlon 2100+ CPU 512 Mb memory Powercolor Evil Master II (Recognised as Radeon 8500 QL -- 64M) 2 x Maxtor 60G ATA133 Disks (running linux raid0) Soundblaster Audigy Platinum PS. glxgears gives me rates between 1500 and 2000 frames/s -- nice? But there is a strange jerking effect in the display of the gears (meaning it turns dor a second, then hampers/halts, then turns again). I'm seeing this when using xine to play DVD as well. QuakeIII is fine though (between 30 and 90 FPS). I can't really diagnose what is causing this becasue my system is new, and just recently installed so It could be another subsystem (sound, raid0_ that is causing this, but if I had to bet... Anyway, thanx for a great job, With kind regards, Jeroen -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Stable Driver Branch
There was a discussion today in the weekly DRI developer's meeting regarding the cross purposes of pushing the latest DRI infrastructure work vs. providing a stable, easy to use set of drivers for our broader base of BETA testers. The conclusions reached in this discussion were: 1) The DRI infrastructure work is the most important for the long term success of our project. We should not let any effort to address a stable driver branch or release interfere with our primary focus of bringing new functionality to the DRI. 2) Point 1 being said, it's unrealistic to think that we can ignore the fact that there is a huge time lag between when new driver functionality is available and when it starts to be supported in most distributions. If we can find a way to release stable driver updates on perhaps an infrequent basis (quarterly), that would address this huge time lag and enable many more users access to the current DRI drivers they need. 3) Keith agreed to be the unwilling maintainer of the stable driver branch until another experienced DRI developer volunteers. He will only be doing minor updates for patches that fix high visibility problems he feels should be addressed. If you're interested in maintaining the stable driver branch, send e-mail to dri-devel. 4) Reide volunteered to build, package and release the stable driver branch when it's ready. We probably won't need nightly builds, so the scripts can be kicked off by hand once the build process is ready and we have any source updates. Jose volunteered to help Reide getting the binary driver releases going. Please reply if anybody has additions or corrections to this discussion. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Triple Buffering
Keith, I've heard you and others talk about triple buffering a few times, and I'm wondering if you can fill me in on a few details. Is the primary motivation for a 3rd buffer to aliviate delays associated with vertical refresh? Using a page swapping method, I would guess the pointers for front, back and display buffer would look like: Before SwapBuffers: Buffer 1 Buffer 2 Buffer 3 ^^ Front Back Display After SwapBuffers but Before Vertical Retrace: Buffer 1 Buffer 2 Buffer 3 ^^^ Display FrontBack At Vertical Retrace: Buffer 1 Buffer 2 Buffer 3 ^^ Front Back Display I'm wondering what happens when the frame rate exceeds the refresh rate. Also, would X need to render to all 3 buffers? Would X's notion of front and back (For DBE) still work at a semantic level? I know DBE doesn't work properly with the DRI right now, but we haven't done anything to prevent it from being implemented. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Triple Buffering
Keith, Ian, Thanks for educating me on the issues. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xpert]Re: [Dri-devel] r200 and libxaa
Mark Vojkovich wrote: On 21 Oct 2002, Michel Dänzer wrote: On Mon, 2002-10-21 at 02:05, Jens Owen wrote: José Fonseca wrote: On Wed, Oct 16, 2002 at 04:52:59PM +1000, Simon Bland wrote: I've seen ppl mention the libxaa.a from Fonseca seems to fix the problem with the screen blanking. Thing is I can't seem to find this libxaa.. Can anyone point me in the right direction for this? And can anyone confirm that this does seem to fix the screen blanking problem with the Radeon 8500. Initially I hosted on my website because there was no certain that it would help. But now that I know it does I've moved it to http://dri.sf.net/snapshots/extras/libxaa.a.bz2 and wrote a README.Sig11 on http://dri.sf.net/snapshots/ . Can anyone on Xpert comment on XAA binary incompatability? Does this just affect Forward compatability, i.e. older X environments with newer binary drivers? The problem appeared when I merged radeon driver fixes by Kevin E. Martin from XFree86 CVS to DRI CVS. They involved adding new fields to the XaaInfoRec struct; the fact that they were added in the middle of that struct caused the DRI binary snapshots, which were built against the new version of that struct but ran with an XAA module built against the old version, to crash and burn. I moved the new fields to the end of the struct, bumped the minor XAA version and added code to the radeon driver to only access the new fields if it's dealing with the new XAA. That worked as expected when I tested it here by copying libxaa.a from my Debian 4.2 installation into my DRI tree, which makes me suspect that the remaining problem with the snapshots is due to toolchain incompatibilities or something along those lines. I don't know why people do this. This change just broke NVIDIA's and ATI's binary drivers too. Any changes to structures that are referenced by drivers need to go at the end of the structures. Mark, I'd like to see driver level binary compatability continue, too. I'm not certain if Michael's changes have made it back to XFree86's CVS. I posted to this thread (and copied Xpert) because I read some posts to dri-devel that implied Michel's fixes weren't enough to restore driver compatability (old drivers, new XFree86 core and modules). If I'm mistaken, please let us know. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] driver feature table
Brian Paul wrote: I've whipped up an HTML table which summarizes the features of the DRI drivers. Thanks Brian. Here are some more corrections: 1) Driver headings on top row: It looks like the driver names were based on some common names we throw around when talking about these drivers. Unfortunately, these names can be very confusing as times, so I've tried to generate consistent names using the IHV's name followed by the directory name for the 3D driver. Here is what I got: ATI r200, ATI radeon, ATI r128, Intel i810, Intel i830, Matrox mga, 3Dfx Voodoo3, 3Dfx Voodoo5. Note, I didn't follow my convention for the 3Dfx drivers in that a single source directory generates two different drivers with very different features in your matrix. I think we'll find as time goes on that it's not unusual for a single driver to generate very different results in the matrix depending on the capabilities for the specific hardware. I know there are a few for the G200 vs G400 hardware for example. 2) Cards Row. This is the hardest row to keep up to date. ATI r200 Column: I realize the 8700 has the R200 chipset, but has anybody successfully testing the 8700 or 8900 with the R200 open source driver? ATI r128 Column: Was support for Pro cards ever completed? I know the initial driver did not have it. Intel I830 Column: i845 is also supported, this can be changed to i830/i845 chipsets. Matrox mga Column: Millenium and Mystique are not supported by this driver. G200 is listed twice. 3) Kernel Module Row, ATI R200 Column: There is no r200.o kernel module. This should be radeon.o 4) Added 2D Driver Module Row. Row inverted here for the sake of e-mail: DRI Driver 2D Driver Name ATI r200 radeon_drv.o ATI radeon radeon_drv.o ATI r128 r128_drv.o Intel i810 i810_drv.o Intel i830 i810_drv.o Matrox mga mga_drv.o 3Dfx Voodoo3 tdfx_drv.o 3Dfx Voodoo5 tdfx_drv.o -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] driver feature table
Brian Paul wrote: If anyone else wants to make changes, do so, and post a new table.html file. Okay. Here's a new file. It contains the following fixes: 1) i830 chipset uses i830 kernel module. 2) Michael's PowerPC support row. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado Summary of DRI driver features: ATI r200 ATI Radeon ATI r128 Intel i810/815 Intel i830/845 Matrox G200/400 3dfx Voodoo3 3dfx Voodoo5 Cards Radeon 8500, 8700 Radeon 7x00 Rage Fury/Pro/Magnum, XPERT 2000, XPERT 128, XPERT 99, All-in-Wonder 128 i810/815 chipsets i830/845 chipsets Millenium G200, G400, G450, Mystique G200 Voodoo3, Banshee, Velocity 100/200 Voodoo4 4500, Voodoo5 5500 Intel/AMD x86 YES (AGP only) YES (AGP only) YES YES YES YES YES YES DEC Alpha YES YES YES no no no YES YES PowerPC no YES YES no no no no no Driver Name r200_dri.so radeon_dri.so r128_dri.so i810_dri.so i830_dri.so mga_dri.so tdfx_dri.so tdfx_dri.so Kernel Module radeon.o radeon.o r128.o i810.o i830.o mga.o tdfx.o tdfx.o 2D XFree86 Driver radeon_drv.o radeon_drv.o r128_drv.o i810_drv.o i810_drv.o mga_drv.o tdfx_drv.o tdfx_drv.o Hardware Stencil YES (@32bpp) YES (@32bpp) YES (@32bpp) no YES (@32bpp) YES (@32bpp) no YES (@32bpp) Hardware Alpha Channel YES (@32bpp) YES (@32bpp) no no YES (@32bpp) YES (@32bpp) no YES (@32bpp) Hardware TCL YES YES no no no no no no ARB_multitexture (units) YES (2?) YES (2?) YES (2) YES (2) YES (2) YES (G200:1, G400:2) YES (2) YES (2) ARB_texture_cube_map no no no no no no no no ARB/EXT_texture_env_add YES YES YES YES YES YES YES YES ARB/EXT_texture_env_dot3 YES YES no no no no no no ARB/EXT_texture_env_combine YES YES no no YES no no YES EXT_blend_color no no no no YES no no no EXT_blend_function_separate no no no no YES no no no EXT_blend_logic_op YES YES no no no no no no EXT_blend_min_max YES no no no YES no no no EXT_blend_subtract YES YES no no YES no no no EXT_fog_coord YES YES no no YES no no no EXT_paletted_texture no no no no no no YES YES EXT_secondary_color YES YES no no YES no no no EXT_shared_texture_palette no no no no no no no no EXT_stencil_wrap YES no no YES YES no no YES EXT_texture_filter_anisotropic YES YES no no no no no no EXT_texture_lod_bias YES YES no YES YES no YES YES IBM_texture_mirrored_repeat no YES no no no no no no MESA_pack_invert YES no no no no no no no MESA_texture_ycbcr YES no no no no no no no NV_texture_rectangle YES no no no no no no no SGIS_generate_mipmap no YES no no no YES no no GLX_NV_vertex_array_range YES no no no no no no no OpenGL Extensions enabled in all DRI drivers: GL_ARB_transpose_matrix GL_EXT_abgr GL_EXT_bgra GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_packed_pixels GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_texture3D (in software) GL_EXT_texture_object GL_EXT_vertex_array GL_IBM_rasterpos_clip GL_MESA_window_pos GL_NV_texgen_reflection
Re: [Dri-devel] R128(0): [drm] drmSetBusid failed (7, PCI:2:0:0),Permission denied
Ilia Zadorozhko wrote: Hi people, Help me please getting DRI to work. I've installed latest (rage128-20021008-linux.i386.tar.bz2) versions of DRI. Function drmSetBusid requires some kind of permission, which I can't understand. Launching X from root gives the same results. Please, help ! Some info and logs: Kernel 2.4.19 - lsmod - Module Size Used by r128 88132 0 agpgart31840 1 ---ls -l /dev/dri/--- crw-rw-rw-1 root root 226, 0 ïËÔ 7 17:14 card0 ---XF86Config-4 Section DRI Mode0666 EndSection XFree86.0.log--- XFree86 Version 4.2.0 / X Window System . (--) PCI:*(2:0:0) ATI Rage 128 Pro PF rev 0, Mem @ 0xf000/26, 0xff9fc000/14, I/O @ 0xd800/8, BIOS @ 0xff9c/17 ... (==) R128(0): Write-combining range (0xf000,0x200) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmGetBusid returned '' (II) R128(0): [drm] drmSetBusid failed (7, PCI:2:0:0), Permission denied (EE) R128(0): [dri] DRIScreenInit failed. Disabling DRI. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel Ilia, Maybe it's a kernel module problem. Make sure your AGPGART module is loaded into the kernel before the r128 module. If that doesn't work, post the output from dmesg. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] install.sh bug
José Fonseca wrote: Next snapshots (which are now fully automated again) have this already. Notify if you run into problems. Jose, or anybody interested in creating an 830/845 package? TG has released many bug fixes for this chipset, but we've been too busy to update the package script. The 2D driver is shared with the i810, however a unique DRM driver and 3D driver is required. All aspects of 830/845 support should be building and running from the trunk, we're only missing the packaging for binary snapshots. TG is not dependent on a package, but I have seen a few posts from DRI and Xpert users who would have liked binary snapshots. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] ATI Radeon VE QY (AGP) new drivers (personal) problems
Keith Whitwell wrote: Felix Kühling wrote: On 03 Oct 2002 11:01:57 +0200 Michel Dänzer [EMAIL PROTECTED] wrote: On Don, 2002-10-03 at 01:52, thork wrote: about the aperture thing, he told me those 8Mb where from system memory not from the video card memory, I found this thing in the log: (--) RADEON(0): VideoRAM: 65536 kByte (64-bit DDR SDRAM) and ofcourse the other lines next: (II) RADEON(0): Using 8 MB AGP aperture but when I load the agpgart modules it says: Sep 30 14:18:32 thork kernel: agpgart: AGP aperture is 64M @ 0xf800 This is the upper limit for the AGP aperture size the DRI can use. the 480FPS on glxgear where using 24bits of color, now the CVS thing is giving me 500FPS ... but come on! ITS A RADEON 7000! Yes, exactly. ;) No hardware TCL (well, actually some VEs do seem to have that, you can try the RADEON_TCL_FORCE_ENABLE environment variable if you're desperate for more fps, but be warned that it will lock up if it doesn't work with your chip). Also, try to enable page flipping if you haven't already. That's funny: without TCL glxgears is slightly faster on my Radeon 7500! Just the CPU usage is higher. With TCL I get 864 FPS (about 14% CPU usage), without TCL it's 872 FPS (about 22% CPU). That should make some sense if you think about it. Because you aren't using 100% cpu, you know that in some way the card is the limiting factor. By turning off tcl you are unloading work from the card, thus perhaps making its life easier allowing it go faster... But really, the difference is so small that it probably doesn't mean anything at all. Could it be that the AGP bus is the limiting factor and pushing TCL vertices requires more bandwidth than just pushing rasterization info? Sorry, I know we shouldn't even get into it regarding gears...it's not a benchmark. Okay, everyone go back to their corners and repeat: Gears is not a benchmark Gears is not a benchmark Gears is not a benchmark :-) -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Snaps for gcc3, glibc-2.2
José Fonseca wrote: Anyway, I already have the minimum chroot environment setup. I just need to test it with a few snapshots, and arrange so that everything can be automated from a cronjob again. Your awesome! Thanks for your effort on these snapshots. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Slow performance with Matrox G400
[EMAIL PROTECTED] wrote: This is not really directly related to DRI, but more a general driver problem. I decided to post it here as the XFree86 - groups are for members only. [EMAIL PROTECTED] is an open list...however, I think your issues is related to the DRI, so I'll respond here. I have been using XFree4.02 for some time and have encountered some speed problems. These problems show when I use double buffering for normal windows. That is, I create a pixmap that is the same size as the window and draw stuff on it. After all drawing is done the pixmap is copied into the window. This works very fast when there are no other pixmaps, but when I have even one other pretty large pixmap the performance drops dramatically. Also if there is for example galeon or dillo running the same thing happens. Has anyone any idea why this happens? Simple theory is that the video memory is not sufficient for both the backbuffer and other pixmaps which causes the backbuffer being put in system memory. However, my G400 has 16 MB memory and that should be more then enough when running at 1024x768 resolution. For example at 32bpp color depth the screen-area takes only 1024*768*4 = 3 MBytes. So I could in theory have 4 screen-area sized pixmaps and still have 1 MB left. Jouni, With the DRI enabled, you'll also need 3 MBytes for the back buffer, another 3 for the depth buffer. Finally, the remainder needs to be divided up between texture cache and pixmap cache. I believe the current allocation is to provide a relatively small amount for the pixmap cache and the rest for textures. If you disable the DRI, almost the entire offscreen will be decicated to the pixmap cache. The other thing you could consider is leaving the DRI enabled and using OpenGL for graphics rendering where you already have a dedicated back buffer allocated. Two other options come to mind, both require some development: 1) Help w/ some of the more dynamic (and sharing) oriented schemes that are targeted at the Radeon, then back port to the MGA driver when it's done. 2) Implement the X double buffer extension so that it uses the dedicated OpenGL back buffer in hardware, instead of allocating a pixmap (which has the same pixmap cache limitation). Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Some thoughts on binary packages
The efforts that have gone into binary snapshots have been a good thing. They have enabled a broader user base by allowing users access to 3D drivers that didn't have them before, getting us feedback from a larger testing base, and exposing backwards compatability issues with our binary interfaces. Thank you to those that have contributed so far, especially Jose who has been building nightly snapshots, and Alan who has written and maintained the DRI packaging scripts. It would be wonderful if the driver release process could evolve to the point where it sets an example to IHV's for how binary only driver packages should be created that are compatabible with XFree86 and play nice with other driver packages. To reach that point, we need to make some improvements in how device independent vs. device specific components are managed. Here's a list of areas that need improvement if anybody is interested in working on this aspect of the DRI project. 1) Users need one simple package. If device independent files need to be included in a driver package, that should be done with care to ensure that packages installed from other vendors aren't broken. One way to achieve this level of compatability is to provide a mechanism that would allow installation scripts to query the version of device independent files at install time. Then, device independent files would only be updated if they came directly from open source releases on the XFree86 or the DRI projects and their version number indicated they were newer (and compatabile) with the current file installed on the system. 2) The kernel AGP GART module is one monolithic driver. IHV's need some way of releasing AGP GART updates without stepping on one another. 3) Many users don't build their own kernels. Providing a means for prebuilt kernel modules on few popolar flavors of kernel would be very useful. The number of actual kernels supported may vary, it's the means for supporting prebuilt modules that would be useful to the packaging effort. 4) A method for more people to get involved in providing nightly snapshots for different flavors of HW architectures, operating systems and compilers as well as a means for users to provide feedback on which ones are working well at any given time. This is not a definitive list. I'd like to get more feedback from IHV binary only package developers, open source package developers and nightly snapshot builders. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] issues/goals for improved texture memory management
Ian Romanick wrote: Really there are 3 places the texture data can be duplicated: in the app, in libGL, and on-card / AGP. This can either be done by exposing some sort of allocate AGP memory extension or with APPLE_client_storage and dynamic AGP remapping. I've done a cursory look at the AGP driver, and it seems like this is possible, but I'm not positive. Anyone know for sure? It is definitly possible in the AGP spec because Mac OS X can do it. :) I believe the R200 implementation of APPLE_client_storage allocates space from a static pool in AGP space. Are you looking for a way to make the AGP pool larger and dynamically move pages in and out of the AGP aperature? -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Patch to enable 3rd TMU on R100
Ian Romanick wrote: A lot of this stuff is inherently device independent with some device dependent direction (i.e., *ChooseTextureFormat), but it hasn't been implemented that way. As a reference point, my previous work removed somewhere around 450 lines of code from the MGA driver (~5%). The gains in the Radeon weren't quite as significant (there was no radeon_texcnv.c to get rid of). This just feels like a win-win to me. :) Having all of it in the kernel will make it easier to implement other off-screen buffers that can't be stolen (i.e., pbuffers, dynamically allocated back/depth buffer, etc.). I take it you don't really mean all of it, ie. not the texture conversion stuff you mention in the preceding paragraph. Right. I wanted to move the code that actually does the allocation, deallocation, and stealing into the kernel. The only problem that I saw was in notifying applications that their memory had been stolen. Sending a signal seemed like it would work, but that also felt like a very ugly solution. Two potential solutions that I can think of: 1) Track what's valid and not in shared memory and have the client check before using it. Access may need to be protected with a semaphore or DRM lock. 2) This one's a little wild just for what you want, but it's something Workstation Vendors have done in the past to virtualize limited resources...When stealing memory, setup the page tables to generate a page fault if it's accessed. Then have the handler steal memory from another application and replace memory for faulting application. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] pageflipping
Alan Hourihane wrote:
On Tue, Sep 24, 2002 at 02:49:37 +0100, Alan Hourihane wrote:
On Tue, Sep 24, 2002 at 02:19:24 +0100, Keith Whitwell wrote:
Michel Dänzer wrote:
On Die, 2002-09-24 at 13:11, Keith Whitwell wrote:
I've been thinking again about pageflipping realized I can solve the
remaining few problems if I can tweak the behaviour of the 2d driver
slightly.
At the moment, the 2d driver always draws to buffer zero (the old front
buffer), and then at some point in the future, the dirty parts are
blitted to buffer one (the old back buffer).
However, this can be incorrect in a couple of circumstances, particularly
when the dirty regions (or even the drawing itself) overlaps with the 3d
window.
I think all my problems can be solved if I do two things:
1) always have X draw to the *current* front buffer (buffer zero or
buffer one, depending)
2) subtract the 3d window from the dirty regions before blitting to
the current back buffer.
I can probably figure out 2) without to much effort.
For 1), I can adjust the accelerated functions fairly easily to get them
to draw to buffer zero/one as appropriate.
How do you deal with offscreen access?
They should remain exactly as they are: I want to change the offset of the
front buffer - I would hope that the two are decoupled, maybe that's a
mistake on my behalf.
What about software fallbacks? What value do these use to get a pointer
to the framebuffer, and how can I go about changing it?
It's passed to xxxScreenInit(), and even if there's a single place where
it's stored afterwards, I'm not sure relying on that is a good idea.
Doesn't 2) alone work?
No, because you should be able to render to the same window with both X and
GL and see the results onscreen. If X always renders to buffer zero,
sometimes that won't work.
In theory,
this should work, but I've not tested it.
{
PixmapPtr pspix;
pspix = (*pScreen-GetScreenPixmap) (pScreen);
(*pScreen-ModifyPixmapHeader)(pspix, pScreen-width,
pScreen-height, pScreen-rootDepth,
BitsPerPixel(pScreen-rootDepth),
PixmapBytePad(pScrn-displayWidth, pScreen-rootDepth),
NEWFBPOINTER);
}
Basically fbScreenInit, passes the framebuffer pointer down to
miScreenInit, which ends up in miCreateScreenResources later where
the screen pixmap is setup. It essentially does the above too, to setup
this up.
In fact, scratch that, looking furthur shows that the miCreateScreenResources
stores the Pixmap pointer in the devPrivate.
I'll do some digging.
It would be good to get Page Swapping working in the server. Not only
is this very valuable for 3D performance, but the X double buffer
extension should utilize this as well.
Perhaps we'll need to move this discussion to the xpert list, but first,
I'll ask here. Does anybody know of any applications that use DBE? If
not, we should remove it. If so, we need to fix it when the DRI is
enabled. The GLX spec clearly states:
All GLX rendering contexts share the same notion of which are front
buffers and which are back buffers for a given drawable. This notion is
also shared with the X double buffer extension (DBE).
Currently, DBE buffers are managed as X Pixmaps and DRI drivers have not
notion of DBE buffers. Any application that used OpenGL and DBE
together would be broken, but I haven't seen any bug reports along this
line. I have to conclude that no applications are using OpenGL and DBE
together.
Note: DBE and DRI cooperation has been broken for a long time. Keith's
work on page flipping is *not* the start of the problem, but it does
present an opportunity for us to fix DBE, or dump it.
--
/\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] pageflipping
Michel Dänzer wrote: On Die, 2002-09-24 at 16:59, Keith Whitwell wrote: You can't change the offset in the chip or offscreen access goes after whatever buffer is front. You'd have to use coordinate deltas, but only if the coordinates are within the virtual resolution, and even then I'm not sure that would always work. Try and see I guess. :) If so, it's a fundamental problem with xaa. What exactly do you mean? Michel, What exactly to *you* mean when you refer to offscreen? Offscreen XAA cache? Offscreen pixmaps? OpenGL back buffer? other OpenGL buffers? There's a lot in offscreen. Please clarify. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 8500, XFree86 CVS vs DRI..
Sven LUTHER wrote: On Wed, Sep 18, 2002 at 11:42:35PM -0700, Linus Torvalds wrote: Is there any reason why the DRI tree isn't tracking the XFree86 CVS tree more? Linus, Think of the DRI trunk as a 3D development branch of XFree86. For the 8500, we've been focused on developing the 3D driver with full TCL support. Other non-3D enhancements have been happening in the main branch (XFree86). The 3D enhancements will be merged into the main development branch of XFree86 before 4.3 goes out. On my Radeon 8500, the DRI tree apparently still doesn't do the Xv extension correctly, even though XFree86 CVS has done it for ages (thanks to Keith for getting the relevant bits off Gatos). So I have to have two different X servers, depending on whether I want to watch DVD's or whether I want to check 3D behaviour. A word of caution about DRM compatability and Gatos. I'm not certain how much of the Gatos functionality Keith P. has integrated into XFree86, but they have been releasing DRM drivers that are not backwards compatible with old XFree86 releases. My understanding of the problem is the Gatos guys need a modified DRM memory map layout and have not been focused on the compatability issue. I'm confident this issue could be resolved if someone interested (and capable) of understanding the Gatos modifications and the DRI backward compatability issues were to dig into this issue. However, to date, nobody has successfully addressed this issue. (The XFree86 CVS tree also has that funky red-cursor-with-a-shadow thing, which I've not yet decided if I like or dis-like ;) Because, as i understand it, the developpment cycle of Xfree/DRI is as follows : o XFree does a new release. o At this point DRI and Xfree are in sync, so DRI development is done in the DRI CVS, based on the lastly released XFree tree. o XFree developpment is done in the XFree CVS. o Sometimes near the end of the XFree development cycle, the two trees are synced by hand once the sync is done in a satisfactory way, The syncing can and has actually happened more frequently than once per release. o XFree does a new release, and all begins again. I think one of the reasons this is so is because the DRI tree is not complete, and needs XFree to build and work correctly, and it is easier for people building from DRI CVS to have the 4.2.0 tarball installed, and build from that. I guess people will try to merge usefull fixes from the XFree tree to the DRI tree if they feel they need them or so, thus making things easier for the folk doing the final sync. Friendly, Sven Luther --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Debugging DRM kernel modules
Bhavana Nagendra wrote: Hi, What is the preferred debugging method used for debugging loadable DRM kernel modules? Has anyone successfully used kgdb for debugging their driver? Any insight into this would be appreciated. I believe kprintf is the usual method. Please CC me as I'm not subscribed to the list yet. I would encourage you to subscribe if you're going to be supporting any DRM or other DRI components. These interfaces do evolve and this is the forum where they are reviewed and discussed. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Fwd: [Dri-patches] [ dri-Bugs-602843 ] MGA dual-head cloned console]
Keith, Since nobody is tracking bugs submitted via the DRI bug data base, I'll try to respond to some of these requests that come in and ask them to submit their support requests to the DRI-users list. Please add this canned response to the list of responses (I don't have admin privledges) at: https://sourceforge.net/tracker/admin/?group_id=387atid=100387add_canned=1 begin canned response Thanks you for sending your support requests to the DRI bug database. This database is *not* being monitored for support requests. We recommend you e-mail your request to [EMAIL PROTECTED] Thanks, The DRI Development Team end canned response -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ---BeginMessage--- Bugs item #602843, was opened at 2002-08-31 07:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=100387aid=602843group_id=387 Category: MGA X Server Group: Other Status: Open Resolution: None Priority: 5 Submitted By: Bryan Hundven (bhundven) Assigned to: Nobody/Anonymous (nobody) Summary: MGA dual-head cloned console Initial Comment: When I start my computer in text mode, only the primary head has a console (expected). I startx then close it and I now have the same console on both monitors and it won't go away until I reboot. BTW... I am not using fb! I am using: mga-20020831-linux.i386 Linux 2.4.19 XFree86 4.2.0-8 (redhat 7.3) Running on: Matrox G550 (32M ddr-sdram ver.) Bryan Hundven [EMAIL PROTECTED] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=100387aid=602843group_id=387 --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Dri-patches mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-patches ---End Message---
Re: [Dri-devel] sf.net tracker
Michel Dänzer wrote:
So, do we want to keep the trackers?
It has been used in the past, but currently, most of the primary
developers have *not* found it useful. I don't think anybody would be
disappointed if it were turned off...at least for now.
If yes, I suggest a couple
improvements:
* only allow submissions from logged in users
If we keep it on, that's a good idea.
* send mails to dri-{devel,user} instead of dri-patches to get more
attention
I was going to send a canned response to have the poster submit to
dri-users. I didn't realize we could change the list these get posted
on. I'm not sure we want these automatically posted. There appears to
be less follow up on the submitters end via this route. That's why I
think a push back to the submitter is just fine.
--
/\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
---
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] sf.net tracker
Michel Dänzer wrote: I think disabling the trackers would be better than a canned response because users might get annoyed by the latter after having entered a tracker entry. I agree. I have somewhat disabled the bug tracker, support request tracker, patch tracker and feature request tracker. I didn't find a means to completely turn these trackers off, but I was able to disable them from being public and put messages like this on the submital pages: The DRI feature request page is not currently being maintained. Please send all feature requests directly to [EMAIL PROTECTED] Thanks, The DRI Development Team Hopefully, that will do the trick. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon scratch register writeback patch
Michel Dänzer wrote: On Sun, 2002-07-14 at 15:36, Keith Whitwell wrote: Michel Dänzer wrote: On Fri, 2002-07-12 at 14:56, Keith Whitwell wrote: Looks good, but I think I've got an even better patch: http://www.penguinppc.org/~daenzer/DRI/radeon-nommio.diff I've moved the initialization and put the scratch registers right behind the ring read pointer, this should work with PCI GART and all kinds of AGP GART. I'll commit this now. This looks ok. The one thing I'd say is that we've added functionality to the kernel module, so we should bump the minor version number (ie 1.4.0) -- this means that you can test rmesa-drm.minor (or whatever) instead of firing off the ioctl checking for EINVAL. Bumping the minor strikes me as overkill for this. It's not a new ioctl or something. What about the attached patch? It's a change to the interface -- an extension. It doesn't matter that it's not a new ioctl, this is exactly what bumping the minor number is supposed to do. Bumping the minor number is free - it doesn't cost anything or break anything. One thing that we haven't really made clear is when a 'release' is. However, given that 1.3 is in the 2.5 kernel sources, I'd say wherever the line is, we've crossed it. So - bump the minor don't worry too much. You're the boss. :) Changed and committed. Michel, Please don't think of Keith as being heavy handed. His suggestion is exactly what we need to do in order to preserve compatability. Thanks for working with us on this issue. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Xpert]glXMakeCurrent dummyContext problem
Meelis Roos wrote: $ glxinfo name of display: localhost:10.0 Xlib: connection to :0.0 refused by server Xlib: Client is not authorized to connect to Server display: localhost:10 screen: 0 direct rendering: No If the display is different from :0.0 (:1.0, remote display, whatever) then GLX initialization tries to connecxt to :0.0 and fails. Sometimes this takes time, depending on user configuration. For example, on my home computer I have to wait quite a long for this :0.0 connect timeout for some reason when running GLX things on :1.0. I have seen this behaviour several times and today I decided to find out what's wrong. If this si the wrong list and there is a better list for GLX library problems, please direct me there. Below is an excerpt from ltrace -S glxinfo to find out the call trace. It basically shows that glxinfo calls glXMakeCurrent with correct display struct but inside glXMakeCurrent a connection to :0.0 is made. A little digging in the code shows that glXMakeCurrent saves old context: oldGC = __glXGetCurrentContext(); __glXGetCurrentContext() finds no previous context and uses dummyContext instead. Somehow dummyContext is used without check later and it seems that this results in spurious connect to default display :0.0. I have not determined where the exact call is since I don't have time to recompile it with debug info currently. This trace is from XFree 4.1.0-17 Debian package (because that's what I'm running on the computer where ltrace works) but I tried it with 4.2.99.1 CVS on another computer (sparc, so no ltrace) and the result was similar - it still connected to :0.0. Even more, it segfaulted somewhere after that but my current binaries are without debug info and I can't find out what exactly happened. Anyway, this GLX problem is present both in 4.1 and 4.2 current. 17369 XCreateWindow(0x08053b00, 49, 0, 0, 100)= 0x0302 17369 glXCreateContext(0x08053b00, 0x08055848, 0, 1, 1 unfinished ... 17369 malloc(1308 unfinished ... 17369 SYS_brk(0x08057000) = 0x08057000 17369 ... malloc resumed ) = 0x08055d10 17369 malloc(262140 unfinished ... 17369 SYS_mmap(0xbb04, 262144, 0x40337dd0, 266240, 0x8000) = 0x40392000 17369 ... malloc resumed ) = 0x40392008 17369 ... glXCreateContext resumed )= 0x08055d10 17369 glXMakeCurrent(0x08053b00, 0x0302, 0x08055d10, 1, 1 unfinished ... 17369 SYS_write(3, \217\024 , 232) = 232 17369 SYS_read(3, ???, 32)= -11 17369 SYS__newselect(4, 0xbaac, 0, 0, 0) = 1 17369 SYS_read(3, \001, 32) = 32 17369 XOpenDisplay(:0.0 unfinished ... 17369 SYS_uname(0xb534) = 0 17369 SYS_socketcall(1, 0xb774, 0x401e8fdc, 0x401e69e8, 60) = 4 17369 SYS_uname(0xb574) = 0 17369 SYS_uname(0xb474) = 0 17369 SYS_socketcall(3, 0xb754, 0x401feac0, 19, 0xb7cc) = 0 17369 SYS_uname(0xb5b4) = 0 17369 SYS_fcntl64(4, 2, 1, 2, 4) = 0 17369 SYS_access(0x08054678, 4, 0x401e8fdc, 0x08054678, 0xb82e) = 0 17369 SYS_open(/home/mroos/.Xauthority, 0, 0666) = 5 17369 SYS_fstat64(5, 0xb58c, 0x40338a40, 0x4033c36c, 5) = 0 17369 SYS_mmap(0xb554, 0xb58c, 0x40337dd0, 0x080568d8, 4096) = 0x40016000 17369 SYS_read(5, , 4096) = 304 17369 SYS_read(5, , 4096) = 0 17369 SYS_close(5)= 0 17369 SYS_munmap(0x40016000, 4096)= 0 17369 SYS_brk(0x08058000) = 0x08058000 17369 SYS_writev(4, 0xb954, 1, 1, 4) = 12 17369 SYS_fcntl64(4, 3, 0, 3, 4) = 2 17369 SYS_fcntl64(4, 4, 2050, 4, 4) = 0 17369 SYS_read(4, ???, 8) = -11 17369 SYS__newselect(5, 0xb8cc, 0, 0, 0) = 1 17369 SYS_read(4, , 8) = 8 17369 SYS_read(4, Client is not authorized to conn..., 48) = 48 17369 SYS_write(2, Xlib: connection to :0.0 refus..., 52) = 52 17369 SYS_write(2, Client is not authorized to conn..., 45) = 45 17369 SYS_write(2, \r\n, 2) = 2 17369 SYS_socketcall(13, 0xb8c4, 0x401e8fdc, 0x08056868, 0x08056820) = 0 17369 SYS_close(4)= 0 17369 ... XOpenDisplay resumed )= NULL 17369 malloc(2244)= 0x080562b8 17369 ... glXMakeCurrent resumed ) = 1 Meelis, When you have time, build the DRI trunk as debuggable and send us whatever info you find. A patch would be great :-) Post to [EMAIL PROTECTED] Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email
Re: [Dri-devel] Segfault in DRIClipNotify
Leif Delgass wrote:
On Fri, 5 Jul 2002, Jens Owen wrote:
Okay, try the attached patch. I think I'll do more than this, but it
would be great if you could test just this, first.
Okay, I have attached a more robust patch. Can you try this on your branch?
I'll apply this to the
mach64 branch, but I'll let you patch the trunk.
I'll apply this new patch to the trunk if it works okay for you.
--
/\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
--- xc/programs/Xserver/GL/dri/dri.c.jens Fri Jul 5 13:07:43 2002
+++ xc/programs/Xserver/GL/dri/dri.cSat Jul 6 09:27:10 2002
@@ -383,29 +383,29 @@
/* Wrap DRI support */
if (pDRIInfo-wrap.ValidateTree) {
- pDRIPriv-wrap.ValidateTree = pScreen-ValidateTree;
- pScreen-ValidateTree = pDRIInfo-wrap.ValidateTree;
+ pDRIPriv-wrap.ValidateTree = pScreen-ValidateTree;
+ pScreen-ValidateTree = pDRIInfo-wrap.ValidateTree;
}
if (pDRIInfo-wrap.PostValidateTree) {
pDRIPriv-wrap.PostValidateTree = pScreen-PostValidateTree;
- pScreen-PostValidateTree = pDRIInfo-wrap.PostValidateTree;
+ pScreen-PostValidateTree = pDRIInfo-wrap.PostValidateTree;
}
if (pDRIInfo-wrap.WindowExposures) {
- pDRIPriv-wrap.WindowExposures = pScreen-WindowExposures;
- pScreen-WindowExposures = pDRIInfo-wrap.WindowExposures;
+ pDRIPriv-wrap.WindowExposures = pScreen-WindowExposures;
+ pScreen-WindowExposures= pDRIInfo-wrap.WindowExposures;
}
if (pDRIInfo-wrap.CopyWindow) {
- pDRIPriv-wrap.CopyWindow = pScreen-CopyWindow;
- pScreen-CopyWindow = pDRIInfo-wrap.CopyWindow;
+ pDRIPriv-wrap.CopyWindow = pScreen-CopyWindow;
+ pScreen-CopyWindow = pDRIInfo-wrap.CopyWindow;
}
if (pDRIInfo-wrap.ClipNotify) {
- pDRIPriv-wrap.ClipNotify = pScreen-ClipNotify;
- pScreen-ClipNotify = pDRIInfo-wrap.ClipNotify;
+ pDRIPriv-wrap.ClipNotify = pScreen-ClipNotify;
+ pScreen-ClipNotify = pDRIInfo-wrap.ClipNotify;
}
if (pDRIInfo-wrap.AdjustFrame) {
- ScrnInfoPtr pScrn = xf86Screens[pScreen-myNum];
- pDRIPriv-wrap.AdjustFrame = pScrn-AdjustFrame;
- pScrn-AdjustFrame = pDRIInfo-wrap.AdjustFrame;
+ ScrnInfoPtr pScrn = xf86Screens[pScreen-myNum];
+ pDRIPriv-wrap.AdjustFrame = pScrn-AdjustFrame;
+ pScrn-AdjustFrame = pDRIInfo-wrap.AdjustFrame;
}
DRIDrvMsg(pScreen-myNum, X_INFO, [DRI] installation complete\n);
@@ -417,18 +417,42 @@
DRICloseScreen(ScreenPtr pScreen)
{
DRIScreenPrivPtr pDRIPriv = DRI_SCREEN_PRIV(pScreen);
+DRIInfoPtr pDRIInfo;
drmContextPtrreserved;
int reserved_count;
if (pDRIPriv pDRIPriv-directRenderingSupport) {
+pDRIInfo = pDRIPriv-pDriverInfo;
+
+ /* Unwrap DRI Functions */
+ if (pDRIPriv-wrap.ValidateTree) {
+ pScreen-ValidateTree = pDRIPriv-wrap.ValidateTree;
+ pDRIPriv-wrap.ValidateTree = NULL;
+ }
+ if (pDRIPriv-wrap.PostValidateTree) {
+ pScreen-PostValidateTree = pDRIPriv-wrap.PostValidateTree;
+ pDRIPriv-wrap.PostValidateTree = NULL;
+ }
+ if (pDRIPriv-wrap.WindowExposures) {
+ pScreen-WindowExposures= pDRIPriv-wrap.WindowExposures;
+ pDRIPriv-wrap.WindowExposures = NULL;
+ }
+ if (pDRIPriv-wrap.CopyWindow) {
+ pScreen-CopyWindow = pDRIPriv-wrap.CopyWindow;
+ pDRIPriv-wrap.CopyWindow = NULL;
+ }
+ if (pDRIPriv-wrap.ClipNotify) {
+ pScreen-ClipNotify = pDRIPriv-wrap.ClipNotify;
+ pDRIPriv-wrap.ClipNotify = NULL;
+ }
if (pDRIPriv-wrap.AdjustFrame) {
- ScrnInfoPtr pScrn = xf86Screens[pScreen-myNum];
- pScrn-AdjustFrame = pDRIPriv-wrap.AdjustFrame;
- pDRIPriv-wrap.AdjustFrame = NULL;
+ ScrnInfoPtr pScrn = xf86Screens[pScreen-myNum];
+ pScrn-AdjustFrame = pDRIPriv-wrap.AdjustFrame;
+ pScrn-AdjustFrame = NULL;
}
- if (pDRIPriv-pDriverInfo-driverSwapMethod != DRI_KERNEL_SWAP) {
+ if (pDRIInfo-driverSwapMethod != DRI_KERNEL_SWAP) {
if (!drmRemoveSIGIOHandler(pDRIPriv-drmFD)) {
DRIDrvMsg(pScreen-myNum, X_ERROR,
[drm] failed to remove DRM signal handler\n);
@@ -463,14 +487,14 @@
lockRefCount=0;
DRIDrvMsg(pScreen-myNum, X_INFO,
[drm] unmapping %d bytes of SAREA 0x%08lx at %p\n,
- pDRIPriv-pDriverInfo-SAREASize,
+ pDRIInfo-SAREASize,
pDRIPriv-hSAREA,
pDRIPriv-pSAREA
Re: [Dri-devel] Segfault in DRIClipNotify
Leif Delgass wrote:
Jens,
This works after fixing one thing in this section from DRICloseScreen:
if (pDRIPriv-wrap.AdjustFrame) {
- ScrnInfoPtr pScrn = xf86Screens[pScreen-myNum];
- pScrn-AdjustFrame = pDRIPriv-wrap.AdjustFrame;
- pDRIPriv-wrap.AdjustFrame = NULL;
+ ScrnInfoPtr pScrn = xf86Screens[pScreen-myNum];
+ pScrn-AdjustFrame = pDRIPriv-wrap.AdjustFrame;
+ pScrn-AdjustFrame = NULL;
^^
}
That last line should change from:
pScrn-AdjustFrame = NULL;
to:
pDRIPriv-wrap.AdjustFrame = NULL;
This is line 452 in the patched dri.c. Other than that it looks good.
Leif,
As you can probably tell by now, I'm not able to test this path. I've
tried on the Radeon driver, but it, like most drivers has a lot of
failure cases that don't appear to be working properly. What does work
is when the DRI comes up cleanly, or when hitting one of the early
fairly cases...lack of AGP, etc. However, if I force a failure in
RADEONDRIFinishScreenInit, which is after most of the DRI resources have
been setup, I can hang the system.
The fact that you are exercising these paths in the mach64 driver is a
good thing.
I made your change to my last patch and have checked it into the trunk.
Regards,
Jens
--
/\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
---
This sf.net email is sponsored by:ThinkGeek
Got root? We do.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Ann: Radeon 8500 binary snapshots now available
Oliver Feiler wrote: On Saturday 06 July 2002 17:36, Oliver Feiler wrote: On Friday 05 July 2002 13:04, José Fonseca wrote: Keith Whitwell confirmed the readiness of the r200-0-1-branch for testing and for binary snapshots. Just tested this driver on a system with original ATI 8500 card. With the binary snaphots and with the r200 branch compiled myself the system crashes immediately when X is started. With DRI disabled X comes up and runs without problems. Oliver, If you have the room for a fully debuggable X Server, try adding this patch before you build the X Server. Then login remotely and run gdb xc/programs/Xserver/XFree86 as root. If you can case the crash like that, post the backtrace to the list. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- xc/config/cf/host.def.jens Tue Jun 4 16:32:56 2002 +++ xc/config/cf/host.def Tue Jul 6 13:43:29 2002 @@ -55,7 +55,7 @@ /* #define GlxBuiltInMga YES */ /* #define GlxBuiltInR128 YES */ /* #define GlxBuiltInRadeon YES */ -/* #define DoLoadableServer NO */ +#define DoLoadableServer NO /* Optionally turn this on to change the place where you install the build. * Warning: trailing blanks will cause build failures.
[Dri-devel] Any interest in a face to face meeting
The Linux Kongress is accepting applications for fully sponsered workshops. This is an opportunity for OS development communities to get together and work face to face for 3 days. See http://www.linux-kongress.org/2002/workshops/faq.html for more details. If you are interested in attending a workshop like this for DRI development, send me an e-mail. If there is enough interest, I'll send in an application. The deadline is monday. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon dualhead and DRI
Adam K Kirchhoff wrote: Actually, Jens, I'm not even talking about getting it working with Xinerama. Just a traditional dualhead setup with two independent displays. Last time I tried this, the radeon driver disabled DRI. The traditional dualhead setup with two independent displays from a single graphics chip is represented by the first diagram: http://www.tungstengraphics.com/dri/Multihead_DH.txt 2D support is in place, now. That's represented by the two indirect rendering pipes that go down the middle of the diagram. This level of sharing is achieved without the need for any DRI mechanisms (contexts, locks, etc.). Once you enable a either of the DRI pipe (the two outside direct rendering paths), you'll need to address how the DRI mechanims will be shared across all the pipes. This could be a straight forward task, at least for a single DRI pipe on the primary display. If somebody is up to flushing out this support. Let us know. Now, if I throw a PCI card into my machine, in addition to the AGP Radeon 7500, I can get DRI working on the Radeon 7500, and still use the PCI card as a secondary head. That is a completely different scenario because you don't have shared render hardware and your not sharing the AGP aperature. To the DRI drivers, it looks the same as a single headed DRI display. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Segfault in DRIClipNotify
Leif Delgass wrote: After merging the trunk into the mach64 branch, I get a segfault in the Xserver in DRIClipNotify (dereferences a null pointer when trying to call a wrapper function, I think) if direct rendering is disabled after DRIFinishScreenInit is called, e.g. if the init of the drm kernel module fails. I tested this with Rage128 by making the cce_init return non-zero and I get the same thing. Was there a recent change in libdri.a that would be causing this? Leif, I spent a little time this morning looking at this. There have been a few minor changes to dri.c in the last month. It's possible that one of these is biting you: revision 1.40 date: 2002/06/12 15:50:27; author: keithw; state: Exp; lines: +16 -0 merged tcl-0-0-branch revision 1.39 date: 2002/06/02 16:00:44; author: mdaenzer; state: Exp; lines: +1 -1 fixes for big endian in general and powerpc in particular revision 1.38 date: 2002/05/28 13:45:11; author: jensowen; state: Exp; lines: +4 -0 bump clipstamp before destroying drawable However, I think you may be tickling a latent bug in the DRI. It's possible that all the other drives have just avoided this bug so far. I looked at DRICloseScreen and I don't see that the DRIClipNotify wrapper is being removed. There are other unwraps missing as well. Can you send me a back trace from a static debuggable server? Let me know if you need help building this. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Any interest in a face to face meeting
Jens Owen wrote: The Linux Kongress is accepting applications for fully sponsered workshops. This is an opportunity for OS development communities to get together and work face to face for 3 days. See http://www.linux-kongress.org/2002/workshops/faq.html for more details. If you are interested in attending a workshop like this for DRI development, send me an e-mail. If there is enough interest, I'll send in an application. The deadline is monday. Many thanks to those that have replied so quickly about attending at DRI session at Linux Kongress. Unfortunately, it's already clear that we would not have critical mass from the most active developers in our community. Consequently, I'm not planning on sending an application. Perhaps there will be other opportunities in the future. If you are a DRI contributer and you plan on attending SigGraph this year, let us know. We'll at least buy you lunch or dinner :-) Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon dualhead and DRI
Adam K Kirchhoff wrote: Could you give a quick explanation, just for my understanding, of the differences between the dualhead Matrox cards (which support the DRI on the primary head) and the dualhead Radeon cards (which do not, currently). DRI requires a hardware cursor. Matrox does not support a hardware cursor on the secondary head for the G400 (which was the target when we wrote dual head support for the driver). Consequently, that driver was written to make sure the DRI was never run on the secondary head. Since the ATI driver could support DRI on the second head, it's possible that when dual head support was added, that the entire DRI was disabled for dual head. It is likely that you could get the DRI running on the primary head and disabled on the secondary head quite easily for the Radeon. This would be effectively the same mode as the matrox driver supports. Any more detailed questions on what needs to change in the Radeon would need to be addressed by the Radeon maintainers. I recommend starting with Kevin Martin, but there are others who have been deep into this driver. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Segfault in DRIClipNotify
Leif Delgass wrote:
On Fri, 5 Jul 2002, Jens Owen wrote:
[snip]
However, I think you may be tickling a latent bug in the DRI. It's
possible that all the other drives have just avoided this bug so far.
I looked at DRICloseScreen and I don't see that the DRIClipNotify
wrapper is being removed. There are other unwraps missing as well.
Can you send me a back trace from a static debuggable server? Let me
know if you need help building this.
Could you tell me how to build a static server or point me to a HOWTO?
The xc/config/cf/host.def in the DRI tree is setup to easily modified to
build a debuggable server. Attached is a copy of a modified host.def
file I used for debugging an i810 problem. You'll probably need to add
the mach64 driver to these options.
Meanwhile, here's a backtrace from the X server built from the branch. It
looks like the ClipNotify wrapper is being called when pDRIPriv is null,
though I'm not sure why I wouldn't have run into this before...
Program received signal SIGSEGV, Segmentation fault.
DRIClipNotify (pWin=0x85d3a60, dx=0, dy=0) at dri.c:1732
1732if(pDRIPriv-wrap.ClipNotify) {
(gdb) bt
#0 DRIClipNotify (pWin=0x85d3a60, dx=0, dy=0) at dri.c:1732
#1 0x080c9009 in MapWindow (pWin=0x85d3a60, client=0x81d56a8) at window.c:2864
#2 0x080c5ee8 in InitRootWindow (pWin=0x85d3a60) at window.c:522
#3 0x080bf39c in main (argc=4, argv=0xb9d4, envp=0xb9e8) at main.c:439
#4 0x40072647 in __libc_start_main (main=0x80bee9c main, argc=4,
ubp_av=0xb9d4, init=0x806cc08 _init, fini=0x8174c80 _fini,
rtld_fini=0x4000dcd4 _dl_fini, stack_end=0xb9cc)
at ../sysdeps/generic/libc-start.c:129
(gdb) info locals
pWin = 0x85d3a60
pScreen = 0x85d3748
pDRIPriv = 0x0
pDRIDrawablePriv = 0x0
Yes, it looks like the DRI initialization process was started, causing
the DRI wrappers to be put in place; then, something caused DRI
initialization to fail, but the failure handling code does not remove
the wrappers.
I believe I need to unwrap the DRI routines in DRICloseScreen. I'd like
to fix this case and ask you to test with what you've got since it's
hard to test these unusual failure cases when everythings working properly.
It's still curious no other drivers have had this problem. Either
nobody else has gone done these failure cases, or I'm barking up the
wrong tree.
Can you verify that we are indeed calling DRICloseScreen by putting a
breakpoint at that routine and sending me a backtrace at that point?
Thanks,
Jens
--
/\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
/*
* Set this for each DRI branch. It will be appended to the XFree86 version
* information.
*/
#define XFree86CustomVersion DRI trunk
#define DefaultGcc2AxpOpt -O2 -mcpu=ev6
#define DefaultGcc2PpcOpt -O2 -mcpu=750
#define DefaultGcc2i386Opt -O2
#if defined(AlphaArchitecture)
# define LibraryCDebugFlags -O2 -mcpu=ev6
#elif defined(PpcArchitecture)
# define LibraryCDebugFlags -O2 -mcpu=750
#else
# define LibraryCDebugFlags -O2
#endif
#define BuildXFree86ConfigTools YES
#if defined(PpcArchitecture)
#define XF86CardDrivers ati
#define DriDrivers r128 radeon
#else
#define XF86CardDrivers tdfx i810 mga ati glint vga
#define DriDrivers tdfx mga i810 r128 radeon gamma i830 /* sis ffb */
#endif
#define GccWarningOptions -Wall -Wpointer-arith -Wstrict-prototypes \
-Wmissing-prototypes -Wmissing-declarations \
-Wnested-externs
#define DefaultCCOptions -ansi GccWarningOptions -pipe -g
#define NormalLibGlx NO
#define BuildXF86DRI YES
/* To do profiling of the dynamically loaded 'xyz_dri.so' object, turn
* this on.
* Use 'xc/lib/GL/makeprofile.sh' to make it work.
*/
/* #define GlxSoProf YES */
#ifdef GlxSoProf
# undef DefaultCCOptions
# define DefaultCCOptions -ansi GccWarningOptions -pipe -g -p
#endif
/* Optionally turn these on for debugging */
/* #define GlxBuiltInTdfx YES */
#define GlxBuiltInI810 YES
/* #define GlxBuiltInMga YES */
/* #define GlxBuiltInR128 YES */
/* #define GlxBuiltInRadeon YES */
#define DoLoadableServer NO
/* Optionally turn this on to change the place where you install the build.
* Warning: trailing blanks will cause build failures.
*/
/* #define ProjectRoot /usr/X11R6-DRI */
/* Optionally turn this on to force the kernel modules to build */
/* #define BuildXF86DRM YES */
#define XF86AFB NO
#define XnestServer NO
#define XVirtualFramebufferServer NO
/*
* Don't change anything below or the build will fail.
*/
#define BuildServersOnly YES
#define BuildLibrariesForXServers NO
#define BuildLibrariesForConfigTools NO
#define BuildXIE NO
#define BuildPexExt NO
#define XprtServer NO
#define SharedLibFont NO
Re: [Dri-devel] Segfault in DRIClipNotify
Leif Delgass wrote:
On Fri, 5 Jul 2002, Jens Owen wrote:
Leif Delgass wrote:
On Fri, 5 Jul 2002, Jens Owen wrote:
[snip]
However, I think you may be tickling a latent bug in the DRI. It's
possible that all the other drives have just avoided this bug so far.
I looked at DRICloseScreen and I don't see that the DRIClipNotify
wrapper is being removed. There are other unwraps missing as well.
Can you send me a back trace from a static debuggable server? Let me
know if you need help building this.
Could you tell me how to build a static server or point me to a HOWTO?
The xc/config/cf/host.def in the DRI tree is setup to easily modified to
build a debuggable server. Attached is a copy of a modified host.def
file I used for debugging an i810 problem. You'll probably need to add
the mach64 driver to these options.
OK, I'll try this. I think you're right that we need to add the
GlxBuiltIn.. option for mach64.
If my memory serves me, that's just for 3D clients, and it doesn't work
anymore...so I wouldn't worry about that option. However, you will want
to add mach64 to the other driver lists in this file.
Meanwhile, here's a backtrace from the X server built from the branch. It
looks like the ClipNotify wrapper is being called when pDRIPriv is null,
though I'm not sure why I wouldn't have run into this before...
Program received signal SIGSEGV, Segmentation fault.
DRIClipNotify (pWin=0x85d3a60, dx=0, dy=0) at dri.c:1732
1732if(pDRIPriv-wrap.ClipNotify) {
(gdb) bt
#0 DRIClipNotify (pWin=0x85d3a60, dx=0, dy=0) at dri.c:1732
#1 0x080c9009 in MapWindow (pWin=0x85d3a60, client=0x81d56a8) at window.c:2864
#2 0x080c5ee8 in InitRootWindow (pWin=0x85d3a60) at window.c:522
#3 0x080bf39c in main (argc=4, argv=0xb9d4, envp=0xb9e8) at main.c:439
#4 0x40072647 in __libc_start_main (main=0x80bee9c main, argc=4,
ubp_av=0xb9d4, init=0x806cc08 _init, fini=0x8174c80 _fini,
rtld_fini=0x4000dcd4 _dl_fini, stack_end=0xb9cc)
at ../sysdeps/generic/libc-start.c:129
(gdb) info locals
pWin = 0x85d3a60
pScreen = 0x85d3748
pDRIPriv = 0x0
pDRIDrawablePriv = 0x0
Yes, it looks like the DRI initialization process was started, causing
the DRI wrappers to be put in place; then, something caused DRI
initialization to fail, but the failure handling code does not remove
the wrappers.
I believe I need to unwrap the DRI routines in DRICloseScreen. I'd like
to fix this case and ask you to test with what you've got since it's
hard to test these unusual failure cases when everythings working properly.
It's still curious no other drivers have had this problem. Either
nobody else has gone done these failure cases, or I'm barking up the
wrong tree.
It's pretty easy to test if you just change the return value of the
driver's drm init function to return non-zero. For example, I tried this
in the r128 driver in r128_do_init_cce (changed the last line to return
-1), and it suffers the same problem (the backtrace was the same).
Yes, it's easy for force specific failures; but I don't think developers
and users have been hitting these cases in normal testing scenarios.
Otherwise, we'd have caught this during the 3 years this extensions been
in use.
Can you verify that we are indeed calling DRICloseScreen by putting a
breakpoint at that routine and sending me a backtrace at that point?
I know it's called because I see the messages in the X log about removing
the signal handler, kernel context, SAREA, etc. It's called as part of
the DRI driver specific CloseScreen (ATIDRICloseScreen) when the kernel
init fails (which is after DRIFinishScreenInit is called). In fact, the
entire X init seems to work without a hitch (I see all the normal messages
in the X log after Direct rendering disabled up to XINPUT) until the
root window is initialized.
Okay, try the attached patch. I think I'll do more than this, but it
would be great if you could test just this, first.
--
/\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
--- xc/programs/Xserver/GL/dri/dri.c.jens Fri Jul 5 13:07:43 2002
+++ xc/programs/Xserver/GL/dri/dri.cFri Jul 5 16:27:11 2002
@@ -417,11 +417,14 @@
DRICloseScreen(ScreenPtr pScreen)
{
DRIScreenPrivPtr pDRIPriv = DRI_SCREEN_PRIV(pScreen);
+DRIInfoPtr pDRIInfo;
drmContextPtrreserved;
int reserved_count;
if (pDRIPriv pDRIPriv-directRenderingSupport) {
+pDRIInfo = pDRIPriv-pDriverInfo;
+
if (pDRIPriv-wrap.AdjustFrame) {
ScrnInfoPtr pScrn = xf86Screens[pScreen-myNum];
pScrn-AdjustFrame = pDRIPriv-wrap.AdjustFrame;
@@ -477,6 +480,27 @@
drmClose(pDRIPriv-drmFD);
+ /* Unwrap DRI Functions */
+ if (pDRIInfo-wrap.ValidateTree) {
+ pScreen-ValidateTree = pDRIPriv-wrap.ValidateTree
Re: [Dri-devel] Segfault in DRIClipNotify
Leif Delgass wrote:
On Fri, 5 Jul 2002, Jens Owen wrote:
[...]
The xc/config/cf/host.def in the DRI tree is setup to easily modified to
build a debuggable server. Attached is a copy of a modified host.def
file I used for debugging an i810 problem. You'll probably need to add
the mach64 driver to these options.
OK, I'll try this. I think you're right that we need to add the
GlxBuiltIn.. option for mach64.
If my memory serves me, that's just for 3D clients, and it doesn't work
anymore...so I wouldn't worry about that option. However, you will want
to add mach64 to the other driver lists in this file.
You're right, it's for building a libGL with the driver statically linked.
I did find where the build problem is, though. In xc/lib/GL/GL/Imakefile,
when I added GlxBuiltInMach64, based on the r128 and Radeon, I was getting
No rule to make target ../../../lib/GL/mesa/dri/?*.o in xc/lib/GL/GL.
It looks like the xc/lib/GL/mesa/dri directory was removed and dri_util.c
was added to xc/lib/GL/dri. I don't know if this is the right solution,
but I took a guess and was able to get it to build with this change:
Index: Imakefile
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/GL/Imakefile,v
retrieving revision 1.1.1.2.12.1
diff -u -r1.1.1.2.12.1 Imakefile
--- Imakefile 27 Jun 2002 22:04:03 - 1.1.1.2.12.1
+++ Imakefile 5 Jul 2002 23:01:58 -
@@ -65,10 +65,10 @@
MESADOBJS = $(COREMESADOBJS) $(MESA_ASM_DOBJS)
MESAPOBJS = $(COREMESAPOBJS) $(MESA_ASM_POBJS)
- DRIMESAOBJS = $(GLXLIBSRC)/mesa/dri/?*.o
-DRIMESAUOBJS = $(GLXLIBSRC)/mesa/dri/unshared/?*.o
-DRIMESADOBJS = $(GLXLIBSRC)/mesa/dri/debugger/?*.o
-DRIMESAPOBJS = $(GLXLIBSRC)/mesa/dri/profiled/?*.o
+ DRIMESAOBJS = $(GLXLIBSRC)/dri/dri_util.o
+DRIMESAUOBJS = $(GLXLIBSRC)/dri/unshared/dri_util.o
+DRIMESADOBJS = $(GLXLIBSRC)/dri/debugger/dri_util.o
+DRIMESAPOBJS = $(GLXLIBSRC)/dri/profiled/dri_util.o
#if GlxUseBuiltInDRIDriver
#include ../mesa/src/drv/common/Imakefile.inc
Check with Keith to see if this stuff is worth fixing. If so,
great...if not, we ought to remove it as cruft.
Meanwhile, here's a backtrace from the X server built from the branch. It
looks like the ClipNotify wrapper is being called when pDRIPriv is null,
though I'm not sure why I wouldn't have run into this before...
Program received signal SIGSEGV, Segmentation fault.
DRIClipNotify (pWin=0x85d3a60, dx=0, dy=0) at dri.c:1732
1732if(pDRIPriv-wrap.ClipNotify) {
(gdb) bt
#0 DRIClipNotify (pWin=0x85d3a60, dx=0, dy=0) at dri.c:1732
#1 0x080c9009 in MapWindow (pWin=0x85d3a60, client=0x81d56a8) at window.c:2864
#2 0x080c5ee8 in InitRootWindow (pWin=0x85d3a60) at window.c:522
#3 0x080bf39c in main (argc=4, argv=0xb9d4, envp=0xb9e8) at main.c:439
#4 0x40072647 in __libc_start_main (main=0x80bee9c main, argc=4,
ubp_av=0xb9d4, init=0x806cc08 _init, fini=0x8174c80 _fini,
rtld_fini=0x4000dcd4 _dl_fini, stack_end=0xb9cc)
at ../sysdeps/generic/libc-start.c:129
(gdb) info locals
pWin = 0x85d3a60
pScreen = 0x85d3748
pDRIPriv = 0x0
pDRIDrawablePriv = 0x0
The backtrace from the static server was the same. BTW, this might help
others trying to debug with a dynamic server: I removed 'Load GLcore'
from my XF86Config, because I saw that it was being reloaded by the glx
module anyway. Before I did that, I was getting a backtrace that was
wrong -- it said something about mipmaps, so I was suspicious :)
Hmmm, I was wondering how you got such nice line numbers from the back
trace of a dynamic server. I'm also guessing you have the version of
gdb with the XFree86 module support.
Yes, it looks like the DRI initialization process was started, causing
the DRI wrappers to be put in place; then, something caused DRI
initialization to fail, but the failure handling code does not remove
the wrappers.
I believe I need to unwrap the DRI routines in DRICloseScreen. I'd like
to fix this case and ask you to test with what you've got since it's
hard to test these unusual failure cases when everythings working properly.
It's still curious no other drivers have had this problem. Either
nobody else has gone done these failure cases, or I'm barking up the
wrong tree.
It's pretty easy to test if you just change the return value of the
driver's drm init function to return non-zero. For example, I tried this
in the r128 driver in r128_do_init_cce (changed the last line to return
-1), and it suffers the same problem (the backtrace was the same).
Yes, it's easy for force specific failures; but I don't think developers
and users have been hitting these cases in normal testing scenarios.
Otherwise, we'd have caught this during the 3 years this extensions been
in use.
It's true that the more stable drivers wouldn't hit this very often,
but this bug wasn't present before the merge of the trunk into the mach64
branch
Re: [Dri-devel] s3virge fixes in CVS
max wrote: Alas, we still miss a good integration with the 2D part (it would be nice [but a super-task] if we could convert that to use DMA instead on MMIO...): - piece of 3D-apps win stay around - no 2D accel Max, Have you seen how the Radeon driver has different routines for 2D accelleration with DRI enabled (uses CP) vs DRI disabled (uses MMIO)? -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Caffeinated soap. No kidding. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] OS Independent Templates
Hi Eric, How is the OS indepedence project coming? I wanted to make the IRC mtg today and get some consensus for merging your stuff in, but I had a schedule conflict. What do you think still needs to be done before merging your work onto the DRI trunk? I definitely think your work is absolutely what the DRI needs for good cross-OS support. I'd like to hear from other developers if there is a concern about making this merge relatively soon. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: bsd-3-0-0-branch)
Eric Anholt wrote: Log message: The drmCommand interface was passing a size to DRM_IOR() and friends, when DRM_IOR was expecting a type, so on BSD only an int was copied in/out of the kernel. Make drmCommand use new DRM_IOC(), which expects a size. Good catch! I'm surprised this worked at all under Linux. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: bsd-3-0-0-branch)
Eric Anholt wrote: Log message: Include protection against ioctl() definition only in the __FreeBSD__ and XFree86Server case. These two drm.h's probably should be shared. With this commit radeon, r128, and mga are all working on FreeBSD and Linux. Haven't tested tdfx, but I have no reason to not expect it to work. At this point, who should review this for a merge? Damn, this is looking sweet! You have almost hit gold with this work, and here's what I would consider perfection: The source repository and plain source trees that haven't been built, yet would contain an os-support/linux/drm/kernel that contained the drm* files for Linux: drm_agpsupport.h drm_drawable.h drm_ioctl.h drm_os_freebsd.h drm_auth.hdrm_drv.h drm_linux.h drm_os_netbsd.h drm_bufs.hdrm_fops.h drm_lists.h drmP.h drm_context.h drm.h drm_lock.hdrm_scatter.h drm_dma.h drm_init.h drm_memory.h drm_sysctl.h drm_vm.h Not these are all Linux specific, but Hardware independent, and of course an os-support/bsd/drm/kernel and other os specific directories, too. None of which contained HW specific files. The os-support/shared/drm/kernel directory would then contain the HW specifics: gamma_dma.c i810_drv.h mga_drm.h r128_drm.h radeon_drv.h gamma_drm.h i810.h mga_drv.c r128_drv.c radeon_state.c gamma_drv.c i830_dma.c mga_drv.h r128_drv.h radeon.h gamma_drv.h i830_drm.h mga_state.c r128_state.c tdfx_drv.c gamma.h i830_drv.c mga_ucode.h r128.h tdfx.h i810_dma.c i830_drv.h mga_warp.c radeon_cp.c i810_drm.h i830.h mga.h radeon_drm.h i810_drv.c mga_dma.c r128_cce.c radeon_drv.c For the drivers you've ported to your OS independent templates (radeon, r128 and mga), it looks like the *_drv.c and Makefile support are all that's left in the OS directories. If you can get these out of there, even by adding a few OS ifdefs in the shared directory, you will get big leverage when a new driver is written. Generally, a driver writer copies another driver as a starting point, and they won't discard non development OS's simply because it's easier to ignore the directories. In other words, let's make new drivers work on all supported OS's by default instead of having to enable each OS/driver combo by hand. I can see the need for disabling a OS/driver combo by hand after we know it can't be easily supported. I'm definitely interested in hearing your opinion on squeeking out the last bigs of OS specifics in these drivers. I realize the last parts are usually the most difficult. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Website [update!]
Ian Molton wrote: Well, I've backed up the old website (except for the huge snapshots folder. I've also put the shell of the new site up. go to http://dri.sourceforge.net/new_site/ to see it. I'm awaiting some charts and a couple of pages from Liam, which look to become excellent references, and I have yet to hook up some of the links. I'll be doing these tasks shortly, but I'd like to know what y'all think of the new layout? (yes, I know the hardware page isnt there yet ;-) Ian, A couple of comments: 1) Please add a link on the side bar to our project page on Source Forge. 2) Your plea for help is spread out over the entire site. Please make sure all potential new developers are aware they should read the developer FAQ before starting in with questions on the devel list. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
