From: Alexander S. <Ale...@at...> - 2001-12-17 21:52:45
|
> On Mon, Dec 17, 2001 at 01:10:36PM -0800, Chris Ahna wrote: > > ... > > The GATT table format is chipset specific, you'll have to check a > > chipset specific datasheet. > > okay... does anyone know where I can get the intel format from, then? > I've been looking at > http://developer.intel.com/design/intarch/techinfo/440BX/HostPCI.htm > > but havent found one yet. Try this page: http://developer.intel.com/design/chipsets/datashts/index.htm and if it doesnt show you all those stuff - go to AMD because they do nicely explain their two level GART system. It helped me a lot to get finally familiar with the topic. Anyways, you might consider reading open source like existing 440BX coding in agpgart in order to see what is required. |
From: Alexander S. <Ale...@at...> - 2001-12-18 12:07:29
|
> From: Philip Brown [mailto:ph...@bo...] > On Mon, Dec 17, 2001 at 10:52:04PM +0100, Alexander Stohr wrote: > > ... > > Try this page: > > http://developer.intel.com/design/chipsets/datashts/index.htm > > I found what seems to be the only document relevant to my AGP > programming > issue, > "440BX AGPset: 82443BX Host Bridge/Controller Datasheet" > > which is > http://developer.intel.com/design/chipsets/datashts/29063301.pdf > > of which I eyeball-scanned through its 132 pages > (skipping the electrical signals section) > and while I saw mention of the function of the GATT, nowhere did I see > specification of the FORMAT of the GATT. arrg. exactly this i meant and this i remembered about the documentation. > > and if it doesnt show you all those stuff - go to AMD because > > they do nicely explain their two level GART system. It helped > > me a lot to get finally familiar with the topic. > > but how does learning how to program AMD hardware, help me to > program the > Intel 82443 hardware that I actually have in my possesion? :-/ Yes, my suggestion sounds weired, but isn't. AMD is categories better in explaining the table structure of the terminal GATT tables - the principle meaning of the bits is identical to those that Intel does use. so you can understand the agpgart programming of the intel chipsets by having read the AMD documentation. just keep in mind that intel does not have that intermediate level of a gatt table directory in its main memory. regards, Alex. |
From: Philip B. <ph...@bo...> - 2001-12-22 00:06:02
|
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?! |
From: Chris A. <chr...@in...> - 2001-12-22 03:26:52
|
On Fri, Dec 21, 2001 at 04:05:33PM -0800, Philip Brown wrote: > 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. AGP memory is not allocated contiguously (check the calls to agp_bridge. agp_alloc_page in agp_allocate_memory). 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. 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? Chris |
From: Abraham vd M. <ab...@2d...> - 2001-12-22 07:52:23
|
Hi Chris! > > 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? > >=20 > > However, I cant imagine that it is easy to guarantee 64 megs of contigu= ous > > physical RAM allocation. So something seems wrong with my assumption. >=20 > AGP memory is not allocated contiguously (check the calls to agp_bridge. > agp_alloc_page in agp_allocate_memory). >=20 > 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. That's because it's not necessary. The user can only get the physical pointer if he/she does an ALLOC with type > 0 which is a chip specific ALLOC and it is up to the driver to implement these types or not. > 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? Of course it's used. It essential for some X drivers such as i8xx series chips. There is nothing wrong with the frontend either. --=20 Regards Abraham Those who educate children well are more to be honored than parents, for these only gave life, those the art of living well. -- Aristotle __________________________________________________________ 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: Abraham vd M. <ab...@2d...> - 2001-12-22 07:59:16
|
Hi Philip! > Sorry if this is repeat: haven't seen my original show up in 12 hours. >=20 > I have a question about "what if physical memory is fragmented"? > The AGIPIOC_ALLOC call returns a 'physical' address. Not always. Only if the alloc type > 0 (which is chip specific). Otherwise, you're not getting a physical address (you'll see the driver don't even set this field). In the case of i8xx where it is used (maybe others as well), there is usually a limit to the size (e.g. one page). You have to remember that this extension was only introduced to help out with some hardware where X requires a physical pointer (e.g. hardware cursor / hardware status page with i8xx) > However, I cant imagine that it is easy to guarantee 64 megs of contiguous > physical RAM allocation. So something seems wrong with my assumption. In the case of generic allocs (type 0), memory is allocated in chunks of single pages, so fragmentation is not an issue. > So, what should be the behaviour of my agp implementation, if contiguous > physical memory is not available? Then you're screwed. You need at least a couple of pages of physical contigious memory for the GTT (or GATT if you wish) table. The entries only needs to be single pages (see agp_generic_alloc (otoh, might be spelled differently). The rest is virtual addresses (e.g. the array in which the allocated pages is stored, etc.) --=20 Regards Abraham There is no education that is not political. An apolitical education is also political because it is purposely isolating. __________________________________________________________ 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: Daryll S. <da...@ha...> - 2001-12-22 00:18:01
|
On Fri, Dec 21, 2001 at 04:05:33PM -0800, Philip Brown wrote: > 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?! IIRC, you're in trouble. AGP memory has to be continuous. Jeff always recommended you build the AGP code into the kernel to make sure it happened early enough. In practice loading it dynamically works. - |Daryll |
From: Keith W. <kei...@ya...> - 2001-12-22 17:28:03
|
Daryll Strauss wrote: > > On Fri, Dec 21, 2001 at 04:05:33PM -0800, Philip Brown wrote: > > 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?! > > IIRC, you're in trouble. AGP memory has to be continuous. Jeff always > recommended you build the AGP code into the kernel to make sure it > happened early enough. In practice loading it dynamically works. I think you're talking about different things (at least I hope you are)... The point of agp is to provide a second address space in which discontiguous pages of physical memory appear to the cpu and bus to be contiguous. Think of it as a 'virtual address space' for the graphics card. AGP is needed precisely because contiguous memory is hard to find and manage in modern operating systems. Thus agp allows you to stitch together all your discontiguous little bits of memory and get the illusion of 8,16,64 megs of contiguous memory. Real contiguous memory is required for the agp *table* which is 4 bytes/page of agp memory, or 64k for typical chipsets.... Occasionally a problem, I'm told, but I've never seen it. My usage patterns are unusual, though. Keith _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Daryll S. <da...@ha...> - 2001-12-22 18:15:41
|
On Sat, Dec 22, 2001 at 05:26:24PM +0000, Keith Whitwell wrote: > Real contiguous memory is required for the agp *table* which is 4 bytes/page > of agp memory, or 64k for typical chipsets.... Occasionally a problem, I'm > told, but I've never seen it. My usage patterns are unusual, though. Right. I was talking about the table. Sorry, you don't allocate 64M of table, so Philip probably meant the actual AGP memory. k, M what's the difference? :) - |Daryll |
From: Philip B. <ph...@bo...> - 2001-12-22 21:18:16
|
On Sat, Dec 22, 2001 at 05:26:24PM +0000, Keith Whitwell wrote: > ... > Real contiguous memory is required for the agp *table* which is 4 bytes/page > of agp memory, or 64k for typical chipsets.... Occasionally a problem, I'm > told, but I've never seen it. My usage patterns are unusual, though. Yah, I dont have problems with the 64k allocation either. It's allocs of a meg or over, that are always fragmented. |
From: Philip B. <ph...@bo...> - 2001-12-21 11:40:43
|
Another in the AGP internals series, I'm afraid: The AGPIOC_ALLOC call returns a physical address in the struct. This implies that the memory gets allocated contiguously. But how reasonable is it to assume that 32 or 64 megs of RAM will be allocated contiguously? What is the expected behaviour by the driver under fragmented physical memory conditions? (from the user-level perspective?) The presense of the GATT table in the first place, implies that the hardware itself does not expect large chunks of contiguous memory. |
From: Philip B. <ph...@bo...> - 2001-12-17 21:55:09
|
On Mon, Dec 17, 2001 at 10:52:04PM +0100, Alexander Stohr wrote: > ... > Anyways, you might consider reading open source like existing > 440BX coding in agpgart in order to see what is required. err, that's what I'm DOING :-) Trouble is, there are virtually zero comments in the /dev/agpgart driver, and I'm not intimately familiar with the linux page allocation stuff, so it's not clear to me what kind of values are being put in the GATT table: addresses, or page numbers, or... |
From: Bjorn H. <bjo...@hp...> - 2001-12-17 22:07:44
|
On Monday 17 December 2001 2:55 pm, Philip Brown wrote: > On Mon, Dec 17, 2001 at 10:52:04PM +0100, Alexander Stohr wrote: > > ... > > Anyways, you might consider reading open source like existing > > 440BX coding in agpgart in order to see what is required. > > err, that's what I'm DOING :-) Trouble is, there are virtually zero > comments in the /dev/agpgart driver, and I'm not intimately familiar > with the linux page allocation stuff, so it's not clear to me what kind > of values are being put in the GATT table: addresses, or page numbers, > or... It depends on the chipset. :-) Typically it is physical addresses, with an extra bit OR'd in to tell the chipset the entry is valid. The Intel 460GX is an exception; I think its GATT entries are page numbers with an extra bit. In general, the GATT entries are the output of the *_mask() functions, which take a physical address and a type as arguments. -- Bjorn Helgaas - bjo...@hp... Linux Systems Operation R&D Hewlett-Packard |
From: Philip B. <ph...@bo...> - 2001-12-18 05:49:40
|
On Mon, Dec 17, 2001 at 10:52:04PM +0100, Alexander Stohr wrote: > ... > Try this page: > http://developer.intel.com/design/chipsets/datashts/index.htm I found what seems to be the only document relevant to my AGP programming issue, "440BX AGPset: 82443BX Host Bridge/Controller Datasheet" which is http://developer.intel.com/design/chipsets/datashts/29063301.pdf of which I eyeball-scanned through its 132 pages (skipping the electrical signals section) and while I saw mention of the function of the GATT, nowhere did I see specification of the FORMAT of the GATT. arrg. > and if it doesnt show you all those stuff - go to AMD because > they do nicely explain their two level GART system. It helped > me a lot to get finally familiar with the topic. but how does learning how to program AMD hardware, help me to program the Intel 82443 hardware that I actually have in my possesion? :-/ |