Benjamin Herrenschmidt wrote:
On Sun, 2006-01-08 at 18:17 +0000, Keith Whitwell wrote:
In the past there has been talk about mapping user memory into the GTT
aperture as a mechanism to avoid copy-based uploading. What I'm
proposing is that this type of mapping becomes the only or at least
primary way of getting data and memory into the GART aperture.
Hi Keith !
A couple of things with this approach that come to mind..
- Caching issues. On a lot of chipsets, AGP memory must be mapped
non-cacheable. This isn't trivial on all architectures and it's not
always feasible to do with userland buffers. That means that either the
cache must be flushed at the time of the mapping _and_ the buffer not
touched at all by the CPU until it's unmapped, or the map call must
change the userland mapping to the buffer to mark it uncached. The
problems of course starts popping up if this buffer happens to be shared
between multiple processes... also, that user memory will also be mapped
in the kernel as part of the kernel's linear mapping, which is
cacheable. Thus you'll end up with pages mapped both cacheable and
non-cacheable in different contexts. This is a good way to cause
checkstops with a number of CPUs (certainly with PowerPC and I think
also with amd's). (At this point, for those who didn't figure out yet
that AGP was just a piece of crap in the first place, welcome to the
real world)
Yes, this I think is addressed by the Map/Unmap semantics from ARB_vbo and the
additional constraints I included in the design, ie that the only time the
buffer contents are meant to be available as user memory is when they are Mapped
(in the ARB_vbo sense, which means *not* mapped in the GART). Thus it's
allowable to tear down the cached access to these pages on upload, and
especially so if required for system stability.
IE, in systems where stability is threatened by the cacheable access to the
pages, it would be necessary to extract the uploaded pages those cacheable maps
and have them solely in the GTT - if it is possible to populate the GTT at all,
it must be possible to populate it with these pages?
If this is an absolute killer for some systems, then I guess there would have to
be a different AGP memory manager on those systems, based more on the sort of
copying and DMA operations that I expect a Video RAM implementation would use.
I feel however that the ARB_vbo API's and semantics are strong enough to cover
both cases.
- I would separate the mecanism for locking & preparing user buffers
for DMA and binding them into a GART, wether it's AGP, or a card
specific one like ATI's PCI GART, or a card's SG DMA engine, like nvidia
objects. That is, on one hand, you have the user program who has buffers
(textures, fbo's, whatever... ) that it wants to make available for
access by the engine, on the other, you have whatever mecanism your card
provides to access system memory with address translation. The later
changes. AGP GART is one way but is slowly going away, ATIs use a
similar mecanism on PCI and PCI-E, nVidia afaik, can store in the card
descriptors for objects in system memory associated with a scatter
gather list (or a page table), on ATI, I've had good results using also
the scatter-gather DMA engine instead of the GART for some types of
transfers (like card -> memory, a direction for which AGP often doesn;t
work at all) etc... All those mecanisms however rely on the same "left
hand" basic mecanism for locking & mapping the user buffers for DMA,
which requires also some resource tracking to make sure a simple DRI
client can't hog the whole system by pinning down too much user memory,
etc...
Indeed. I think that taking the API from ARB_vbo makes these different
implementations entirely possible. The implementation I am interested in right
now is the AGP one, but don't take that to imply that other implementations and
backends are excluded.
I've tried to provide exactly the seperation that I think you're talking about
by sticking closely to the buffer_object semantics from ARB_vbo/ARB_fbo for the
interface.
Keith
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
--
_______________________________________________
Dri-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel
