New glucose code
keith at tungstengraphics.com
Thu Mar 29 05:02:31 PDT 2007
Daniel Stone wrote:
> 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.
> 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. ;)
Yes, it's a known unknown... It'll be interesting to see how far we can
push the balance.
More information about the xorg