EXA support for nv driver
lars at trolltech.com
Fri Aug 26 00:43:01 PDT 2005
On Friday 26 August 2005 08:58, Benjamin Herrenschmidt wrote:
> 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...
Hmmm... true. I remember vaguely having read that some newer chipsets support
this, but I couldn't find the reference anymore.
> > 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.
Probably. And it doesn't require reworking parts of the agpgart driver.
> > 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.
More information about the xorg