From: Dieter <Die...@ha...> - 2001-12-09 22:31:31
|
Am Sonntag, 9. Dezember 2001 22:01 schrieben Sie: > Sorry if this is a duplicate: It's been 8 hours or more, and I havent seen > a copy of my email to the list. > > I'm looking to write a driver that implements /dev/agpgart, as a first step > towards doing a full DRI port. > > Trouble is, I cant seem to find anything that USES the device any more. > In Xfree 3.x only the intel i810 drivers seem to have it. > > in Xfree4, os-support/lnx_agp.c has it.... but nothing seems to use the > related > > xf86AgpGARTSupported|xf86GetAGPInfo|xf86AcquireGART|xf86AllocateGARTMemory > > routines, besides the i810 driver again. > > [which I think is really wierd, because I thought AGP was this huge win > on memory access speed, so I was assuming everything that could use it, > would use it] > > > So: suggestions for programs that use /dev/agpgart, so I can test on a > reasonable scale? There was a reply to your first post: [-] Hello Have you checked that your AGP module is correctly loaded ? If so, I suggest that you compile and run (as root, and before running X) the C program located at : http://ltswww.epfl.ch/~aspert/patches/testgart.c Send the output of the program to the list... Best regards Nicolas. [-] Have a nice 2. Advent. -Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science @home: Die...@ha... |
From: Philip B. <ph...@bo...> - 2001-12-10 00:34:31
|
On Sun, Dec 09, 2001 at 11:29:53PM +0100, Dieter Nützel wrote: > ... > Have you checked that your AGP module is correctly loaded ? > If so, I suggest that you compile and run (as root, and before running X) the > C program located at : > http://ltswww.epfl.ch/~aspert/patches/testgart.c > > Send the output of the program to the list... Well, unfortunately, the driver isnt THAT far along :-) I'm also using that test program you gave me, as a bit more documentation as to how agpgart is used. I havent come across a document that describes, "This is how you use /dev/agpgart at the user/developer level" |
From: <vo...@mi...> - 2001-12-10 05:30:27
|
On Sun, 9 Dec 2001, Philip Brown wrote: > On Sun, Dec 09, 2001 at 11:29:53PM +0100, Dieter N=FCtzel wrote: > > ... > > Have you checked that your AGP module is correctly loaded ? > > If so, I suggest that you compile and run (as root, and before running = X) the > > C program located at : > > http://ltswww.epfl.ch/~aspert/patches/testgart.c > >=20 > > Send the output of the program to the list... >=20 > Well, unfortunately, the driver isnt THAT far along :-) > I'm also using that test program you gave me, as a bit more documentation > as to how agpgart is used. I havent come across a document that describes= , > "This is how you use /dev/agpgart at the user/developer level" And this is true about the kernel-level API as well. I have just figured out that agp_memory_t.memory field is an array of addresses to allocated pages - but I have not figured out whether these are physical or not. Some comments ala <linux/fs.h> would be quite helpful. Vladimir Dergachev >=20 >=20 > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel >=20 |
From: Derrik P. <dp...@ds...> - 2001-12-10 06:59:51
|
On Sun, 9 Dec 2001, Philip Brown wrote: > Well, unfortunately, the driver isnt THAT far along :-) > I'm also using that test program you gave me, as a bit more documentation > as to how agpgart is used. I havent come across a document that describes, > "This is how you use /dev/agpgart at the user/developer level" Well, I don't think that anyone developing AGP GART support thought a lot about that - usually, apps aren't going to be talking directly to the AGP GART, but via some sort of abstraction layer, like DRI. Which, from what I gather, is what you're trying to port away from X... Derrik Pates | Sysadmin, Douglas School | #linuxOS on EFnet dp...@ds... | District (dsdk12.net) | #linuxOS on OPN |
From: Philip B. <ph...@bo...> - 2001-12-10 05:06:20
|
On Sun, Dec 09, 2001 at 10:00:07PM -0700, Derrik Pates wrote: > ... > Well, I don't think that anyone developing AGP GART support thought a lot > about that - usually, apps aren't going to be talking directly to the AGP > GART, but via some sort of abstraction layer, like DRI. Which, from what I > gather, is what you're trying to port away from X... Well, no, I'm not trying to "port it away from X". I'm just looking for a straightforward way to test it, and make sure I'm implementing it the way it needs to be. Whether internal or external, it's still always a good idea to document use of an API. |
From: Philip B. <ph...@bo...> - 2001-12-10 08:39:58
|
So I'm looking through the AGP stuff, still learning... and it seems that there's a whole lot of redundancy in the current API. If I'm understanding the sequence properly, generally programs do the following: 1. open /dev/agpgart 2. ioctl(ACQUIRE) 3. ioctl(INFO) to determine amountof memory for AGP 4. mmap the device 5. ioctl(SETUP) to set the AGP mode 6. ioctl(ALLOCATE) a chunk o memory, specifying offset in aperture 7. ioctl(BIND) that same chunk o memory The allocate and bind parts seem to be useless, since the program has to call mmap() anyway [right?] Seems to me that programs could perfectly well just mmap the whole chunk of memory at once and do what they like to it. The agpgart driver could then automatically update the GATT table (which I still havent fully figured out, admittedly) The allocate and bind calls could just be implicitly done through the mmap call. What am I missing? Just the "physical" address return, which could perfectly easily be done through an agp_allocate() call that would otherwise do nothing, I think. ? |
From: Abraham vd M. <ab...@2d...> - 2001-12-10 10:03:06
|
Hi Philip! > So I'm looking through the AGP stuff, still learning... > and it seems that there's a whole lot of redundancy in the current API. >=20 > If I'm understanding the sequence properly, generally programs do the > following: > 1. open /dev/agpgart > 2. ioctl(ACQUIRE) > 3. ioctl(INFO) to determine amountof memory for AGP > 4. mmap the device > 5. ioctl(SETUP) to set the AGP mode > 6. ioctl(ALLOCATE) a chunk o memory, specifying offset in aperture > 7. ioctl(BIND) that same chunk o memory >=20 > The allocate and bind parts seem to be useless, since the program has > to call mmap() anyway [right?]=20 >=20 > Seems to me that programs could perfectly well just mmap the whole chunk = of > memory at once and do what they like to it. > The agpgart driver could then automatically update the GATT table > (which I still havent fully figured out, admittedly) > The allocate and bind calls could just be implicitly done through the > mmap call. > What am I missing? It is not always necessary to memory map the device. For instance with the I810 driver, just plain 2D, there is no need to mmap the device, but the GTT (or GATT if you wish) must be populated because the card has no onboard memory and by default. Since the ALLOCATE ioctl() allocates physical memory and the BIND ioctl() populates the GTT, the process looks like this: open /dev/agpgart ioctl(INFO ioctl(ACQUIRE) =2E =2E =2E ioctl(ALLOCATE) ioctl(BIND) =2E =2E =2E (see xc/programs/Xserver/hw/xfree86/drivers/i810/i810_memory.c for details) > Just the "physical" address return, which could perfectly easily be done > through an agp_allocate() call that would otherwise do nothing, I think. > ? Sometimes, the X driver needs to know the _physical_ location of the page which it allocates. For instance, there is 2 cases where the I810 series of chips need this information: 1) hardware cursor and 2) if you want to use the hardware status page and not do the silly spin until head =3D=3D tail f= or the ring buffer (which btw is the way the Linux driver does this right now). That is why the agpgart module provides a way to get the physcal location of a page. --=20 Regards Abraham You roll my log, and I will roll yours. -- Lucius Annaeus Seneca __________________________________________________________ Abraham vd Merwe - 2d3D, Inc. Device Driver Development, Outsourcing, Embedded Systems Cell: +27 82 565 4451 Snailmail: Tel: +27 21 761 7549 Block C, Antree Park Fax: +27 21 761 7648 Doncaster Road Email: ab...@2d... Kenilworth, 7700 Http: http://www.2d3d.com South Africa |
From: Philip B. <ph...@bo...> - 2001-12-10 17:56:10
|
On Mon, Dec 10, 2001 at 12:05:47PM +0200, Abraham vd Merwe wrote: > ... > It is not always necessary to memory map the device. For instance with the > I810 driver, just plain 2D, there is no need to mmap the device, but the GTT > (or GATT if you wish) must be populated because the card has no onboard > memory and by default. Since the ALLOCATE ioctl() allocates physical memory > and the BIND ioctl() populates the GTT, the process looks like this: ... Errr.... wonder how xfree86 works with i810 currently under solaris then, since there is currently no AGP driver for solaris. > > Just the "physical" address return, which could perfectly easily be done > > through an agp_allocate() call that would otherwise do nothing, I think. > > ? > > Sometimes, the X driver needs to know the _physical_ location of the page > which it allocates. For instance, there is 2 cases where the I810 series of > chips need this information: 1) hardware cursor and 2) if you want to use > the hardware status page and not do the silly spin until head == tail for > the ring buffer (which btw is the way the Linux driver does this right now). > That is why the agpgart module provides a way to get the physcal location of > a page. Right, I read that code. [otherwise, I wasnt going to return the physical addr at all :-)] So if I provided that through the agp_allocate() return, but had already allocated the memory for the entire aperture beforehand... sounds like it would work fine? |
From: Keith W. <kei...@ya...> - 2001-12-11 09:28:27
|
Philip Brown wrote: > > On Mon, Dec 10, 2001 at 12:05:47PM +0200, Abraham vd Merwe wrote: > > ... > > It is not always necessary to memory map the device. For instance with the > > I810 driver, just plain 2D, there is no need to mmap the device, but the GTT > > (or GATT if you wish) must be populated because the card has no onboard > > memory and by default. Since the ALLOCATE ioctl() allocates physical memory > > and the BIND ioctl() populates the GTT, the process looks like this: ... > > Errr.... wonder how xfree86 works with i810 currently under solaris then, > since there is currently no AGP driver for solaris. Is that our problem or solaris' ? There are ways of kludging around not having an agp driver, the XFree 3.3 driver included some of them, but they're ugly and in the end no simpler than just doing agp support properly. Keith _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Gareth H. <gar...@ac...> - 2001-12-10 17:19:25
|
On Mon, Dec 10, 2001 at 12:39:57AM -0800, Philip Brown wrote: > So I'm looking through the AGP stuff, still learning... > and it seems that there's a whole lot of redundancy in the current API. > > If I'm understanding the sequence properly, generally programs do the > following: > 1. open /dev/agpgart > 2. ioctl(ACQUIRE) > 3. ioctl(INFO) to determine amountof memory for AGP > 4. mmap the device > 5. ioctl(SETUP) to set the AGP mode > 6. ioctl(ALLOCATE) a chunk o memory, specifying offset in aperture > 7. ioctl(BIND) that same chunk o memory > > The allocate and bind parts seem to be useless, since the program has > to call mmap() anyway [right?] Every time you update the GATT, you have to flush the cache and/or TLBs. This is expensive. Therefore, you allocate and bind the pages you'll use, and mmap() just returns the right pages when needed. -- Gareth |
From: Philip B. <ph...@bo...> - 2001-12-10 17:50:43
|
On Mon, Dec 10, 2001 at 09:19:16AM -0800, Gareth Hughes wrote: > On Mon, Dec 10, 2001 at 12:39:57AM -0800, Philip Brown wrote: > > So I'm looking through the AGP stuff, still learning... > > and it seems that there's a whole lot of redundancy in the current API. > > ... > > The allocate and bind parts seem to be useless, since the program has > > to call mmap() anyway [right?] > > Every time you update the GATT, you have to flush the cache and/or > TLBs. This is expensive. Therefore, you allocate and bind the pages > you'll use, and mmap() just returns the right pages when needed. But I thought that GATT is simply a scatter/gather table, so you only have to update the GATT when you "allocate and bind" pages. Then, if you "allocate and bind" the whole range at once, you're done, and you dont have to do any cache flushing from that point on. So sounds like you are agreeing with me?? :-> |
From: Daryll S. <da...@ha...> - 2001-12-10 17:56:30
|
On Mon, Dec 10, 2001 at 09:50:42AM -0800, Philip Brown wrote: > But I thought that GATT is simply a scatter/gather table, so > you only have to update the GATT when you "allocate and bind" pages. > Then, if you "allocate and bind" the whole range at once, you're done, and > you dont have to do any cache flushing from that point on. > So sounds like you are agreeing with me?? :-> The interface was developed with input from XFree86, nVidia, and Xi Graphics. It is also intended to support architectures other than x86. Therefore this is a nice general solution to the problem. - |Daryll |
From: Philip B. <ph...@bo...> - 2001-12-10 18:06:45
|
On Mon, Dec 10, 2001 at 09:56:28AM -0800, Daryll Strauss wrote: > On Mon, Dec 10, 2001 at 09:50:42AM -0800, Philip Brown wrote: > > But I thought that GATT is simply a scatter/gather table, so > > you only have to update the GATT when you "allocate and bind" pages. > > Then, if you "allocate and bind" the whole range at once, you're done, and > > you dont have to do any cache flushing from that point on. > > So sounds like you are agreeing with me?? :-> > > The interface was developed with input from XFree86, nVidia, and Xi > Graphics. It is also intended to support architectures other than > x86. Therefore this is a nice general solution to the problem. Fair enough, as far as architecture goes. But since I'm only coding a back-end for solaris, which only has AGP on x86, do you see a problem with me IMPLEMENTING it this way? :-) |
From: David D. <dawes@XFree86.Org> - 2001-12-10 18:59:30
|
On Mon, Dec 10, 2001 at 10:06:45AM -0800, Philip Brown wrote: >On Mon, Dec 10, 2001 at 09:56:28AM -0800, Daryll Strauss wrote: >> On Mon, Dec 10, 2001 at 09:50:42AM -0800, Philip Brown wrote: >> > But I thought that GATT is simply a scatter/gather table, so >> > you only have to update the GATT when you "allocate and bind" pages. >> > Then, if you "allocate and bind" the whole range at once, you're done, and >> > you dont have to do any cache flushing from that point on. >> > So sounds like you are agreeing with me?? :-> >> >> The interface was developed with input from XFree86, nVidia, and Xi >> Graphics. It is also intended to support architectures other than >> x86. Therefore this is a nice general solution to the problem. > >Fair enough, as far as architecture goes. >But since I'm only coding a back-end for solaris, which only has AGP on >x86, do you see a problem with me IMPLEMENTING it this way? :-) Here is the XFree86 point of view: If you want the result to be usable with XFree86, then just make sure that it will fit in with the AGP abstractions provided in XFree86's os-support layer. XFree86 drivers that need AGP GART functionality, like the i810 driver, use solely those interfaces. You can hide the OS-specific details in the Solaris part of the XFree86 os-support lyaer. David -- David Dawes Email: dawes@XFree86.org Founder/President, Release Engineer Phone: +1 570 764 0288 The XFree86 Project, Inc http://www.xfree86.org/~dawes |
From: <vo...@mi...> - 2001-12-10 18:08:44
|
On Mon, 10 Dec 2001, Daryll Strauss wrote: > On Mon, Dec 10, 2001 at 09:50:42AM -0800, Philip Brown wrote: > > But I thought that GATT is simply a scatter/gather table, so > > you only have to update the GATT when you "allocate and bind" pages. > > Then, if you "allocate and bind" the whole range at once, you're done, and > > you dont have to do any cache flushing from that point on. > > So sounds like you are agreeing with me?? :-> > > The interface was developed with input from XFree86, nVidia, and Xi > Graphics. It is also intended to support architectures other than > x86. Therefore this is a nice general solution to the problem. Is it possible to change it to allow more than one driver to acquire agp_backend at once ? I need this for a video capture driver. Vladimir Dergachev > > - |Daryll > > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |
From: Gareth H. <gar...@ac...> - 2001-12-10 18:03:08
|
On Mon, Dec 10, 2001 at 09:50:42AM -0800, Philip Brown wrote: > > But I thought that GATT is simply a scatter/gather table, so > you only have to update the GATT when you "allocate and bind" pages. > Then, if you "allocate and bind" the whole range at once, you're done, and > you dont have to do any cache flushing from that point on. > So sounds like you are agreeing with me?? :-> Yes. Hence, the "allocate and bind" part *is* necessary, which contradicts your statement that only the mmap() was needed and that allocate/bind was redundant. -- Gareth |
From: Benjamin H. <be...@ke...> - 2001-12-10 18:08:27
|
>On Mon, Dec 10, 2001 at 09:19:16AM -0800, Gareth Hughes wrote: >> On Mon, Dec 10, 2001 at 12:39:57AM -0800, Philip Brown wrote: >> > So I'm looking through the AGP stuff, still learning... >> > and it seems that there's a whole lot of redundancy in the current API. >> > ... >> > The allocate and bind parts seem to be useless, since the program has >> > to call mmap() anyway [right?] >> >> Every time you update the GATT, you have to flush the cache and/or >> TLBs. This is expensive. Therefore, you allocate and bind the pages >> you'll use, and mmap() just returns the right pages when needed. > >But I thought that GATT is simply a scatter/gather table, so >you only have to update the GATT when you "allocate and bind" pages. >Then, if you "allocate and bind" the whole range at once, you're done, and >you dont have to do any cache flushing from that point on. >So sounds like you are agreeing with me?? :-> Please, beware of another problem with AGP. Several chipsets including Apple's UniNorth or some ia64 ones can't let the CPU access the AGP aperture. So the kernel has to map real physical memory pages into the process space when mmap'ing bits of the aperture. That makes very difficult to handle unbind when other processes already map part of the aperture. We got it to work properly with the in kernel AGP API by hacking both agpgart and the DRM, and since most DRI drivers actually allocate the whole AGP memory once and don't touch it. Ben. |
From: Philip B. <ph...@bo...> - 2001-12-10 19:01:08
|
On Mon, Dec 10, 2001 at 07:14:15PM +0100, Benjamin Herrenschmidt wrote: > ... > Please, beware of another problem with AGP. Several chipsets including > Apple's UniNorth or some ia64 ones can't let the CPU access the AGP > aperture. So the kernel has to map real physical memory pages into > the process space when mmap'ing bits of the aperture. There's another way? :-/ My reading of the drivers so far made it seem like an agp driver HAS to do all of: 1. allocate actual RAM when an ioctl(ALLOC) is done 2. "bind" it by making an entry in the GATT when ioctl(BIND) is done 3. mmap the RAM in step #1 to userspace when an mmap() is requested. But you seem to imply there's a more direct method possible? |
From: Benjamin H. <be...@ke...> - 2001-12-10 19:49:21
|
>There's another way? :-/ >My reading of the drivers so far made it seem like an agp driver HAS to do >all of: > >1. allocate actual RAM when an ioctl(ALLOC) is done >2. "bind" it by making an entry in the GATT when ioctl(BIND) is done >3. mmap the RAM in step #1 to userspace when an mmap() is requested. > >But you seem to imply there's a more direct method possible? Some chipsets (and the original agpgart supported those only) can let the CPU access the AGP aperture directly. All mmap had to do was then to map the user pages to the aperture physical pages, if they had memory bound or not didn't matter. Ben. |
From: Philip B. <ph...@bo...> - 2001-12-10 20:09:40
|
On Mon, Dec 10, 2001 at 08:52:26PM +0100, Benjamin Herrenschmidt wrote: > ... > Some chipsets (and the original agpgart supported those only) can > let the CPU access the AGP aperture directly. All mmap had to do > was then to map the user pages to the aperture physical pages, > if they had memory bound or not didn't matter. Chipsets of the motherboard, or chipset of the card? Does the agp code still support that type of direct mapping for those cards, and could you point me to the place in the driver code where that is done? It looks like the latest linux agpgart_be.c only uses gatt tables, which seems to imply it doesnt do the "direct" mapping any more ? [ugh. its tough wading through the linux code: there are waaay too many #define shortcut()s ] |
From: Benjamin H. <be...@ke...> - 2001-12-11 08:46:52
|
>Chipsets of the motherboard, or chipset of the card? >Does the agp code still support that type of direct mapping for those >cards, and could you point me to the place in the driver code where that is >done? >It looks like the latest linux agpgart_be.c only uses gatt tables, which >seems to imply it doesnt do the "direct" mapping any more ? > >[ugh. its tough wading through the linux code: there are waaay too > many #define shortcut()s ] Depends on the host AGP chipset, not the card. So far, the userland ioctl API can only mmap the physical aperture, not RAM pages, so it doesn't work with chipsets that don't support this feature. The stock DRM doesn't neither, only patched versions to support that mapping of RAM pages work and only with the in-kernel agpgart API. Ben. |
From: Philip B. <ph...@bo...> - 2001-12-11 01:33:15
|
On Mon, Dec 10, 2001 at 08:52:26PM +0100, Benjamin Herrenschmidt wrote: > ... > Some chipsets (and the original agpgart supported those only) can > let the CPU access the AGP aperture directly. All mmap had to do > was then to map the user pages to the aperture physical pages, > if they had memory bound or not didn't matter. waitamint... I just read http://developer.intel.com/design/intarch/techinfo/440BX/addrmap.htm which describes the AGP Graphics Aperture, as the "AGP Dram Graphics Aperture". Which means 'A way for the AGP device to access main RAM'. All this time I thought it was a way for programs to access the RAM on-board the card! Well that clears things up a bit :-/ But... isnt there a straightforward mmap type way to access the RAM on board the card, then? Or is it usually "load the data to the aperture, then copy it into card-local RAM from there" ? [or via the "drmDMA" stuff, I suppose?] |
From: Gareth H. <gar...@ac...> - 2001-12-11 01:53:41
|
On Mon, Dec 10, 2001 at 05:33:09PM -0800, Philip Brown wrote: > On Mon, Dec 10, 2001 at 08:52:26PM +0100, Benjamin Herrenschmidt wrote: > > ... > > Some chipsets (and the original agpgart supported those only) can > > let the CPU access the AGP aperture directly. All mmap had to do > > was then to map the user pages to the aperture physical pages, > > if they had memory bound or not didn't matter. > > waitamint... I just read > http://developer.intel.com/design/intarch/techinfo/440BX/addrmap.htm > > which describes the AGP Graphics Aperture, as the > "AGP Dram Graphics Aperture". > > Which means 'A way for the AGP device to access main RAM'. > All this time I thought it was a way for programs to access the RAM > on-board the card! > Well that clears things up a bit :-/ > > But... isnt there a straightforward mmap type way to access the RAM on > board the card, then? > Or is it usually "load the data to the aperture, then copy it > into card-local RAM from there" ? > [or via the "drmDMA" stuff, I suppose?] Why do you want to touch the framebuffer (video memory, that is)? That's one way to make your 3D graphics go really slowly... AGP was designed to let the graphics processor pull data from system memory, instead of having the CPU push data out. -- Gareth |
From: Philip B. <ph...@bo...> - 2001-12-11 02:06:11
|
On Mon, Dec 10, 2001 at 05:53:32PM -0800, Gareth Hughes wrote: > On Mon, Dec 10, 2001 at 05:33:09PM -0800, Philip Brown wrote: > > ... > > But... isnt there a straightforward mmap type way to access the RAM on > > board the card, then? > > Or is it usually "load the data to the aperture, then copy it > > into card-local RAM from there" ? > > [or via the "drmDMA" stuff, I suppose?] > > Why do you want to touch the framebuffer (video memory, that is)? > That's one way to make your 3D graphics go really slowly... I dont know... I'm new at all this :-) I just figured that since it only takes about 8 megs of RAM to hold all the pixels for high-res 24-bit displays, then if a card has 32 megs of RAM or higher, then programs have to be doing something interesting with the rest of the ram. I thought under 2d, it gets used for sprites, and other various cached pixmaps. So in 3d, it got used to store textures or something. So I'd better know how to enable access to it, if I want to implement DRI on my platform. > AGP was designed to let the graphics processor pull data from system > memory, instead of having the CPU push data out. Good to know ;-) |
From: Keith W. <kei...@ya...> - 2001-12-11 09:25:11
|
Philip Brown wrote: > > On Mon, Dec 10, 2001 at 05:53:32PM -0800, Gareth Hughes wrote: > > On Mon, Dec 10, 2001 at 05:33:09PM -0800, Philip Brown wrote: > > > ... > > > But... isnt there a straightforward mmap type way to access the RAM on > > > board the card, then? > > > Or is it usually "load the data to the aperture, then copy it > > > into card-local RAM from there" ? > > > [or via the "drmDMA" stuff, I suppose?] > > > > Why do you want to touch the framebuffer (video memory, that is)? > > That's one way to make your 3D graphics go really slowly... > > I dont know... I'm new at all this :-) > > I just figured that since it only takes about 8 megs of RAM to hold all the > pixels for high-res 24-bit displays, then if a card has 32 megs of RAM or > higher, then programs have to be doing something interesting with the rest > of the ram. > I thought under 2d, it gets used for sprites, and other various cached > pixmaps. So in 3d, it got used to store textures or something. > So I'd better know how to enable access to it, if I want to implement DRI > on my platform. Just look at /proc/pci or similar on a linux box. All the pci cards have memory ranges assigned to them - that's where your on-card memory lives in the physical address space. The pci bus hardware diverts memory accesses in this range to the appropriate card. But don't use it if you can avoid it, as Gareth mentioned, because it is as slow as a dog. Keith _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |