qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Spice project is now open


From: Alexander Graf
Subject: Re: [Qemu-devel] Spice project is now open
Date: Sat, 12 Dec 2009 00:54:47 +0100

On 11.12.2009, at 23:46, Izik Eidus wrote:

> On Fri, 11 Dec 2009 23:08:01 +0100
> Alexander Graf <address@hidden> wrote:
> 
>> 
>> On 11.12.2009, at 22:13, Izik Eidus wrote:
>> 
>>> On Fri, 11 Dec 2009 14:46:55 -0600
>>> Anthony Liguori <address@hidden> wrote:
>>> 
>>>> Izik Eidus wrote:
>>>>> I personaly dont like mjpeg, and yes in the end of the day you can
>>>>> add the video streaming into vnc, but what is the point here?
>>>>> 
>>>> 
>>>> What I'm trying to understand is, what can we do with Spice that
>>>> we couldn't possibly do with vnc.  That means understanding each
>>>> feature and then figuring out if there's a vnc analog.
>>>> 
>>>> If there are compellingly unique features to Spice that can't be 
>>>> duplicated in vnc, then it's a no brainer.  If you can do most
>>>> things in vnc but it would be hackish whereas Spice makes it all
>>>> elegant, then provided we can merge Spice without a huge amount of
>>>> pain, then it's a net win.
>>>> 
>>>> However, if we need to make a few changes to vnc in order to get
>>>> the same performance as Spice, then it's not quite as clear that
>>>> it's what we should be using.
>>>> 
>>>> We're talking about a major change here.  There is a ton of
>>>> management software that assumes vnc today.  Even though there are
>>>> Spice clients out there, there are embedded vnc clients in certain
>>>> tools today along with java applets.
>>>> 
>>>> That's not to say we shouldn't embrace Spice, we just have to make
>>>> sure we have a good reason to.
>>> 
>>> Ok, I understand your concerns.
>>> 
>>> But even though that spice and vnc achive in the end of the day the
>>> same thing - they both allow remote rendering, they have fendumental
>>> diffrent architacture.
>>> 
>>> Spice server work with a ring to the guest, it was build from day
>>> one to work like that, In addition it was built from day one so
>>> that the server will render only what it must to render (to allow
>>> much higher virtualization denticity).
>> 
>> The ring is from qemu <-> guest, right? I mean, qemu <-> client would
>> be a TCP transport anyways, so the ring argument is void.
> 
> 
> Beside the fact that we dont have the network overhead...

Eh - when you connect to the VM remotely you still get the network overhead, 
because you're connecting to it via the network :-).

> 
>> 
>>> Just to make clear how much spice is diffrence from VNC is by the
>>> fact that only the library itself (not including the drivers) have
>>> 128,277 lines of code inside it. (In my old qemu repo i see almost
>>> 600,000 lines for qemu) so this should give better prespective on
>>> how much spice is diffrent from vnc.
>>> 
>>> So ofcurse in theory you can take all this 128,000 lines and push
>>> them into qemu-vnc.c ?, but you got to remember that spice is not
>>> just specific qemu thing, Spice should be used to work on physical
>>> machines too, just cutting all this lines of code from spice and
>>> throw it into qemu-vnc.c will be meaning a fork of spice inside
>>> qemu....
>> 
>> I definitely understand your point of having a single protocol. The
>> good news is that your physical machine stuff isn't released yet
>> (AFAIK), so luckily there's still time to change parts of the
>> protocol :-).
>> 
>>> It isnt just the rings and the rendering style that make spice
>>> diffrence, it is the channels it have for each compoment, it is the
>>> multiple drawing surfaces, and so on...
>> 
>> These should be fairly easy to implement in VNC too. In fact, I
>> remember a project implementing off-screen drawing in VNC using a
>> larger region of the screen than what was visible and then copyrect
>> them in.
> 
> In theory you can even change the whole of VNC into SPICE or the whole
> of VI into EMACS, so???, I personaly think changing code isnt the
> problem, the problem is always the desgien, and SPICE have fandumental
> diffrent desgien than VNC, (Here you can say: OK I can make my VNC
> desgien like SPICE, or you can say I think SPICE dsgien is bad, or you
> can just use SPICE...)

Oh I'm not trying to talk you or anyone into anything. I was merely trying to 
stress that SPICE isn't really its own protocol but extensions to the RDP 
protocol (IIUC). You could do similar extensions to VNC if you liked. Thus I'd 
love to see a generic mid-layer and implementations of RDP and VNC on top of 
that actually.

> 
>> 
>>> This why the VDI interfaces were made, it was made so who ever used
>>> VNC, can still use it, whoever want to use SPICE can still use
>>> spice,
>>> 
>>> By merging SPICE you just merge VDI interfaces, not the library
>>> itself, it is so self contained thanks to the VDI interfaces, that
>>> it almost dont touch anything inside qemu, I belive this was one of
>>> the best aurgoments when Avi pushed kvm into the kernel - the fact
>>> that it was a module that can be easyly removed if ppl dont want to
>>> use it. 
>>> 
>>> 
>>>> 
>>>>> We acctuly want to kick away that video streaming, and move into
>>>>> the DirectX and X video extentions video support (that will be
>>>>> made using the qxl driver) - will give much better performence.
>>>>> 
>>>> 
>>>> Okay, I suspect we're in agreement here then.
>>> 
>>> Thanks God ! ;-)
>>> 
>>> 
>>>> 
>>>>>> By the time we get to video memory, the display server has
>>>>>> already straightened out what portions of the screen are visible
>>>>>> and what aren't.  It will not render a hidden window and then
>>>>>> render another window on top of it.
>>>>>> 
>>>>> 
>>>>> I dont understand, if you have applciation that draw Rectangle,
>>>>> and just another Rectanlge on top of it, wont it hide it?, doesnt
>>>>> we want just to send the newest Rectangle?
>>>>> 
>>>> 
>>>> If you're using something like gdk, the toolkit double buffers
>>>> windows by default and does a single flip on expose.  So this sort
>>>> of thing never makes it way to the X server.  But the other point
>>>> is, if you draw a rectangle with gdk, all the X server ever sees
>>>> is the drawing of an image.
>>> 
>>> Spice work on the driver primitives it doesnt know what is GDK, if
>>> the X driver will draw rectangle and then another rectangle, VNC
>>> will have to draw it twice, spice not.
>> 
>> Well, in fact VNC would wait for the refresh timer of the VGA
>> framebuffer dirty thing and only send a single update too.
> 
> Yes but what will happen if you run vnc using paravirtual device?

That depends on what you get from the PV device. I'm not sure what the vmware 
svga does, but from what I've seen they try to keep a lot of the cleverness in 
the guest driver.

> 
>> 
>> But Anthony's point was that rectangle drawing isn't used anymore.
>> Instead gtk/qt just draw it themselves and tell the X driver "here's
>> an image".
> 
> 
> And what about 3D ? or Xrender operations such as composing ?
> (streching)?

Yes, you get those :-). It makes a _lot_ of sense to be your own X driver! The 
point was if we could achieve even more :-). But let's try to focus on what's 
there first.

Alex



reply via email to

[Prev in Thread] Current Thread [Next in Thread]