EXA support for nv driver

[Alex Deucher]

On 9/6/05, Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote:
> On Tue, 2005-09-06 at 09:29 +0200, Lars Knoll wrote:
> > > You mean PCIe chipsets? ;) AFAIK AGP is explicitly specified not to be
> > > cache coherent.
> >
> > AGP 3.0 seems to allow for cache coherency:
> 
> Yah, but any idea which chipsets actually provide it ? I've been
> thinking about various ways of "using" those features lately with EXA.
> There have been several things I had in mind.
> 
> 1) Create a 3rd classs of migration for pixmaps -> AGP memory (or
> whatever "GART" memory, wether it's AGP, PCI-GART or PCI-E GART).
> Pixmaps put there are the ones that get regulary banged from both the
> CPU (software fallbacks) and the engine. The nice thing with AGP memory
> is that it's faster than video memory for CPU accesses (especially if
> your chipset supports cacheable AGP !) and it's directly accessible by
> the engine.
> 
> 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...
> 

these zones would also be useful on cards with "special" chunks of
memory like radeons with more than 128 MB or vram and 3d cards with
separate vram for textures vs framebuffer, etc.

Alex

> 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 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).
> 
> Keith, what do you think ?
> 
> Ben.
> 
> 
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>