New glucose code

[Daniel Stone]

On Thu, Mar 29, 2007 at 12:11:55PM +0100, Keith Whitwell wrote:
> Note that at the moment it might well be worth going to software, but 
> only because the 3d stack is optimized towards a single context doing 
> big q3arena screenloads of rendering.  The hardware itself can do much 
> better - through support for hardware context switches, multiple active 
> hardware contexts (eg per-context ringbuffers) & hardware scheduling, etc.
> 
> All of these mechanisms serve to reduce the overhead of doing that 10x10 
> blit in hardware, and thereby avoiding the drain/flush penalty.  Better 
> still, with sufficient care, they can allow you to prioritize 
> user-interface blits *above* pending rendering.  All this stuff has been 
> around since at least the i830, so it's not exactly new - we just have 
> to take advantage of it.

Hi,
The balance tilts a little bit the other way with poor little consumer
device hardware, where you don't have multiple HW contexts, and
especially, potentially very high latencies and also rather slow
transfer speeds from the 3D engine back to the framebuffer.  Maybe a
dynamic calculation of the overhead involved in set up, transfer, and
teardown would be needed to work out which approach to take.

Obviously I have to defer to you on current desktop hardware, though. ;)

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20070329/07f89c74/attachment.pgp>