Re: [Dri-devel] Adding hardware detection to DRI drivers
Ville Syrj?l? [EMAIL PROTECTED] wrote: On Wed, Oct 15, 2003 at 03:48:38PM -0700, Alex Deucher wrote: there's also this driver: http://www.instmath.rwth-aachen.de:8000/linux/G450-PCI/ I'm not sure how the G4/550 and G200 differ in regard to PCI vs. AGP... AFAIK G450 PCI cards have an AGP-PCI bridge on the card which could do address translation just like the AGP GART. G200/G400 don't have that bridge. I'm not sure if the agpgart driver in that link you posted uses that bridge or some generic PCI GART stuff available on some architectures. Hey, the guy's a good friend of mine - but he never told me he was tweaking DRI stuff I'm pretty shure he wrote the driver for use on his UP2000 Alpha mainboard he used for visualization purpose, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mga anisotropic filtering
Ville Syrjälä wrote: My previous comment on irc about anisotropic filtering needing two mip levels was crap. Fortunately I've since managed to figure out the real details. The good news is that G550 doesn't have any problems with anisotropic filtering. The bad news is that G4x0 chips need both texture units to pull it off. Both units must be programmed with the same parameters or the chip will lock up. So G4x0 can't do anisotropic filtering with dual texturing :( Now I need to change the ddx driver to tell the 3D driver if the chipset is a G550. But this causes some compatibility problems. The 3D driver doesn't have a version number so the ddx doesn't know if the 3D driver can handle the new G550 chipset type. Which means that a combination of a new ddx and an old 3D driver won't work. A new 3D driver and an old ddx will work without problems because the G550 doesn't seem to mind being programmed like a G4x0. I'm thinking that I should just ignore the problem because I doubt many people will upgrade the ddx driver and keep the old 3D driver. Any better ideas? Does the kernel have the information you need? We've added 'GetParam' ioctls in the past to query these sorts of details, as the interface is easier to deal with than the X protocol extension used to talk to the DDX driver. If it doesn't have the information, you could also consider adding a 'SetParam' ioctl so that the DDX driver can tell the kernel at init time. Keith --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Major mergedFB rework committed to CVS
Alex Deucher [EMAIL PROTECTED] wrote: I can switch back to the old order in the mean time, however, I'm not sure if it is any more or less reliable than the current code. both work fine on my hardware. I just rebuilt the stuff with a CVS checkout from one hour before now. When I do _not_ explicitly _disable_ MergedFB in XG86Config, the X server spits out this to the log: (II) RADEON(0): Generating MergedFB mode list (II) RADEON(0): No MetaModes given, linking first modes by default (EE) RADEON(0): Failed to parse MetaModes or no modes found. MergeFB mode disabled. (--) RADEON(0): MergedFB: Virtual width 1152 (--) RADEON(0): MergedFB: Virtual height 864 This is exactly the resolution that I expect on my one and only screen of a Radeon7500 - but it does not show up, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Major mergedFB rework committed to CVS
Yeah, I've noticed that as well. If I only comment out the lines regarding MergedFB, it still assumes I want to use MergedFB. I need to explicity tell it not to. Adam On 16 Oct 2003, Martin Spott wrote: Alex Deucher [EMAIL PROTECTED] wrote: I can switch back to the old order in the mean time, however, I'm not sure if it is any more or less reliable than the current code. both work fine on my hardware. I just rebuilt the stuff with a CVS checkout from one hour before now. When I do _not_ explicitly _disable_ MergedFB in XG86Config, the X server spits out this to the log: (II) RADEON(0): Generating MergedFB mode list (II) RADEON(0): No MetaModes given, linking first modes by default (EE) RADEON(0): Failed to parse MetaModes or no modes found. MergeFB mode disabled. (--) RADEON(0): MergedFB: Virtual width 1152 (--) RADEON(0): MergedFB: Virtual height 864 This is exactly the resolution that I expect on my one and only screen of a Radeon7500 - but it does not show up, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding hardware detection to DRI drivers
On Thu, 2003-10-16 at 03:08, Jon Smirl wrote: Same patch again with Matrox PCI IDs fixed and a linux-2.4 port. The patches are almost identical. Both against current bitkeeper source. Can people in the know please check the PCI IDs for the other hardware? I'm fairly sure Radeon, Rage128, and Matrox are right but the others haven't been checked. For radeonfb, I'm moving away from linux pci_ids.h list. It's just too much hell to keep in sync and is always a patch reject nightmare... At least for now, and until it's finished, my new radeonfb uses a separate file I stuffed in drivers/video/aty/ that contains a copy of XFree ATI PCI IDs. I may go back to pci_ids.h once the driver is complete enough, but I'd prefer not doing so, that would help keeping in sync with XFree. BTW. Another problem I've been reported recently, at least on one case, the BIOS ROM wasn't properly read on an x86 (signature was 0). I have to investigate more, but since the old driver worked, I tend to think the memory image may have been correct. I wonder about allowing for some kind of fallback here... Ben. --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] driver comparison
On Thu, 2003-10-16 at 03:49, Roland Scheidegger wrote: And to get this fully on-topic, is there a specific reason why the dri driver is quite a bit slower (up to 50% in some subtests) in SpecViewPerf compared to the cvs version of july? I wonder if it could be related to recent 2D driver changes, in particular the new bandwidth management code; that was only committed a couple of days ago though. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] driver comparison
On Thu, Oct 16, 2003 at 12:51:20PM +0200, Michel Dänzer wrote: On Thu, 2003-10-16 at 03:49, Roland Scheidegger wrote: And to get this fully on-topic, is there a specific reason why the dri driver is quite a bit slower (up to 50% in some subtests) in SpecViewPerf compared to the cvs version of july? I wonder if it could be related to recent 2D driver changes, in particular the new bandwidth management code; that was only committed a couple of days ago though. I'm suspicious of this too, as it has a specific entry for XF86DRI where it utilizes the AGP mode (for some reason) to calculate some of the values. But only on specific chips... Strange. Alan. --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Thu, 2003-10-16 at 08:36, Alex Deucher wrote: Log message: Clean up of the mode validation code for MergedFB. Does it behave the same as pre-MergedFB by default now? Also enable MergedFB autoconfig which will automatically set the virtual desktop size and/or metamodes if you forget to specify them. Also added MergedFBAuto option which will automatically run single head or dualhead depending on whether it detects one or two attached monitors. Is that option really needed? Shouldn't that be the default? PS: The name of Option NoMergedXinerama is broken. The option handling code will automatically treat NoXXX as XXX off. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] driver comparison
Michel Dnzer wrote: On Thu, 2003-10-16 at 03:49, Roland Scheidegger wrote: And to get this fully on-topic, is there a specific reason why the dri driver is quite a bit slower (up to 50% in some subtests) in SpecViewPerf compared to the cvs version of july? I wonder if it could be related to recent 2D driver changes, in particular the new bandwidth management code; that was only committed a couple of days ago though. No, this can't be possible, the bandwidth management code was commited on the 12th or 13th October to dri cvs (unless parts of it were submitted earlier?) but the cvs version used for this article was from the 8th October. For the record, a cvs version from yesterday seems to be just as fast as that from 8th October (in specviewperf light-06), so the bandwidth code doesn't seem to affect performance too much. The performance drop happens really only in the subtests which deal with wireframes. Roland --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Adding hardware detection to DRI drivers
On Thu, 2003-10-16 at 00:13, Eric Anholt wrote: Seems like we need a set-understood-version ioctl. What I'm imagining is an ioctl that takes in a DRM interface version and/or card-specific DRM interface version. It can then adjust its response to other ioctls appropriately. It would return the maximum of those versions that are understood (which is sort of a duplicate of the current version ioctl, but the generic DRM interface version is the new part). There would be a hook for the card-specific part of the DRM to get this understood version information, too, which may help in dealing with the radeon issues that have been discussed. If you mean the memory layout transition, that won't need this. Does this seem like a good idea? It might still be useful otherwise though. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding hardware detection to DRI drivers
Would he be interested in contributing his work back? or maybe explaining how/if he got it working? Alex --- Martin Spott [EMAIL PROTECTED] wrote: Ville Syrj?l? [EMAIL PROTECTED] wrote: On Wed, Oct 15, 2003 at 03:48:38PM -0700, Alex Deucher wrote: there's also this driver: http://www.instmath.rwth-aachen.de:8000/linux/G450-PCI/ I'm not sure how the G4/550 and G200 differ in regard to PCI vs. AGP... AFAIK G450 PCI cards have an AGP-PCI bridge on the card which could do address translation just like the AGP GART. G200/G400 don't have that bridge. I'm not sure if the agpgart driver in that link you posted uses that bridge or some generic PCI GART stuff available on some architectures. Hey, the guy's a good friend of mine - but he never told me he was tweaking DRI stuff I'm pretty shure he wrote the driver for use on his UP2000 Alpha mainboard he used for visualization purpose, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
--- Michel D�nzer [EMAIL PROTECTED] wrote: On Thu, 2003-10-16 at 08:36, Alex Deucher wrote: Log message: Clean up of the mode validation code for MergedFB. Does it behave the same as pre-MergedFB by default now? I haven't put back the old clone code, although the code that's there should work (it's an almost identical code path, the only real difference is how the crtc2 modes are stored in the driver). It works for me, but it may not work perfectly for others. This was mostly a clean up I've been working on for a while. Unfortunately, it still crashes when you run mergedfb mode without libint10.a. I haven't been able to track that down yet. Also enable MergedFB autoconfig which will automatically set the virtual desktop size and/or metamodes if you forget to specify them. Also added MergedFBAuto option which will automatically run single head or dualhead depending on whether it detects one or two attached monitors. Is that option really needed? Shouldn't that be the default? Yeah, I guess it should :) it was late, when I finally got it working. I'll make that the default tonight. PS: The name of Option NoMergedXinerama is broken. The option handling code will automatically treat NoXXX as XXX off. I'll take a look. thanks, Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Thu, 2003-10-16 at 15:41, Alex Deucher wrote: --- Michel Dnzer [EMAIL PROTECTED] wrote: On Thu, 2003-10-16 at 08:36, Alex Deucher wrote: Log message: Clean up of the mode validation code for MergedFB. Does it behave the same as pre-MergedFB by default now? I haven't put back the old clone code, although the code that's there should work (it's an almost identical code path, the only real difference is how the crtc2 modes are stored in the driver). It works for me, but it may not work perfectly for others. It's less important which code it is, so long as it behaves the same by default, which obviously wasn't the case. Is this fixed now? -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding hardware detection to DRI drivers
On Thu, Oct 16, 2003 at 06:30:53AM -0700, Alex Deucher wrote: Would he be interested in contributing his work back? or maybe explaining how/if he got it working? I'll ask him - he moved to southern Germany earlier this year, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding hardware detection to DRI drivers
Alex Deucher [EMAIL PROTECTED] wrote: Would he be interested in contributing his work back? or maybe explaining how/if he got it working? Sorry, currently he's forced to finish his dissertation. He says you might have to wait at least a month until he'll be able to deal with that, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
IIRC, the radeon driver still uses AGP writeback. This doesn't work reliably on my system and I disabled it in my local tree. Some people (including myself) have been thinking about an efficient algorithm to detect unreliable writeback, but AFAICT nobody came up with anything yet (at least no implementation). Should we just disable it for good? Regards, Felix On Thu, 16 Oct 2003 07:18:52 -0700 Michel Daenzer [EMAIL PROTECTED] wrote: CVSROOT: /cvs/dri Module name: xc Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/ Changes by: [EMAIL PROTECTED] 03/10/16 07:18:52 Log message: * Introduce COMMIT_RING() as in radeon DRM, stop using error prone writeback for ring read pointer (Paul Mackerras) * Get rid of some superfluous stuff, minor fixes Modified files: xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/: r128_cce.c r128_drv.h r128_state.c Revision ChangesPath 1.12 +9 -30 xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/r128_cce.c 1.10 +32 -25 xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/r128_drv.h 1.10 +24 -8 xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/r128_state.c --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-patches mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-patches __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
Felix Kühling wrote: IIRC, the radeon driver still uses AGP writeback. This doesn't work reliably on my system and I disabled it in my local tree. Some people (including myself) have been thinking about an efficient algorithm to detect unreliable writeback, but AFAICT nobody came up with anything yet (at least no implementation). Should we just disable it for good? How often do we actually look at the read pointer? It's only really useful for detecting an empty ring, and we have other registers for that. The other time it's examined is for a *full* ring. If we read it lazily, and only when the ring appears to fill, that actually wouldn't be that many reads. Keith --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding hardware detection to DRI drivers
--- Michel Dänzer [EMAIL PROTECTED] wrote: On Thu, 2003-10-16 at 03:08, Jon Smirl wrote: [...] a linux-2.4 port. The patches are almost identical. For DRI CVS we need a single patch which works everywhere, see drm_os_linux.h for examples how this is handled for other stuff. The code didn't change any I just moved it around to make it apply to 2.4. You wanted to know it worked with 2.4. I will do another patch against DRI CVS when everything is stable. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mga anisotropic filtering
On Thu, Oct 16, 2003 at 09:29:36AM +0100, Keith Whitwell wrote: Now I need to change the ddx driver to tell the 3D driver if the chipset is a G550. But this causes some compatibility problems. The 3D driver doesn't have a version number so the ddx doesn't know if the 3D driver can handle the new G550 chipset type. Which means that a combination of a new ddx and an old 3D driver won't work. A new 3D driver and an old ddx will work without problems because the G550 doesn't seem to mind being programmed like a G4x0. I'm thinking that I should just ignore the problem because I doubt many people will upgrade the ddx driver and keep the old 3D driver. Any better ideas? Does the kernel have the information you need? Not at the moment. I can change the ddx to pass the information to the drm. We've added 'GetParam' ioctls in the past to query these sorts of details, as the interface is easier to deal with than the X protocol extension used to talk to the DDX driver. If it doesn't have the information, you could also consider adding a 'SetParam' ioctl so that the DDX driver can tell the kernel at init time. Ok. I can do it without a SetParam ioctl because the mga drm init struct already includes a field for the chip type. I'll just have to make the drm handle the new G550 chip type and add the GetParam ioctl stuff. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding hardware detection to DRI drivers
On Wed, 2003-10-15 at 18:08, Jon Smirl wrote: Same patch again with Matrox PCI IDs fixed and a linux-2.4 port. The patches are almost identical. Both against current bitkeeper source. Can people in the know please check the PCI IDs for the other hardware? I'm fairly sure Radeon, Rage128, and Matrox are right but the others haven't been checked. I'm still working on cleaning the PCI ID stuff up to be portable, which I'll commit as soon as I test (I'm trying to get a multihead setup going to see if there are problems with that as Michel Daenzer brought up). Notably, I'm not using pci_ids.h and instead using the values themselves as has been done in the BSD drivers. I believe I have all the correct PCI IDs, but I'll take another look against your list. Is there any value in the families enum that's being associated with each pci id? After that I'll see how hard the versioning ioctl thing would be to try to save us needing to add too many new ioctls for smallish changes like these. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding hardware detection to DRI drivers
no worries... I was just curious. --- Martin Spott [EMAIL PROTECTED] wrote: Alex Deucher [EMAIL PROTECTED] wrote: Would he be interested in contributing his work back? or maybe explaining how/if he got it working? Sorry, currently he's forced to finish his dissertation. He says you might have to wait at least a month until he'll be able to deal with that, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Multiple VTs with DRI
On Tue, Oct 14, 2003 at 09:22:33PM -0700, Jon Smirl wrote: --- Alex Deucher [EMAIL PROTECTED] wrote: As I recall, no. As it is now, only a single instance of Xfree86 can use the DRI. I think it might be possible by adapting the resume code to reinitialize state and agp on a VT switch, however, I may be wrong. Alex Am I right in thinking that suspend/resume and VT switch should be the same piece of code with slightly different behavior? Does the suspend/resume code save all of the texture memory and AGP state? Or does it rebuild it? Your right Jon. The resume code gets enabled when the DRI is enabled and is executed during a VT switch. Alan. --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding hardware detection to DRI drivers
On Thu, 2003-10-16 at 12:41, Jon Smirl wrote: --- Eric Anholt [EMAIL PROTECTED] wrote: I'm still working on cleaning the PCI ID stuff up to be portable, which I'll commit as soon as I test (I'm trying to get a multihead setup going to see if there are problems with that as Michel Daenzer brought up). Notably, I'm not using pci_ids.h and instead using the values themselves as has been done in the BSD drivers. I believe I have all the correct PCI IDs, but I'll take another look against your list. Is there any value in the families enum that's being associated with each pci id? Right now the drivers have a bunch of ifs/PCI-ID to compute families. Once we get the PCI ID thing working we can slowly remove the ifs and switch to the family enums. Families are more important for some chips (radeon) than others. The radeon driver already uses the family enum to tell secondary from primary adapters. This is done so that linux PCI utlities will show the Radeon driver as owning both devices. GET_SUGGESTED should be modified to return the family enum too. Then we could remove the PCI ID's and ifs in the radeon DSO that are recomputing the family. I think it is better to keep the family data in the PCI ID table than to scatter it all over the code base via if/PCI-ID. You're talking about the DRM here? Because that's all I was looking at, and I don't see drivers doing cases based on pci id data (checked radeon/mga, don't remember it happening in the others) as much as being passed family information from userland. I'll add a driver private field to the pci id list struct I was using and set it to NULL in the lists. Then we can convert the usage of userland-passed family info to family info from the kernel. Is it worth having a separate probe routine just to have the Linux PCI utilities show the driver as owning the secondary adapter as well? As it is, none of the drivers needed a separate probe routine. After that I'll see how hard the versioning ioctl thing would be to try to save us needing to add too many new ioctls for smallish changes like these. Another idea would be to deprecate SET_UNIQUE/GET_UNIQUE and then recover the IOCTL numbers ten years from now. I really hope that we can come to some agreement on being able to deprecate DRM features after a certain time span or number of releases or something. I think having defined versions will help with that. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] weird corruption with r200
Before I go grepping through the tree, where would I find this code (in the DRM, DRI, or 2D)? Also is it for r100 or r200 or both? is there a r200_cp_dispatch_clear()? thanks, Alex --- Michel Dänzer [EMAIL PROTECTED] wrote: On Tue, 2003-10-14 at 06:44, Alex Deucher wrote: I've uploaded some screenshots as an example: http://www.botchco.com/alex/2048-error/ the new version of xscreensaver displays a separate instance on each head of a xinerama desktop. so in this case only the context running up again the 2048 limit (the right side) shows the error. When I turn off xinerama or run an older version of xscreensaver the corruption shown on the right side of the above images shows across the entire screen. Looks like a clearing problem. you can see there seems to be remnants of old whales and glxgears overlayed on the new scene. Doesn't look like what I'd expect if clears didn't work though, but you may still want to start digging in radeon_cp_dispatch_clear(). -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] cool merge/diff app
I just noticed this app today: http://meld.sourceforge.net/index.html Looks pretty nice. Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] R300 specs and drivers.
I'm curious if Tungsten Graphics has made any attempts to get basic 3D specs from ATI for the R300 line of cards? While is certainly great that ATI is showing a commitment to writing their own 3D drivers for linux, there are still other operating systems (and users who insist on open source drivers) that would benefit from having the specs available. Adam --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] driver comparison
On Thu, 2003-10-16 at 23:17, Roland Scheidegger wrote: btw why exactly isn't it possible to hot-swap (when xfree86 is running) the dri driver (r200_dri.so)? This kinda works, but kwm, kicker kwhatever insists on crashing shortly afterwards :-( Weird, when you do what exactly? I've never had problems with that. (I don't use KDE, but I fail to see how that would matter) -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R300 specs and drivers.
On Thu, Oct 16, 2003 at 05:42:15PM -0400, Adam K Kirchhoff wrote: I'm curious if Tungsten Graphics has made any attempts to get basic 3D specs from ATI for the R300 line of cards? While is certainly great that ATI is showing a commitment to writing their own 3D drivers for linux, there are still other operating systems (and users who insist on open source drivers) that would benefit from having the specs available. Not to speak about non x86 architectures, especially the new Apple powerbooks with radeon mobility 9600 would benefit from it. Friendly, Sven Luther --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] driver comparison
Keith Whitwell wrote: Alex Deucher wrote: As I recall KDE preloads libGL for some reason. that might have something to do with it. If you make sure that the old driver.so file is removed, not overwritten, there shouldn't be any problem, as existing open filehandles won't then see any changes. Yes! That did it. Sure enough, fuser shows a dozen kdeinit (and kalarmd, korgac) using libGL.so.1.2 and r200_dri.so. I'm not sure if the XFree86 install was designed with installation over a *running* system in mind, so I don't know if this is happening already or not. Well, I've never tried to install the whole XFree86 when it's running, but I'm often lazy and just compile the mesa/src/drv/r200 if only small changes happen and copy the r200_dri.so manually. But as you suggested, if I'll delete the installed r200_dri.so before copying the new one, then no crashes happen - the running kde happily keeps its references to the old deleted dri driver and new apps will use the new dri driver. Roland --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Adding hardware detection to DRI drivers
On Thu, 2003-10-16 at 03:08, Jon Smirl wrote: [...] a linux-2.4 port. The patches are almost identical. For DRI CVS we need a single patch which works everywhere, see drm_os_linux.h for examples how this is handled for other stuff. What about the other points I raised? Anyway, it seems Eric will look into this. -- Michel Dnzer [EMAIL PROTECTED] wrote: How does standalone Mesa handle video modes etc.? [...] Plan is to do it in user space like Xfree does. Same for cursor support. A new daemon then, or will clients need to run as root? -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI proprietary modules
On Thu, 2003-10-16 at 19:12, Dave Jones wrote: On Thu, Oct 16, 2003 at 04:46:44PM -0400, John Dennis wrote: Does anybody know for the proprietary drivers (supplied by ATI and Nvidia) which pieces they replace and which pieces they expect to be there? The reason I'm asking is to understand the consequences of changing an API. I'm curious to the answer in general, but in this specific instance the api I'm worried about is between the agpgart kernel module and drm kernel module. If the agpgart kernel module modifies it's API will that break things for someone who installs a proprietary 3D driver? Do the proprietary drivers limit themselves to mesa driver and retain the existing kernel services assuming the IOCTL's are the same? Or do they replace the kernel drm drivers as well? If so do they manage AGP themselves, or do they use the systems agpgart driver? Do they replace the systems agpgart driver? NVIDIA driver can optionally use the kernel agpgart, but also has its own built-in. ATI always use their own agpgart afair. Change the agpgart API, and they will likely break. ATI can optionally use kernel agpgart with Option UseInternalAGPGART no signature.asc Description: This is a digitally signed message part
Re: [Dri-devel] DRI proprietary modules
On Thu, Oct 16, 2003 at 04:46:44PM -0400, John Dennis wrote: Does anybody know for the proprietary drivers (supplied by ATI and Nvidia) which pieces they replace and which pieces they expect to be there? The reason I'm asking is to understand the consequences of changing an API. I'm curious to the answer in general, but in this specific instance the api I'm worried about is between the agpgart kernel module and drm kernel module. If the agpgart kernel module modifies it's API will that break things for someone who installs a proprietary 3D driver? Do the proprietary drivers limit themselves to mesa driver and retain the existing kernel services assuming the IOCTL's are the same? Or do they replace the kernel drm drivers as well? If so do they manage AGP themselves, or do they use the systems agpgart driver? Do they replace the systems agpgart driver? NVIDIA driver can optionally use the kernel agpgart, but also has its own built-in. ATI always use their own agpgart afair. Change the agpgart API, and they will likely break. Dave -- Dave Jones http://www.codemonkey.org.uk --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI proprietary modules
For DRI to work correctly there are several independent pieces that all have to be in sync. * XFree86 server which loads drm modules (via xfree86 driver module) * The drm kernel module * The agpgart kernel module Does anybody know for the proprietary drivers (supplied by ATI and Nvidia) which pieces they replace and which pieces they expect to be there? The reason I'm asking is to understand the consequences of changing an API. I'm curious to the answer in general, but in this specific instance the api I'm worried about is between the agpgart kernel module and drm kernel module. If the agpgart kernel module modifies it's API will that break things for someone who installs a proprietary 3D driver? Do the proprietary drivers limit themselves to mesa driver and retain the existing kernel services assuming the IOCTL's are the same? Or do they replace the kernel drm drivers as well? If so do they manage AGP themselves, or do they use the systems agpgart driver? Do they replace the systems agpgart driver? -- John Dennis [EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
