qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/8] virtio-gpu/2d: add hardware spec include fi


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [PATCH 1/8] virtio-gpu/2d: add hardware spec include file
Date: Mon, 06 Oct 2014 11:20:31 +0200

  Hi,

> >> >> +    VIRTIO_GPU_FORMAT_B5G5R5A1_UNORM  = 5,
> >> >> +    VIRTIO_GPU_FORMAT_B5G6R5_UNORM    = 7,
> >> >
> > Ok.  But for 2D we can just not support it, right?
> 
> We can, I expect some pushback at some point, people still want to
> test with 16bpp for other areas, and it would be nice to know they
> can. But I don't really care about it personally. I just though we
> should provide at least a basic number of working bpps (8,16,32).

Lets try to get away with 32bpp only in 2d mode then.

bochsdrm likewise supports 32bpp only and I yet have to see a request
for 16bpp or even 8bpp support.

> I think we should probably move a few more formats from the 3D side
> into the 2D side, so we can have the guests just pick the LE format
> it requires
> 
> http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/include/pipe/p_format.h#n354
> 
> is what gallium currently does, and we could just provide XRGB, XBGR
> formats in both endianness
> and have the guest pick the one it wants to use.

   PIPE_FORMAT_R8G8B8A8_UNORM          = 67,
   PIPE_FORMAT_X8B8G8R8_UNORM          = 68,

   PIPE_FORMAT_A8B8G8R8_UNORM          = 121,
   PIPE_FORMAT_R8G8B8X8_UNORM          = 134,

With the last two ones being in a /* TODO: re-order these */ block.
How stable are these numbers?

> The 2D pixman code would need updating to provide 2D support for these
> formats as well.

Yep.  Mapping the 32bpp formats to pixmap formats is easy.

> I suspect I could add an endian cap for the 3D bits that I could pass
> through from guest to host.

I was thinking about using virtio feature bit.  Advantage is that the
guest will tell the host which features it'll use.

Initially this doesn't matter much as the host will support only one
endianness anyway. 

But in case we get the byteswapping work reasonable well some day and
the host supports both be and le virgl we'll know that way which
endianness the guest is using.

> How do you test guests with big endian? Isn't it really slow?

emulated pseries machine with fedora ppc64.  Yes, it is slow.  Building
a kernel with virtio-gpu driver takes a day or so.

cheers,
  Gerd





reply via email to

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