[Mesa3d-dev] Re: [Dri-devel] New tdfx driver, locking, small device driver changes

[Gareth H. <ga...@va...>]

Keith Whitwell wrote:
> 
> OK, so in examining the newest tdfx driver, I got to wondering about the calls
> to LOCK_HARDWARE inside the triangle functions.  In particular, after noticing
> the slowdown after Brian added cliprect handling to those calls, I wondered
> what would happen if I moved locking out of the triangle function.

Just before I left, I had begun implementing exactly the same
optimization.  Thanks for taking care of this!

> So...  What's the catch?
> 
> Basically, to lock outside the trifuncs, I need somewhere to lock.  The
> obvious place is in the RenderStart/RenderFinish driver callbacks.  The only
> trouble with this is the span fallbacks: we lock in these on a per-spanline
> basis.  We can remove locking from the span callbacks, and be fine on triangle
> rendering.  However, the span fallbacks are also called from DrawPixels, etc.
> 
> DrawPixels, etc. don't currently call RenderStart/RenderFinish, so where
> should the locking occur there?
> 
> To my mind, the obvious thing to do is:
> 
>         - Add RenderStart/RenderFinish calls around all possible calls to the
> span/pixel functions
>         - Do locking in RenderStart/RenderFinish in the tdfx driver
>         - Remove locking from triangle and spanline functions in the tdfx driver

I think this is the nicest way to handle driver-side immediate mode
("direct") rendering.  If the tdfx driver buffered vertices and then
submitted them as required (like in the other MGA-style drivers) this
wouldn't be a problem.

Aside: I've been looking at taking advantage of the COMMAND_TRANSPORT
extension in Glide, which will basically allow us to bypass the Glide
triangle functions and write directly to the FIFO.  This would involve
buffering of vertices and submitting them in a bunch.  Only this
submission would require the hardware lock, just like in the other
drivers.  If only I had a damned machine...

> One potential problem with this is that in fallback cases we will hold the
> hardware lock for the time it takes to render an entire vertex buffer of
> triangles, one spanline at a time.  I propose to get around this by 'flashing'
> the lock in the spanline and pixel functions, eg:
> 
>         UNLOCK_HARDWARE(fxMesa);
>         LOCK_HARDWARE(fxMesa);
>         ...
> 
> To allow a (tiny) window for the X server or other clients to grab the lock.

This looks like a nice way to go.

-- Gareth