Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S266538AbUIMLk5 (ORCPT ); Mon, 13 Sep 2004 07:40:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S266543AbUIMLk5 (ORCPT ); Mon, 13 Sep 2004 07:40:57 -0400 Received: from colossus.systems.pipex.net ([62.241.160.73]:5532 "EHLO colossus.systems.pipex.net") by vger.kernel.org with ESMTP id S266538AbUIMLkz (ORCPT ); Mon, 13 Sep 2004 07:40:55 -0400 Message-ID: <4145873B.8070805@tungstengraphics.com> Date: Mon, 13 Sep 2004 12:40:43 +0100 From: Keith Whitwell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Smirl Cc: Alan Cox , Dave Airlie , =?ISO-8859-1?Q?Michel_D=E4nzer?= , =?ISO-8859-1?Q?Felix_K=FChling?= , DRI Devel , lkml Subject: Re: radeon-pre-2 References: <9e47339104091011402e8341d0@mail.gmail.com> <1094853588.18235.12.camel@localhost.localdomain> <1094873412.4838.49.camel@admin.tel.thor.asgaard.local> <1094913222.21157.61.camel@localhost.localdomain> <9e47339104091109463694ffd3@mail.gmail.com> <1094919681.21157.119.camel@localhost.localdomain> <9e47339104091110272101ecfb@mail.gmail.com> In-Reply-To: <9e47339104091110272101ecfb@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1641 Lines: 43 Jon Smirl wrote: > On Sat, 11 Sep 2004 17:21:22 +0100, Alan Cox 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/