Re: radeon-pre-2

[Keith Whitwell <keith@tungstengraphics.com>]

Jon Smirl wrote:
> On Sat, 11 Sep 2004 17:21:22 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> 
>>On Sad, 2004-09-11 at 17:46, Jon Smirl wrote:
>>
>>>User 1's game queues up 20ms of 3D drawing commands.
>>>Process swap to user 2.  ->quiesce() is going to take 20ms.
>>>User 2's timeslice expires and we go back to user 1.
>>>User 1 queues up another 20ms.
>>>
>>>User 2's editor is never going to function.
>>
>>If you implement it wrongly sure. If you implemented it right then
>>this occurs.
>>
>>User 1 queues 20 ms of 3D commands
>>User 1 is pre-empted
>>User 2 wants the 2D engine
>>User 2 beings wait for 2D
>>User 2 sleeps
>>User 1 wakes
>>User 1 beings wait for 3D but discovers a claim is in progress
>>User 1 sleeps
>>User 2 wakes, runs commands
> 
> 
> This model destroys the parallel processing between the main CPU and the GPU.

And this is the reason that cards tend to do 2d and 3d through the same 
command queue, and often the same hardware at the backend - there's no need on 
such hardware to quiesce between acclerated 2d and 3d commands.

Of course, if either user ends up wanting to touch the framebuffer directly, 
they will have to flush the queue & wait for quiescence.  There's nothing 
particularly 2D or 3D about this - they both have fallbacks, and they're both 
faster if fallbacks can be avoided.

Keith (who has lost track of who's arguing about what or why)