The GART is the paging unit of the AGP system. It deals nicely with fragmented chunks of page sized memory chunks. So you only need some sort of memory allocation and a way to determine eachs pages physical adress to use it for those GART purposes.
You just need to ensure that your memory is permanent, which means its neither moved around in physical memory nor swapped to harddisk. And you can have some 2GB gart range whilst you only have a few 100 MB real physical ram in your machine. The idea is to provide as much linearly rearanged memory space so that all your one or two gart clients do have enough linear space to remap to. Regards Alex. > -----Original Message----- > From: Philip Brown [mailto:[EMAIL PROTECTED]] > Sent: Saturday, December 22, 2001 01:06 > To: [EMAIL PROTECTED] > Subject: [Dri-devel] agp: what if memory is fragmented? > > > Sorry if this is repeat: haven't seen my original show up in 12 hours. > > I have a question about "what if physical memory is fragmented"? > The AGIPIOC_ALLOC call returns a 'physical' address. > This implies that the ALLOC is a single contiguous chunk of physical > memory. Right? > > However, I cant imagine that it is easy to guarantee 64 megs > of contiguous > physical RAM allocation. So something seems wrong with my assumption. > > > I've looked at the bsd AGP source, and it uses "malloc()", > and some fancy > bsd magic that I dont understand. > Similarly, I do not understand the linux page allocation stuff at all. > > > So, what should be the behaviour of my agp implementation, if > contiguous > physical memory is not available? > I would think it should not be neccessary: thats why the GATT > exists, after > all?! > > _______________________________________________ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
