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

[Dave Airlie]

>
> 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?

In theory the mesa/gallium numbers aren't stable, though I've never
seen them change yet,

If they diverge in the future I'll just provide a remapping table
inside the guest driver.

So it should be fine to expose these formats for 2D 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.

I spent a little while trying to get a ppc64 f20 install to complete, just
using the F20 qemu ppc64 system package but hit a bug I
think is related to missing SIMD instructions, so I'm not sure how best
to move forward with getting a test platform here.

Dave.