[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-xorg
Subject:    Re: EXA support for nv driver
From:       Benjamin Herrenschmidt <benh () kernel ! crashing ! org>
Date:       2005-08-26 3:03:30
Message-ID: 1125025410.14225.7.camel () gaston
[Download RAW message or body]


> 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 :)

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.

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.

> 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.

> 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.

Regards,
Ben.



[prev in list] [next in list] [prev in thread] [next in thread]