On Tue, 2006-09-19 at 11:27 +0200, Thomas Hellström wrote:

> But this should be the same problem encountered by the agpgart driver?
> x86 and x86-64 calls change_page_attr() to take care of this.
> On powerpc it is simply a noop. (<asm/agp.h>)

Possibly. We sort-of ignore the issue for now on PowerPC and happen to
be lucky most of the time because 32 bits PowerPC aren't that agressive
at prefetching...

I haven't looked at change_page_attr() implementation on x86 but I know
they also map the linear mapping with large pages. I don't know what
happens if you start trying to change a single page attribute. x86 can
breakup that large page into 4k pages, so maybe that's what happens.

> Currently we take the following approach when the GPU needs access to
> a buffer:
> 
> 0) Take the hardware lock.
> 1) The buffer is validated, and if not present in the GATT, it's
> flipped in. At this point, idle buffers may be flipped out.
> 2) The app submits a batch buffer (or in the general case a command
> sequence). All buffers that are referenced by this command sequence
> needs to have been validated, and the command sequence should be
> updated with their new GATT offset.
> 3) A "fence" is emitted, and associated with all unfenced buffers.
> 4) The hardware lock is released.
> 5) When the fence has expired (The GPU is finished with the command
> sequence), the buffers associated with it may optionally be thrown
> out. 
> 
> One problem is that buffers that need to be pinned (_always_ available
> to the GPU) cannot be thrown out and will thus fragment the aperture-
> or VRAM space.
> 
> Buffers also carry usage- and mapping refcounts. They are not allowed
> to be validated when mapped, and (except under some circumstances) are
> not allowed to be mapped while validated. Buffer destruction occurs
> when the refcount goes to zero.

Yup. My idea was to allow the locking from userspace to allow for chips
that can allow userspace direct command submission. Basically, lock/pin
the buffer if it's still in the card, and if that fails (because it's
been evicted already), then fallback to a kernel call.

Ben.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to