From: Alexander S. <Ale...@at...> - 2001-12-22 01:30:34
|
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:ph...@bo...] > Sent: Saturday, December 22, 2001 01:06 > To: dri...@li... > 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 > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |
From: Sottek, M. J <mat...@in...> - 2001-12-22 04:42:31
|
>However, it does look like AGPIOC_ALLOCATE is broken. It only returns >the ->physical field of the resulting agp_memory structure. It doesn't >even look like this field is set for any chipsets other than the i810 >and i830. You don't need anything other than the "key". This isn't a general purpose memory allocator. The agp memory doesn't have a usable address until you bind it into the gart, and at that point the client tells agpgart where in the gart to put it. It is only accessed through the gart. The "physical" pointer is returned only for a special type of memory where you need to know both the physical address of the page and the location in the gart. Intel's cursor uses this because the cursor takes a full 32 bit address so it can be used in non-gart modes too. >Is /dev/agpgart even supposed to work on Linux? I don't think any >programs use it, and the rest of the kernel used the backend interfaces >directly. It's possible that the frontend has fallen out of sync with >the back. Can anyone here confirm or refute this? The X server uses it when you are not running DRM. -Matt |
From: Alexander S. <Ale...@at...> - 2002-01-07 12:31:33
|
> From: Philip Brown [mailto:ph...@bo...] > I thought that was just from the perspective of the graphics card. A GART memory mapping is a memory range that is visible from the grafics card (if on AGP socket) and from the CPU (or CPUs). The GART memory area is looking just as a PCI card that has mapped some amount of memory to the bus. Its a linear chung of memory in terms of the bus scope and therefore has a physical base address and its range is contiguous on the bus. The grafics card simply uses physical adressing. The CPU muss call the OS to do a remap on those physical range, as it has to do for any other sort of PCI adapter memory. > But you are saying that ALL AGP supporting motherboards will remap > their aperture range, both for the graphics card, AND the cpu? The motherboard chipset do remap a bunch of individual pages into a single GART memory area. Its view is independent and seperate from the regular location of the main memory, there is no overlapping. GART means an aditional view of the same with the advantage of getting memory contiguous for the grafics adapter, even if several could handle fragmentation without that unit. (the CPU already has a sufficient paging unit.) > In which case... doesnt that screw up the OS considerably, to > suddenly have a large chunk of memory change its apparent contents? :-/ If you have multiprocessing, a grafics co-processor, a busmaster or a cpu-external memory manager, then you must flus CPU read or write caches at certain points of modifications in the sub system. > I dont know of any kernel routines under solaris that tell the kernel, > "Stop using this specific physical address range now: I'm going to > take it over" You first allocate pages in main memory before starting to remap them via GART. After use you have to do this in the reverse direction. > Also.. seems like if you have a system that has a large amount of memory, > you would then lose twice the amount of memory you allocate, since a > previously usable chunk of memory now gets shadowed to another section of > memory. You have to mark the memory as used. But its only a single location, so this single memory is useable for exactly one purpose only. Its single but shared, multiple visible, magically mirrored, purple-dotted memory. The only thing that you need in advance is a memory manager, that tracks which ranges of the GART range are used and which are free. > Yeuk. I thought you are called Philip. :-) Regards Alex. |
From: Philip B. <ph...@bo...> - 2001-12-22 01:34:50
|
On Sat, Dec 22, 2001 at 02:30:14AM +0100, Alexander Stohr wrote: > 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. thats what I figured. But then what is the point of returning the starting physical address to the user-space caller? If the user-space asks for 1 meg of memory==256 pages, and gets the physical address of the first page back, but all the oteher 255 pages are non-physically contiguous... then whats the point of returning the physical address of that first block? |
From: Gareth H. <gar...@ac...> - 2001-12-23 21:47:08
|
On Fri, Dec 21, 2001 at 05:34:43PM -0800, Philip Brown wrote: > On Sat, Dec 22, 2001 at 02:30:14AM +0100, Alexander Stohr wrote: > > 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. > > thats what I figured. But then what is the point of returning the > starting physical address to the user-space caller? You return the physical address of the *AGP aperture*, not the first page *in* the aperture. Remember, the AGP aperture is a physically-contiguous block of memory that can have scattered pages mapped into it. Thus, graphics cards can access the memory as one physical range, even though the pages in that range aren't really contiguous. That's the whole point of having a GART remapper... > If the user-space asks for 1 meg of memory==256 pages, > and gets the physical address of the first page back, but > all the oteher 255 pages are non-physically contiguous... then whats the > point of returning the physical address of that first block? Don't do that. Return the physical address of the aperture, which the user-space process can map into it's virtual address space. Then, both the client and graphics card can talk to the same block of memory -- client through the virtual mapping, hardware through the AGP GART remapping. -- Gareth |
From: Philip B. <ph...@bo...> - 2001-12-24 19:25:20
|
On Sun, Dec 23, 2001 at 01:46:56PM -0800, Gareth Hughes wrote: > > You return the physical address of the *AGP aperture*, not the first > page *in* the aperture. Remember, the AGP aperture is a > physically-contiguous block of memory that can have scattered pages > mapped into it. Thus, graphics cards can access the memory as one > physical range, even though the pages in that range aren't really > contiguous. That's the whole point of having a GART remapper... Oh, right. I was reading about the 82443, and how it can intercept requests for physical ranges, and remap to what the GATT indicates. I thought that was just from the perspective of the graphics card. But you are saying that ALL AGP supporting motherboards will remap their aperture range, both for the graphics card, AND the cpu? In which case... doesnt that screw up the OS considerably, to suddenly have a large chunk of memory change its apparent contents? :-/ I dont know of any kernel routines under solaris that tell the kernel, "Stop using this specific physical address range now: I'm going to take it over" :-/ Also.. seems like if you have a system that has a large amount of memory, you would then lose twice the amount of memory you allocate, since a previously usable chunk of memory now gets shadowed to another section of memory. Yeuk. |