qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] X support for QXL and SPICE


From: Alexander Graf
Subject: Re: [Qemu-devel] X support for QXL and SPICE
Date: Sat, 12 Dec 2009 16:43:43 +0100

On 12.12.2009, at 16:29, Izik Eidus wrote:

> On Sat, 12 Dec 2009 09:13:51 -0600
> Anthony Liguori <address@hidden> wrote:
> 
>> Izik Eidus wrote:
>>> On Fri, 11 Dec 2009 21:31:34 -0600
>>> Anthony Liguori <address@hidden> wrote:
>>> 
>>>> Okay, that's in line with what my expectations were.  So what's
>>>> the future of Spice for X?  Anything clever or is Windows the only
>>>> target right now?
>>>> 
>>> 
>>> Offscreen pixmaps, Xrender, opengl 3d commands, Video extention.
>>> 
>>> I dont understand what you want here?
>>> 
>> 
>> To understand what makes Spice special.
> 
> 
> Spice is interesting beacuse unlike the great VNC protocol it already
> have what it take to make VDI possible to the user.
> 
> If you think all the above features are pointless and if you think that
> Windows graphic systems (90% of the world wide desktops users) is not
> important, I really dont know what to tell you.
> 
> It is easy to say about everything "We can implment it in VNC..." yes.
> and I can write my own new operation system and tell everyone "Haa,
> right now i dont have it, but it is easy to implement"...
> 
> It is naive to think that software is all about features..., In this
> case Linux / Freebsd are the same thing..., ohh wait they are diffrent
> no?.
> 
> Wait, I think Google, Yahoo and Bing, does`nt they all have the same
> features????, How come ppl still prefer to use Google in that case?
> 
> VNC is much older than spice, but still why it didnt get all this SPICE
> protocol goodies? why? (I mean it is so easy to add this into VNC...)

I think you're getting the wrong message. Let me tell you something about my 
work on virtio-fb.

I did 2 versions. The first one was completely ring and message based. I used 
the virtio ring topology to send framebuffer updates along to the hypervisor, 
basically resembling the linux fb callback interface.

While that worked, it was _horribly_ slow. I didn't know why. Until I found out 
that all of this transferring happens synchronously! So on every linuxfb 
function call we basically got a hypervisor exit, resulting in a lot of 
overhead. Not to speak of all the vmalloc magic I had to do.

If I had known before that this is a bottleneck, I would have designed the 
protocol differently. In fact, I did for v2 - and ended up having only a single 
real command in my awesome protocol: "mark dirty". So I ended up basically 
reimplementing the same framebuffer based interface we use in qemu already. Oh 
great.

If anybody would have been around to tell me that what I'm doing is a bad idea 
because he went through it before, or if I had simply known before, I wouldn't 
have made those mistakes. It's all about knowledge.


Another example.


I'm always having a hard time understanding why VNC is slow. I've seriously 
always been wondering. And I'm still puzzled as to why RDP is so much superior 
performance-wise. After all, it basically only implements framebuffer updates 
too.

So now you bring in SPICE to that equation. I don't know _why_ SPICE is faster. 
I know that it is and I hear all those awesome great features. But I still 
don't have a feeling on which part of it really is the performance booster. As 
with the example above, I would never have guessed that doing synchronous 
updates is the performance killer. I'm still trying to figure out what is going 
wrong in VNC :-).

So don't take this as an offense. It's about learning from you guys. You're the 
ones that measured what makes things fast - and we want to know! Even if we're 
not building code on it, but using SPICE, it'd still be very valuable to know 
why exactly it is performing better. And best case also by how much each single 
feature saves us.


Alex

PS: Let me explain my background on those questions:

I'm stuck with VNC for SUSE Studio for now. While I can't make fundamental 
changes to the protocol, I can easily modify the guest and I can also easily 
modify the VNC viewer to add a few new commands. If I can get a throughput 
reduction of 50% by using 2 out of 10 features SPICE has as VNC protocol 
extensions, I'd gladly implement them. That'd just make user experience on our 
side a lot better. If that means using QXL inside the guest, so be it :-).



reply via email to

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