EXA support for nv driver
Lars Knoll
lars at trolltech.com
Thu Aug 25 23:41:30 PDT 2005
On Friday 26 August 2005 05:03, you wrote:
> > Interesting. Why can the DRM mapping methods handle this and the agpgart
> > module can't? The limitation sounds somewhat arbitrary to me. Shouldn't
> > the code needed to handle this case be in the agpgart module then?
>
> Because the DRM was fixed to handle it and agpgart wasn't :) Practically
> what happens is that the DRM installs a nopage() handler, and upon page
> faults, maps the actual RAM page into the client process space on
> platforms that have this limitation. Back then, nobody
> using /dev/agpgart was around to require a similar fix :)
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?
> The problem with the agpgart infrastructure is that technically, you are
> allowed to bind/unbind memory after you have done the mapping. A simple
> approach like the above doesn't work in that case since it would have to
> invalidate the mappings in all client processes on unbind(). That is a
> bit complicated and thus was not implemented.
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.
> It would be easy to add a nopage() handler to /dev/agpgart too, provided
> that the API is limited to mapping memory that has already been bound,
> and not unbinding memory before it's unmaped.
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.
> > The problem is that you'd need a drm module for nv first. I had a short
> > look at the DRM stuff, but as I couldn't find any decent documentation on
> > how to write one, I didn't feel like diving into this up to now.
>
> I know, that's annoying. I may give a try at fixing agpgart though. What
> do you need ? a fixed binding or dynamically bind/unbind bits ? I have
> an iMac G5 with a 5200 here so I suppose I'll be able to test.
The driver uses a fixed binding currently (ie. it binds a chunk of memory at
startup and maps this once). But that's
> > I have some ideas how to dispatch DMA command buffers that are resident
> > in AGP memory as well, so one could propably write a semi decent DRM
> > module for NV.
>
> Not sure. Have you looked at the openbeos (Haiku OS nowadays) NV
> driver ? It seems to be more complete than ours, it contains interesting
> bits.
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.
Cheers,
Lars
More information about the xorg
mailing list