Linus Torvalds wrote:
> Yes, kernel support (or indirect rendering) is needed for untrusted
> applications, but it might actually be interesting to see what a
> direct-rendering all-user-land implementation looks like. It has some
> debugging advantages, and it may actually make sense to start from a
> totally trusted app that goes as fast as humanly possible, and then when
> that has been optimized to death look at just where the interfaces make
> the most sense..
Keith,
Along these lines, I've been toying around with the idea that direct
user level access to the ring for commands *might* be able to use a DRM
locking policy similar to how we protected the ring in the TDFX driver
where it was directly accessed by the user space driver and indirect
buffers were only used for indirect kinds of data like arrays and
textures.
We touched on this a few weeks ago on IRC, and IIRC you thought there
might be some problems with coordinating access and aging buffers.
Would it be valuable if I were able to get a prototype going where the
2D server access and the kernel DRM module shared direct access to the
ring protected by the DRM lock? Obviously, multiple instances of a 3D
driver would be an even better prototype, but I'm looking for an easier
proof of concept:-)
If I can get 2D and kernel sharing access, what problems do you foresee
with getting multiple 3D clients to participate using a policy similar
to TDFX?
Regards,
Jens
-- /\
Jens Owen / \/\ _
[EMAIL PROTECTED] / \ \ \ Steamboat Springs, Colorado
----------------------------------------------------------------------------
Bringing you mounds of caffeinated joy
>>> http://thinkgeek.com/sf <<<
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
