On Wed, 2005-06-29 at 13:36 -0400, Jon Smirl wrote:
> On 6/29/05, Keith Whitwell <[EMAIL PROTECTED]> wrote:
> > Jon Smirl wrote:
> > > In i810/server/i810_dri.c there is a call to agp alloc without the
> > > type set to zero:
> > > drmAgpAlloc(ctx->drmFD, 4096 * 1024, 1, NULL, &dcacheHandle);
> > >
> > > A type of one translates into U16_APER_SIZE which doesn't match the
> > > request size of 4MB.
> > >
> > > Is this a bug or do I not understand the type parameter on agp alloc?
> > > This is the only place where a type other than zero is used.
> > >
> > 
> > The i810 had an optional bank of dedicated video ram, the "dcache",
> > which was useful for certain tasks despite having lower bandwidth than
> > regular shared/system ram.  This memory required special handling - I
> > would say the type parameter would have been added for this case in
> > particular.
> > 
> > Note that this is not the same as the i810's "stolen" ram which is
> > allocated off the top of regular memory at boot time by the bios.
> 
> If I am reading the code right the type ends up straight in the
> kernel's agp_allocate_memory(pages, type);  Then looking at the kernel
> code the type goes into the chip agp driver and then comes back out
> later. I can't find any documentation on what 'type' does.
> 
> I don't have any reason to think it's not working, it was just odd
> that it was the only non-zero use in the system.

Type 0 is normal.  Type of 1 specifies that it's dcache.  Type of 2
specifies cursor memory.  The AGP driver respects the type and allocates
from the appropriate place.

-- 
Eric Anholt                                     [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/              [EMAIL PROTECTED]


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
--
_______________________________________________
Dri-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to