EXA support for nv driver

[Benjamin Herrenschmidt]

> Seems like newer AMD chipsets are 3.0. At least mine is, so I could do some 
> testing.

Well... Apple's one claims AGP 3.0 but for some reasons, I doubt it
deals with cacheable aperture ;) I'll try it one of these days though.

> > The way to do that at first (incremental implementation) would probably
> > to modify the offscreen allocator to actually have N instances of the
> > allocator itself (zones). Then, the driver could create a memory zone
> > and an AGP zone. The pixmaps themselves would have a flag indicating in
> > which zone their backup is. That also means more dynamic allocation of
> > the vram/agp storage as we don't want to permanently allocate space in
> > both for all pixmaps, and thus more causes for failures due to
> > fragmentation but since we can kick pixmaps around, and possibly move
> > them around as well, that should be doable...
> 
> Sounds very good. Having pixmaps that will be accessed both by the graphics HW 
> and by CPU in the GART will be a definite win.

Yup. I think I can figure out how to implement the low level support in
EXA (provided that I can find the time for it, so feel free to beat me
to it) but I'd leave the actual intelligence of deciding where/when to
migrate pixmap to somebody else ;)

> > 2) With PCI GART and PCI-E GART (and with cache coherent AGP too) we are
> > in a new situation where we don't really need to permanently bind a
> > whole aperture in the "GART" space at all. We could dynamically map the
> > pixmap there "on demand". Which mean that instead of migrating the
> > pixmaps to "AGP" (or rather call it GART space)
> 
> This would be even more flexible, and could be quite a bit faster in a lot of 
> cases. But it would probably require some kernel/drm support (to be able to 
> map a specified region of virtual memory into the GART).

Definitely. We need to be careful as memory mapped into the GART will
have to be locked physically, thus we need to make sure we don't
lock/map more than a given amount, possibly based on RLIMIT_MEMLOCK, and
kick things out when reaching that limit. It would need an updated AGP
kernel interface but I foresee no real difficulty.

> > This is really only a low level implementation detail compared to 1).
> > That is, we still have to allocate GART virtual space (though we can
> > afford to have a much larger GART) and instead of "migrating" from
> > memory to GART, we would just alter the mappings. Sort-of a faster
> > version of 1).
> 
> I don't think the virtual space is a problem, if we limit ourselves to 256MB 
> or similar on 32 bit machines.
> 
> I think it would be best to start out with the first proposal and add some 
> sort of GART handling to the memory manager and EXA.

Yup, that was my idea. I'm still using most of my spare time on other
things at the moment, including the radeon EXA driver, so I won't tackle
this for some time, so feel free to beat me to it, or somebody else
motivated ;)

Ben.