From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37454) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMVh0-0003lO-A0 for qemu-devel@nongnu.org; Fri, 22 Jan 2016 01:59:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMVgv-000536-Al for qemu-devel@nongnu.org; Fri, 22 Jan 2016 01:59:34 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40173) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMVgv-00052y-5g for qemu-devel@nongnu.org; Fri, 22 Jan 2016 01:59:29 -0500 Message-ID: <1453445964.17005.4.camel@redhat.com> From: Gerd Hoffmann Date: Fri, 22 Jan 2016 07:59:24 +0100 In-Reply-To: References: <1453110880.23289.7.camel@redhat.com> <56A09F6A.2030609@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 Subject: Re: [Qemu-devel] RFC: running the user interface in a thread ... List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dave Airlie Cc: Paolo Bonzini , =?ISO-8859-1?Q?Marc-Andr=E9?= Lureau , qemu-devel , David Airlie Hi, > In theory Mesa could help here, but GL isn't thread friendly at all, > so it probably won't help in the virgl > case even if it did. Since most GL apps compile a shader and block on > using it straight away doing it > in a thread won't help unblock things. >=20 > So I think it would be best to have all the virgl vq processing happen > in it's own thread with some API > to the UI to do UI resizes (the most difficult) and dirty regions etc. We can move only virgl into its own thread, but then we'll have two threads (virgl and main which runs ui) which use opengl. So I was thinking maybe it is better to have a single thread which runs both virgl and ui (and thats why I've started this thread ...). cheers, Gerd