lkml.org 
[lkml]   [2004]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: radeon-pre-2
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)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:0.209 / U:0.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site