EXA support for nv driver

[Benjamin Herrenschmidt]

On Fri, 2005-08-26 at 08:41 +0200, Lars Knoll wrote:

> Wouldn't mapping the actual RAM page be better anyway, as that one could be 
> mapped cachable, whereas the GART memory usually is write combining only?

Mapping cacheable ? Hrm... I'm not sure that would work with many
chipsets as I'm not sure they would trigger proper coherency protocol
when beeing accessed by the card. I currently map them non-cacheable on
Macs but it might be worth trying on some chipsets I suppose...

> That explains it. Currently you can only mmap the whole aperture. I tried 
> mmap'ing only the part I bound first, which failed. It took me quite a while 
> to find out that I can only map the whole aperture at once.
>
> What I found strange is that the DRM module seems to duplicate a lot of the 
> functionality of the agpgart. 

Yup, it sort-of uses the agpgart backend directly and replaces the
frontend (at least for some things).

> Either this, or we implement a simple DRM module for nvidia. The problem might 
> be that this changes how the agpgart behaves. As I said above you can 
> currently map the whole aperture before binding, I guess because it maps the 
> address reagion reserved for the GART and not the physical pages.

Yes. Exactly. I suppose we could change agpgart to behave differently
only on bridges that have cant_use_aperture=1. But it would be easier at
first to just do a simple DRM driver imho.

> The driver uses a fixed binding currently (ie. it binds a chunk of memory at 
> startup and maps this once). But that's

That's what ? :)

> I looked into their driver as well. utah-glx and rivatv are some other sources 
> where you can find bits of information. The information that exists could be 
> enough to write some simple 3d acceleration, probabably enough to play 
> tuxracer and quake, but my current goal is more to get 2d working as good as 
> possible.

Yup. EXA is definitely a nice step forward.

Ben.