Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out

[Anthony Liguori]

Alon Levy <address@hidden> writes:

> On Mon, Jul 30, 2012 at 10:08:07PM +1000, Benjamin Herrenschmidt wrote:
>> On Mon, 2012-07-30 at 14:58 +0300, Avi Kivity wrote:
>> > Let's balkanize some more then?
>> > 
>> > No, qxl is our paravirt vga, we should improve it instead of spawning
>> > new ones (which will be horrible in the eyes of the next person to look
>> > at them).  You should also be getting the drm driver for free.
>> > 
>> > http://spice-space.org/page/DRM
>> 
>> "Free" is a big word here, I wouldn't be surprised if it was totally
>> endian busted :-)
>> 
>> Why so much effort into a bad design on top of a crack transport btw ?
> Could you elaborate about the design and transport issues that you
> see?

"bad design" is too simplistic.  The design is fine for what it
initially targetted.

But we have better ways of doing things now and a much broader scope.
There's no way we can support non-PCI architectures without heavy
lifting.  We also have the opportunity to improve things in such a way
to have a single unified graphics adapter which is a very good thing.

Basically, the core requirements are VESA-compatible + virtio for
command queue.

This gives us reasonable performance/features when a guest driver isn't
available and a path to supporting non-PCI platforms.

Non-PCI graphics is actually very common place.  Many embedded systems
have some form of framebuffer.  Having a graphics platform that supports
non-PCI systems would be quite valuable.

>
>> Is it just RH politics of there's a good reason hiding somewhere ? Some
> No politics AFAIK. Spice code may suck but it's doing a good job while
> sucking, so we prefer to fix it unless a good design that makes it
> easier to rebuild from scratch comes along. I'm all ears.
>
>> kind of morbid fascination for anything Windows ?
> We do have bad linux performance but the is work going to improve it, by
> adding RENDER implementation to our driver and protocol additions, among
> others.

FWIW, when I talk about PV graphics, I'm really only interested in
having a variable sized linear framebuffer (in a sane format--32-bit
8-bit pixels), 2d acceleration like blit and solid fill, and ARGB cursor
offload.

I strongly suspect that even Linux has this today with Spice.  My only
problem with Spice is that it's all or nothing.  If we could negotate
capabilities, I'd be very happy with it.

Offscreen bitmaps, YUV surfaces, etc, are all just icing on the cake.
Requring libspice for that kind of stuff is fine by me.

Regards,

Anthony Liguori

>> 
>> People I've talked to around in the community seem to agree that some
>> minor improvements on qemu-vga are worthwhile, so I'm doing them,
>> nothing drastic, mostly having a mirror of the legacy IO registers in an
>> MMIO BAR so it's more usable for non-x86 platforms, and I'm about to add
>> some simplistic 2D blit facility so we can have a semi-decent fb console
>> over vnc. I can trivially do an equivalent of cirrusdrmfb for it so we
>> get X mode setting / RandR.
>> 
>> That gives us a baseline for mostly unaccelerated 2D.
>> 
>> Something tells me that getting that spice/qxl gunk will be more than a
>> trivial effort (but I might be wrong) and I'm reluctant to start
>> committing effort on it since so far I yet have to see it being actually
>> picked up by people.
>
> I'll be happy to elaborate on any part of qxl/spice that I understand
> and help you help us improve it.
>
>> 
>> Cheers,
>> Ben.
>> 
>>  
>> 
>>