On Sat, 11 Sep 2004 17:21:22 +0100, Alan Cox <[EMAIL PROTECTED]> 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)
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
