From: Antoine R. <are...@tu...> - 2003-07-26 23:40:39
|
Hi, I just compiled dri from the CVS for my radeon 9000 Mobbility card (r250 lf) and it wont work as good as it is expected to (I.E : 30 fps in Quake3) The thing is when i do a glxinfo it is reported as a r200 chip which it isn't... So i'd like to know if you are aware of this and what solutions do i have. I also wanted to know if support should be better or if this is normal. For information i'm running Gentoo linux 1.4_RC4 with 2.4.21-ac3 patched kernel (patched for the mmu_cr4 problem) I'm running Xfree 4.3.0. If you need more informations let me know. Thanks in advance and thanks for doing such a great job. Bye. |
From: Michel <mi...@da...> - 2003-07-27 09:53:03
|
On Sun, 2003-07-27 at 01:39, Antoine REVERSAT wrote: > Hi, > I just compiled dri from the CVS for my radeon 9000 Mobbility card > (r250 lf) and it wont work as good as it is expected to (I.E : 30 > fps in Quake3) The thing is when i do a glxinfo it is reported as a > r200 chip which it isn't... But it is, as far as the 3D driver is concerned. > For information i'm running Gentoo linux 1.4_RC4 with 2.4.21-ac3 > patched kernel (patched for the mmu_cr4 problem) I'm running Xfree > 4.3.0. The driver from current DRI CVS should be better. Other things to try are running at lower resolution and/or depth. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer |
From: Antoine R. <are...@tu...> - 2003-07-27 10:32:18
|
Le 27 Jul 2003 11:53:00 +0200 Michel D=E4nzer <mi...@da...> =E0 =E9crit : > On Sun, 2003-07-27 at 01:39, Antoine REVERSAT wrote: > > Hi,=20 > > I just compiled dri from the CVS for my radeon 9000 Mobbility card=20 > > (r250 lf) and it wont work as good as it is expected to (I.E : 30=20 > > fps in Quake3) The thing is when i do a glxinfo it is reported as a=20 > > r200 chip which it isn't...=20 >=20 > But it is, as far as the 3D driver is concerned. >=20 >=20 > > For information i'm running Gentoo linux 1.4_RC4 with 2.4.21-ac3=20 > > patched kernel (patched for the mmu_cr4 problem) I'm running Xfree=20 > > 4.3.0. >=20 > The driver from current DRI CVS should be better. >=20 > Other things to try are running at lower resolution and/or depth. >=20 Performances should be way better even in thsi resolution/depth (with the c= losed source ati drivers i get 60 fps at quake3) so this shouldn't be the f= ix for the problem... >=20 > --=20 > Earthling Michel D=E4nzer \ Debian (powerpc), XFree86 and DRI developer > Software libre enthusiast \ http://svcs.affero.net/rm.php?r=3Ddaenzer >=20 >=20 >=20 > ------------------------------------------------------- > 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/psa00100003ave/direct;at.aspnet_072303_01/= 01 > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel |
From: Ian R. <id...@us...> - 2003-07-30 01:07:02
Attachments:
r200_device_id.patch
|
Antoine REVERSAT wrote: > I just compiled dri from the CVS for my radeon 9000 Mobbility card (r250 lf) and it wont work as good as it is expected to (I.E : 30 fps in Quake3) The thing is when i do a glxinfo it is reported as a r200 chip which it isn't... So i'd like to know if you are aware of this and what solutions do i have. I also wanted to know if support should be better or if this is normal. > For information i'm running Gentoo linux 1.4_RC4 with 2.4.21-ac3 patched kernel (patched for the mmu_cr4 problem) I'm running Xfree 4.3.0. > If you need more informations let me know. Here's a patch that should clear some of that up, at least for the R200-family of chips. I did change the code to include xf86PciInfo.h. In spite of the comment there, it doesn't seem to produce any errors. Is this a safe change to make? Also, do we really need to check the device ID against R100-family IDs in the R200 driver? Anyway, if this is acceptable I'll expand it to include the R100 driver & commit it. |
From: Michel <mi...@da...> - 2003-07-30 13:25:51
|
On Wed, 2003-07-30 at 03:06, Ian Romanick wrote: > Antoine REVERSAT wrote: > > > I just compiled dri from the CVS for my radeon 9000 Mobbility card (r250 lf) and it wont work as good as it is expected to (I.E : 30 fps in Quake3) The thing is when i do a glxinfo it is reported as a r200 chip which it isn't... So i'd like to know if you are aware of this and what solutions do i have. I also wanted to know if support should be better or if this is normal. > > For information i'm running Gentoo linux 1.4_RC4 with 2.4.21-ac3 patched kernel (patched for the mmu_cr4 problem) I'm running Xfree 4.3.0. > > If you need more informations let me know. > > Here's a patch that should clear some of that up, at least for the > R200-family of chips. I did change the code to include xf86PciInfo.h. > In spite of the comment there, it doesn't seem to produce any errors. > Is this a safe change to make? Also, do we really need to check the > device ID against R100-family IDs in the R200 driver? Apparently, people do try to use the wrong drivers on the Mesa embedded and whatnot branches... Is this change really needed or even useful? I suspect this will only serve to produce more 'my chip isn't properly detected!' reports when it doesn't make any difference for the driver operation. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer |
From: Ian R. <id...@us...> - 2003-07-31 05:49:40
|
Michel D=C3=A4nzer wrote: > On Wed, 2003-07-30 at 03:06, Ian Romanick wrote: >=20 >>Antoine REVERSAT wrote: >> >> >>>I just compiled dri from the CVS for my radeon 9000 Mobbility card (r2= 50 lf) and it wont work as good as it is expected to (I.E : 30 fps in Qua= ke3) The thing is when i do a glxinfo it is reported as a r200 chip which= it isn't... So i'd like to know if you are aware of this and what soluti= ons do i have. I also wanted to know if support should be better or if th= is is normal. >>>For information i'm running Gentoo linux 1.4_RC4 with 2.4.21-ac3 patch= ed kernel (patched for the mmu_cr4 problem) I'm running Xfree 4.3.0. >>>If you need more informations let me know. >> >>Here's a patch that should clear some of that up, at least for the=20 >>R200-family of chips. I did change the code to include xf86PciInfo.h.=20 >>In spite of the comment there, it doesn't seem to produce any errors.=20 >>Is this a safe change to make? Also, do we really need to check the=20 >>device ID against R100-family IDs in the R200 driver? >=20 > Apparently, people do try to use the wrong drivers on the Mesa embedded > and whatnot branches... How can that be? The user has to select which 3D driver to use (i.e.,=20 the 2D driver doesn't select it for them)? What's to stop someone with=20 an R200 from "selecting" the MGA driver? > Is this change really needed or even useful? I suspect this will only > serve to produce more 'my chip isn't properly detected!' reports when i= t > doesn't make any difference for the driver operation. It's certainly not "needed," but *I* think it's useful. :) Dunno... |
From: Michel <mi...@da...> - 2003-07-31 11:46:05
|
On Thu, 2003-07-31 at 07:49, Ian Romanick wrote: > Michel Dänzer wrote: > > > On Wed, 2003-07-30 at 03:06, Ian Romanick wrote: > > > >>[...] do we really need to check the > >>device ID against R100-family IDs in the R200 driver? > > > > Apparently, people do try to use the wrong drivers on the Mesa embedded > > and whatnot branches... > > How can that be? The user has to select which 3D driver to use (i.e., > the 2D driver doesn't select it for them)? What's to stop someone with > an R200 from "selecting" the MGA driver? I don't know how things are supposed to work on those branches, but someone asked whether radeon_dri.so was the correct driver for an RV250 chip, as it didn't work correctly. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer |
From: Keith W. <ke...@tu...> - 2003-07-31 15:49:13
|
Ian Romanick wrote: > Michel D=C3=A4nzer wrote: >=20 >> On Wed, 2003-07-30 at 03:06, Ian Romanick wrote: >> >>> Antoine REVERSAT wrote: >>> >>> >>>> I just compiled dri from the CVS for my radeon 9000 Mobbility card=20 >>>> (r250 lf) and it wont work as good as it is expected to (I.E : 30=20 >>>> fps in Quake3) The thing is when i do a glxinfo it is reported as a=20 >>>> r200 chip which it isn't... So i'd like to know if you are aware of=20 >>>> this and what solutions do i have. I also wanted to know if support=20 >>>> should be better or if this is normal. >>>> For information i'm running Gentoo linux 1.4_RC4 with 2.4.21-ac3=20 >>>> patched kernel (patched for the mmu_cr4 problem) I'm running Xfree=20 >>>> 4.3.0. >>>> If you need more informations let me know. >>> >>> >>> Here's a patch that should clear some of that up, at least for the=20 >>> R200-family of chips. I did change the code to include=20 >>> xf86PciInfo.h. In spite of the comment there, it doesn't seem to=20 >>> produce any errors. Is this a safe change to make? Also, do we=20 >>> really need to check the device ID against R100-family IDs in the=20 >>> R200 driver? >> >> >> Apparently, people do try to use the wrong drivers on the Mesa embedde= d >> and whatnot branches... >=20 >=20 > How can that be? The user has to select which 3D driver to use (i.e.,=20 > the 2D driver doesn't select it for them)? What's to stop someone with= =20 > an R200 from "selecting" the MGA driver? There's no 2D driver. It would be simple to add some checking to ensure the chipid is recognize= d by=20 the 3d driver, just hasn't been done yet. Keith |
From: Ian R. <id...@us...> - 2003-07-31 16:20:15
|
Keith Whitwell wrote: > Ian Romanick wrote: >=20 >> Michel D=C3=A4nzer wrote: >> >>> On Wed, 2003-07-30 at 03:06, Ian Romanick wrote: >>> >>>> Here's a patch that should clear some of that up, at least for the=20 >>>> R200-family of chips. I did change the code to include=20 >>>> xf86PciInfo.h. In spite of the comment there, it doesn't seem to=20 >>>> produce any errors. Is this a safe change to make? Also, do we=20 >>>> really need to check the device ID against R100-family IDs in the=20 >>>> R200 driver? >>> >>> Apparently, people do try to use the wrong drivers on the Mesa embedd= ed >>> and whatnot branches... >> >> How can that be? The user has to select which 3D driver to use (i.e.,= =20 >> the 2D driver doesn't select it for them)? What's to stop someone=20 >> with an R200 from "selecting" the MGA driver? >=20 > There's no 2D driver. That makes sense. Duh. > It would be simple to add some checking to ensure the chipid is=20 > recognized by the 3d driver, just hasn't been done yet. Let me work up a patch that does this in a more generally way. The=20 current big switch-statement is somewhat unpleasant. Do the embedded=20 drivers have a header file where they get PCI IDs? I assume that=20 xf86PciInfo.h is not available. :) |
From: Keith W. <ke...@tu...> - 2003-07-31 16:49:03
|
>> It would be simple to add some checking to ensure the chipid is >> recognized by the 3d driver, just hasn't been done yet. > > > Let me work up a patch that does this in a more generally way. The > current big switch-statement is somewhat unpleasant. Do the embedded > drivers have a header file where they get PCI IDs? I assume that > xf86PciInfo.h is not available. :) We should probably just import it. Keith |
From: Sven L. <sve...@wa...> - 2003-08-01 05:44:04
|
On Thu, Jul 31, 2003 at 09:02:08AM -0700, Ian Romanick wrote: > Keith Whitwell wrote: > > >Ian Romanick wrote: > > > >>Michel Dänzer wrote: > >> > >>>On Wed, 2003-07-30 at 03:06, Ian Romanick wrote: > >>> > >>>>Here's a patch that should clear some of that up, at least for the > >>>>R200-family of chips. I did change the code to include > >>>>xf86PciInfo.h. In spite of the comment there, it doesn't seem to > >>>>produce any errors. Is this a safe change to make? Also, do we > >>>>really need to check the device ID against R100-family IDs in the > >>>>R200 driver? > >>> > >>>Apparently, people do try to use the wrong drivers on the Mesa embedded > >>>and whatnot branches... > >> > >>How can that be? The user has to select which 3D driver to use (i.e., > >>the 2D driver doesn't select it for them)? What's to stop someone > >>with an R200 from "selecting" the MGA driver? > > > >There's no 2D driver. > > That makes sense. Duh. > > >It would be simple to add some checking to ensure the chipid is > >recognized by the 3d driver, just hasn't been done yet. > > Let me work up a patch that does this in a more generally way. The > current big switch-statement is somewhat unpleasant. Do the embedded > drivers have a header file where they get PCI IDs? I assume that > xf86PciInfo.h is not available. :) Notice that in order to more easily build 2D drivers of the CVS branch with the latest released stable driver SDK, it makes more sense to move the pci id information out of the xf86PciInfo.h file and into each individual drivers. With the new (well, new as in 4.x or something such) driver architecture, the xf86PciInfo.h is not really needed anymore, since each driver knows how to detect supported cards himself. Maybe doing something similar for the 3D drivers would be a step in the right direction, instead of importing the monolitic xf86PciInfo.h file. BTW, what about the drm modules, do they recognize the hardware also, or do they not care about being loaded or not. Friendly, Sven Luther |
From: Ian R. <id...@us...> - 2003-08-01 16:33:18
|
Sven Luther wrote: > On Thu, Jul 31, 2003 at 09:02:08AM -0700, Ian Romanick wrote: >>Keith Whitwell wrote: >> >>>It would be simple to add some checking to ensure the chipid is >>>recognized by the 3d driver, just hasn't been done yet. >> >>Let me work up a patch that does this in a more generally way. The >>current big switch-statement is somewhat unpleasant. Do the embedded >>drivers have a header file where they get PCI IDs? I assume that >>xf86PciInfo.h is not available. :) > > Notice that in order to more easily build 2D drivers of the CVS branch > with the latest released stable driver SDK, it makes more sense to move > the pci id information out of the xf86PciInfo.h file and into each > individual drivers. With the new (well, new as in 4.x or something such) > driver architecture, the xf86PciInfo.h is not really needed anymore, > since each driver knows how to detect supported cards himself. > > Maybe doing something similar for the 3D drivers would be a step in the > right direction, instead of importing the monolitic xf86PciInfo.h file. Agreed. The direction I plan to go is have a Python script that will process pci.ids and generate a table using the data there (much like is done in the Linux kernel's PCI driver). Basically, the table will be of structures like so: struct driPCIInfoRec { uint_fast16_t device_id; uint_fast16_t device_vendor; uint_fast16_t subsystem_id; uint_fast16_t subsystem_vendor; const char * device_name; const char * device_driver; union { int i; void * p; } device_data; }; The script will pull the first 5 fields from pci.ids, and the remaining 2 will be supplied as parameters. The last field could store things like G200 vs. G400 for the MGA driver, or TCL vs. no-TCL for the Radeon driver, etc. Where would we want such a script to live in the tree? We wouldn't want it to run as part of the build process because pci.ids may not always be available. We'd want to "periodically" run the script against an known good pci.ids to generate the .h files for each driver and commit the new .h files. There are some scripts like that in Mesa, but I don't think they exist in the DRI tree. This does make one subtle, but VERY important change to the policy carried out by the driver's init function. Right now all of the drivers will try to run even if they don't recognize the PCI ID. If we go this route, that will change. If a device ID isn't in the table, the driver will bail. Given what Keith and Michel had said about the embedded branch, I think this is the better way to go. Thoughts? The nice part about doing it this way is that, as new devices come out, we just have to make sure that pci.ids is up to date (a good idea anyway!) and regenerate / commit the .h files for the drivers. I had shared Michel's maintainence worries over the old switch-statement based approach, and I think this solves that. > BTW, what about the drm modules, do they recognize the hardware also, or > do they not care about being loaded or not. I think they check, but I'm not sure. I'd have to look. |
From: Keith W. <ke...@tu...> - 2003-08-01 16:52:58
|
>> BTW, what about the drm modules, do they recognize the hardware also, or >> do they not care about being loaded or not. > > > I think they check, but I'm not sure. I'd have to look. I don't think so. The FreeBSD varients have a table of pci ids, but that's got a lot to do with the FreeBSD device model. The linux ones just let it all hang out, I think. Keith |
From: Ian R. <id...@us...> - 2003-08-02 03:31:01
|
Ian Romanick wrote: > Sven Luther wrote: > >> On Thu, Jul 31, 2003 at 09:02:08AM -0700, Ian Romanick wrote: >> >>> Keith Whitwell wrote: >>> >>>> It would be simple to add some checking to ensure the chipid is >>>> recognized by the 3d driver, just hasn't been done yet. >>> >>> >>> Let me work up a patch that does this in a more generally way. The >>> current big switch-statement is somewhat unpleasant. Do the >>> embedded drivers have a header file where they get PCI IDs? I assume >>> that xf86PciInfo.h is not available. :) >> >> >> Notice that in order to more easily build 2D drivers of the CVS branch >> with the latest released stable driver SDK, it makes more sense to move >> the pci id information out of the xf86PciInfo.h file and into each >> individual drivers. With the new (well, new as in 4.x or something such) >> driver architecture, the xf86PciInfo.h is not really needed anymore, >> since each driver knows how to detect supported cards himself. >> >> Maybe doing something similar for the 3D drivers would be a step in the >> right direction, instead of importing the monolitic xf86PciInfo.h file. > > > Agreed. The direction I plan to go is have a Python script that will > process pci.ids and generate a table using the data there (much like is > done in the Linux kernel's PCI driver). Basically, the table will be of > structures like so: > > struct driPCIInfoRec { > uint_fast16_t device_id; > uint_fast16_t device_vendor; > uint_fast16_t subsystem_id; > uint_fast16_t subsystem_vendor; > > const char * device_name; > const char * device_driver; > > union { > int i; > void * p; > } device_data; > }; > > The script will pull the first 5 fields from pci.ids, and the remaining > 2 will be supplied as parameters. The last field could store things > like G200 vs. G400 for the MGA driver, or TCL vs. no-TCL for the Radeon > driver, etc. > > Where would we want such a script to live in the tree? We wouldn't want > it to run as part of the build process because pci.ids may not always be > available. We'd want to "periodically" run the script against an known > good pci.ids to generate the .h files for each driver and commit the new > .h files. There are some scripts like that in Mesa, but I don't think > they exist in the DRI tree. > > This does make one subtle, but VERY important change to the policy > carried out by the driver's init function. Right now all of the drivers > will try to run even if they don't recognize the PCI ID. If we go this > route, that will change. If a device ID isn't in the table, the driver > will bail. Given what Keith and Michel had said about the embedded > branch, I think this is the better way to go. Thoughts? > > The nice part about doing it this way is that, as new devices come out, > we just have to make sure that pci.ids is up to date (a good idea > anyway!) and regenerate / commit the .h files for the drivers. I had > shared Michel's maintainence worries over the old switch-statement based > approach, and I think this solves that. Okay, here it is. r200_pci_info.h was generated by gen_pci_info.py using r200_card_info.txt and a patched version of the 2.6.0-test2 pci.ids file (that patch is also attached). ./gen_pci_info.py r200_card_info.txt \ ~/devel/linux-2.6.0-test2/drivers/pci/pci.ids > r200_pci_info.h We would just need to keep r200_card_info.txt and our favorite pci.ids up-to-date, and the rest is magic. :) The remaining patch modifies the DDX and the DRI driver to exchange PCI information and use that to identify the chip. Is this to everyone's likeing? |
From: Michel <mi...@da...> - 2003-08-01 22:54:53
|
On Fri, 2003-08-01 at 18:33, Ian Romanick wrote: > > This does make one subtle, but VERY important change to the policy > carried out by the driver's init function. Right now all of the drivers > will try to run even if they don't recognize the PCI ID. If we go > this route, that will change. If a device ID isn't in the table, the > driver will bail. Given what Keith and Michel had said about the > embedded branch, I think this is the better way to go. Thoughts? I think the new behaviour should be limited to scenarios where there isn't a 2D driver which knows the correct 3D driver. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer |
From: Alan C. <al...@lx...> - 2003-08-02 13:16:56
|
On Gwe, 2003-08-01 at 23:54, Michel D=C3=A4nzer wrote: > On Fri, 2003-08-01 at 18:33, Ian Romanick wrote: > >=20 > > This does make one subtle, but VERY important change to the policy=20 > > carried out by the driver's init function. Right now all of the driver= s=20 > > will try to run even if they don't recognize the PCI ID. If we go=20 > > this route, that will change. If a device ID isn't in the table, the=20 > > driver will bail. Given what Keith and Michel had said about the=20 > > embedded branch, I think this is the better way to go. Thoughts? >=20 > I think the new behaviour should be limited to scenarios where there > isn't a 2D driver which knows the correct 3D driver. In the Linux world the driver framework for hot plug is going to require the driver knows the right PCI idents to work nicely. The 2.6-test tree however also allows runtime adjustment of tables. |