Jens Owen wrote:
> 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.
I don't understand why you see the ring as being so special. The hardware
provides indirect buffers just so you don't have to have multiple clients
contending for the ring. I don't see any disadvantages to using that; the big
advantage is you don't have to grab the lock each time you want to emit a few
bytes to an indirect buffer (you would with the ring, and the fast path on the
lock isn't *that* fast).
Arrays & textures have a third level of indirection provided by the hardware.
> 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:-)
This is a reasonable thing to do anyway as the 2d driver currently holds the
lock over its entire operation (perhaps delayed until the first accel action),
and is already 'trusted', so probably *should* use the ring directly rather
than going through the ioctl overhead for accel, which typically comes to only
a few 10's to 100's of bytes/ioctl.
> 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?
The i810 actually works exactly the way you're describing.
Keith
----------------------------------------------------------------------------
Bringing you mounds of caffeinated joy
>>> http://thinkgeek.com/sf <<<
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
