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


_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to