Re: My experience with the r300 driver
On Thursday 13 October 2005 07:51, Michel Dänzer wrote: There's no question that the override is useful for developers, the question is whether it isn't more harm- than useful for users. I've often thought it'd be nice to have the VideoRAM option in the config file be clamped to the max(user specified, driver probed), with some magic value the driver could specify to say it has no real idea how much vram is available. And, the driver also limits texture memory to only be useable up to 128MB, and I think this is not necessary (as textures are always blitted using the gpu and the memory used by them never touched directly by the cpu) or is it? Indeed, that memory would probably be useful for textures for now, but maybe CPU access to textures in the framebuffer will be necessary in the future? I don't think so. For fixed function cards, the numbers I've been getting while playing with accelerating XGetImage and XPutImage in EXA suggest that even for fairly small updates to offscreen images (about an 8x8 tile update or so), it's faster to download the subimage you're interested in, modify it in host RAM, and re-upload it, than it is to do CPU-driven access directly. XGetImage of XYPixmaps is a good example, where DMAing the pixmap down from the framebuffer and then converting ZPixmap to XYPixmap in host memory is between 3 to 12 times faster than the normal software path. For cards with useful fragment shaders, it'd be really really hot to see the server's fb layer implemented in fragment shaders and do even core X rendering entirely on-card. This is basically the Quartz 2D Extreme model. Again, you need to get this data off the card sometimes for things like glReadPixels or XGetImage, but that should really be done with DMA, or a proper memcpy at minimum. Think of it as manual cache management. Block transfers are fairly quick, and modifying data within a memory domain is really fast, but single-word updates between domains are just painful. So I guess to answer your question, memory outside the BAR is fine to only use for textures, because if the host really wants to modify them it should do so only between DFS and UTS pairs, and presumably the GPU can use its entire address space for DMA sources and targets rather than just only the range visible through the PCI bus aperture. - ajax pgpxozj5uXT8l.pgp Description: PGP signature
Re: My experience with the r300 driver
On Wed, 2005-10-12 at 14:58 +0200, Roland Scheidegger wrote: Michel Dänzer wrote: On Wed, 2005-10-12 at 11:01 +0100, pedro.lixo wrote: By the way, if i do the override that won't do nothing, in terms of amount of memory visible to GPU, right? No, it will only affect what the driver thinks, and if that doesn't correspond with what's actually there and/or the hardware can handle, bad things will happen, which is why the override is usually bad and the patch you encountered which disables it is generally a good idea. Maybe the driver should be changed so it can output a more precise message, so people don't think that the ram is misdetected (e.g. something like detected 256MB, using 128MB). Yeah, that'd be good. Also, the 128MB limit should just not be overridable, since we KNOW the driver can't cope with it (imho, otherwise allowing override is a nice idea, you can for instance simulate performance with cards which have less memory, though you could argue only smaller than detected values are useful, as long as the driver always detects the memory amount correctly). There's no question that the override is useful for developers, the question is whether it isn't more harm- than useful for users. And, the driver also limits texture memory to only be useable up to 128MB, and I think this is not necessary (as textures are always blitted using the gpu and the memory used by them never touched directly by the cpu) or is it? Indeed, that memory would probably be useful for textures for now, but maybe CPU access to textures in the framebuffer will be necessary in the future? -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: My experience with the r300 driver
It's not. The driver limits it to 128 MB because the CPU can't access more than that. Thanks for the information! By the way, if i do the override that won't do nothing, in terms of amount of memory visible to GPU, right? --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: My experience with the r300 driver
On Wed, 2005-10-12 at 11:01 +0100, pedro.lixo wrote: By the way, if i do the override that won't do nothing, in terms of amount of memory visible to GPU, right? No, it will only affect what the driver thinks, and if that doesn't correspond with what's actually there and/or the hardware can handle, bad things will happen, which is why the override is usually bad and the patch you encountered which disables it is generally a good idea. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: My experience with the r300 driver
Michel Dänzer wrote: On Wed, 2005-10-12 at 11:01 +0100, pedro.lixo wrote: By the way, if i do the override that won't do nothing, in terms of amount of memory visible to GPU, right? No, it will only affect what the driver thinks, and if that doesn't correspond with what's actually there and/or the hardware can handle, bad things will happen, which is why the override is usually bad and the patch you encountered which disables it is generally a good idea. Maybe the driver should be changed so it can output a more precise message, so people don't think that the ram is misdetected (e.g. something like detected 256MB, using 128MB). Also, the 128MB limit should just not be overridable, since we KNOW the driver can't cope with it (imho, otherwise allowing override is a nice idea, you can for instance simulate performance with cards which have less memory, though you could argue only smaller than detected values are useful, as long as the driver always detects the memory amount correctly). And, the driver also limits texture memory to only be useable up to 128MB, and I think this is not necessary (as textures are always blitted using the gpu and the memory used by them never touched directly by the cpu) or is it? Roland --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: My experience with the r300 driver
On Mon, Oct 10, 2005 at 10:50:02PM +0200, Roland Scheidegger wrote: This looks like pixmap damage. Are you using exa (not obvious from this forum thread)? If not, does the option XaaNoOffscreenPixmaps help? Thanks alot. That did the trick. Just one question. Is there a way of seeing how much RAM my card has ? Couldn't find anything on dmesg or /proc, and it doesn't display anything during boot. --lf Roland --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: RE: My experience with the r300 driver
-Mensagem original- De: [EMAIL PROTECTED] em nome de Luis Felipe Strano Moraes Enviada: ter 11-10-2005 7:12 Para: dri-devel@lists.sourceforge.net Assunto: Re: My experience with the r300 driver On Mon, Oct 10, 2005 at 10:50:02PM +0200, Roland Scheidegger wrote: This looks like pixmap damage. Are you using exa (not obvious from this forum thread)? If not, does the option XaaNoOffscreenPixmaps help? Thanks alot. That did the trick. Just one question. Is there a way of seeing how much RAM my card has ? Couldn't find anything on dmesg or /proc, and it doesn't display anything during boot. Use this cat /proc/mtrr In this case: you'll have 3 lines First - Size of system memory Second - Size of Bios AGP Aperture Third - Size of Graphic card Memory or cat /var/log/Xorg.0.log |grep VideoRAM to do if XAA is enabled cat /var/log/Xorg.0.log |grep XAA to see if FastWrites is enabled cat /var/log/Xorg.0.log |grep Fast Write By the way are you using latest drm. Try always to use the lates cvs version of Xorg, drm and Mesa. At least with me, i'm not complainig. Once a week total recompile. (Xorg+ drm+ Mesa). i'm using R300 from the beginig of the project (sort of), since the red_tinted_cube snap. No problems so far. I also have a Gecube, but a 9600XT with 256 MB. By the way, why i have to use the override option? I have 256 MB, of memory in the card but X only detects 128MB, it has anything to do with Bios AGP Aperture, or a bug, maybe. Pedro Maia --lf Roland --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: My experience with the r300 driver
On Tue, Oct 11, 2005 at 12:00:03PM +0200, khaqq wrote: This should be in your Xorg.0.log : # cat /var/log/Xorg.0.log | grep VideoRAM (--) RADEON(0): VideoRAM: 131072 kByte (128 bit DDR SDRAM) My card has 256 RAM . I tried to override it, but (II) RADEON(0): VideoRAM override ignored, this driver autodetects RAM (--) RADEON(0): VideoRAM: 131072 kByte (128 bit DDR SDRAM) should it be like this ?? --lf Cheers khaqq --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RE: My experience with the r300 driver
On Tue, Oct 11, 2005 at 10:58:23AM +0100, pedro.lixo wrote: Use this cat /proc/mtrr In this case: you'll have 3 lines First - Size of system memory Second - Size of Bios AGP Aperture Third - Size of Graphic card Memory or cat /var/log/Xorg.0.log |grep VideoRAM The first way gave me 256 . Thanks, didn't know about thtat. to do if XAA is enabled cat /var/log/Xorg.0.log |grep XAA to see if FastWrites is enabled cat /var/log/Xorg.0.log |grep Fast Write By the way are you using latest drm. Try always to use the lates cvs version of Xorg, drm and Mesa. At least with me, i'm not complainig. Once a week total recompile. (Xorg+ drm+ Mesa). I'm using the latest versions. Just installed them yesterday from CVS. i'm using R300 from the beginig of the project (sort of), since the red_tinted_cube snap. No problems so far. I also have a Gecube, but a 9600XT with 256 MB. I'm planning to start a wiki somewhere to help benchmark the drivers, since there's a lot of people that are interested in using them, at least on the gentoo forums. By the way, why i have to use the override option? I have 256 MB, of memory in the card but X only detects 128MB, it has anything to do with Bios AGP Aperture, or a bug, maybe. I've tried to use the override option, but the driver just ignores it : (II) RADEON(0): VideoRAM override ignored, this driver autodetects RAM (--) RADEON(0): VideoRAM: 131072 kByte (128 bit DDR SDRAM) --lf Pedro Maia --lf Roland --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: My experience with the r300 driver
Your Xorg version, is patched with a known patch(at least by me, it's from Mike A. Harris). Are you using gentoo!? Gentoo has this patch, probably also Red Hat and Fedora Core. With that patch, you cannot override. In gentoo just go to xorg-x11-version-patches-patch_version.tar.bz2 , and remove the patch 1214_all_4.3.0-radeon-disable-VideoRAM-option. delete digest and redigest the ebuild. Rebuild xorg-x11. :) With this patch you will only have 128 MB, i dont know how get around! Sorry. Pedro Maia --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: My experience with the r300 driver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 pedro.lixo wrote: | Your Xorg version, is patched with a known patch(at least by me, it's from Mike A. Harris). Are you using gentoo!? | | Gentoo has this patch, probably also Red Hat and Fedora Core. | | With that patch, you cannot override. In gentoo just go to | xorg-x11-version-patches-patch_version.tar.bz2 , and remove the patch | 1214_all_4.3.0-radeon-disable-VideoRAM-option. delete digest and redigest | the ebuild. Rebuild xorg-x11. :) | | With this patch you will only have 128 MB, i dont know how get around! Sorry. Rather than that, why not file an X.Org bug saying that your card's RAM is detected incorrectly (if that is in fact the case). Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDTAuUXVaO67S1rtsRAn31AJ9KIe+bd5NKmSszz86a/Px8o69AGACaAwV8 r+nWohfjM4fhXMfJ8BB59Rw= =W746 -END PGP SIGNATURE- --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: My experience with the r300 driver
Luis Felipe Strano Moraes wrote: Hello, just sending this to describe my experience so far with the open-source r300 drivers. My card is a Radeon 9600Pro with 256 mb ram by Gecube. After installing everything following this tutorial : http://forums.gentoo.org/viewtopic-t-374745-highlight-r300.html I was able to get inside X without problems. But, after a few minutes of use, I started having some problems. Don't know how to describe them very well, so I took screenshots. My screen gets like this : http://www.ic.unicamp.br/~ra016681/Screenshot.png After it gets like that, if I move screens around it gets like this : http://www.ic.unicamp.br/~ra016681/Screenshot-1.png This looks like pixmap damage. Are you using exa (not obvious from this forum thread)? If not, does the option XaaNoOffscreenPixmaps help? Roland --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
