From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40050) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T77DH-00053x-Ph for qemu-devel@nongnu.org; Thu, 30 Aug 2012 12:03:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T77DC-00089U-A3 for qemu-devel@nongnu.org; Thu, 30 Aug 2012 12:03:23 -0400 Received: from smtp.nfit.au.dk ([130.225.17.180]:51265 helo=nysmtp.nfit.au.dk) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T77DC-00088D-2N for qemu-devel@nongnu.org; Thu, 30 Aug 2012 12:03:18 -0400 From: sandmann@cs.au.dk (=?utf-8?Q?S=C3=B8ren?= Sandmann) References: <1346088041-17062-1-git-send-email-sandmann@cs.au.dk> <1346088041-17062-2-git-send-email-sandmann@cs.au.dk> <503C621D.80805@redhat.com> <20120829101457.GC32547@garlic.redhat.com> <503EFB6D.1080701@redhat.com> Date: Thu, 30 Aug 2012 18:03:15 +0200 In-Reply-To: <503EFB6D.1080701@redhat.com> (Gerd Hoffmann's message of "Thu, 30 Aug 2012 07:34:37 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Spice-devel] [PATCH] Add new client_present and client capabilities fields to QXLRom List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Alon Levy , qemu-devel@nongnu.org, spice-devel@freedesktop.org, =?utf-8?Q?S=C3=B8ren?= Sandmann Pedersen Gerd Hoffmann writes: >> The scheme I had in mind was this: >>=20 >> - When a new non-a8-capable client appears, don't send it any of the >> a8 surfaces >>=20 >> - If the client doesn't understand a8 surfaces, >>=20 >> - keep all a8 surfaces rendered on the server side >>=20 >> - if the guest sends a command using an a8 surface as a >> destination, simply render the command on the server side >>=20 >> - if the client sends a command using an a8 surface as a source, >> rewrite the image object to be a real image referring to the >> server side bits (which are also sent or possibly cached) >> rather than a surface > > Hmm, when the server is able to translate a8 ops into non-a8 ops using > server-side rendering, then there is no need to notify the guest about > the client capabilities. To be clear, this ability doesn't exist at the moment, and it would be a significant chunk of work to add it. >> But it's much simpler to just say that the guest should stop referring >> to a8 surfaces if the client can't handle them. > > Not sure about that, this move might just shift the complexity from > spice-server to the guest qxl driver. The ability to handle this is already pretty much present in at least the X driver (and I'm pretty sure the Windows driver has it as well) because any time something can't be expressed in the SPICE protocol, it has to fall back to software rendering. Ie., it has to read all the involved surfaces back from video memory, do software rendering, then upload the result as an image. Dealing with a disappearing ability to handle a8 surfaces would simply be a matter of reading back the a8 surfaces to guest RAM and then not attempt to acccelerate any operations involving them any more. It looks much more involved to do it in spice-server because it would probably involve adding a new concept of "emulated surface" that needs to be handled specially in a bunch of cases. S=C3=B8ren