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

[Dave Airlie]

> Triggered by the framebuffer endian issues we have with stdvga I've
> started to check where we stand with virtio-gpu and whenever we have to
> fix something in the virtio protocol before setting in stone with the
> upstream merge.

Let me start by saying its not that I don't care about endianness, but
its a mess I had hoped to avoid until someone else care more about it.

We haven't even managed to get endianness fixed for real 3D gpu hardware yet,

We sort of have decent endianness support for the llvmpipe sw driver now, after
I spent a week trawling patches and fixing up the results.

So before we try fixing things, we probably need to design something
that defines
where all the swapping happens, and what formats the virgl "hw" device supports.
The main problem is getting an efficient solution that avoids double swapping
of the major items like texture and vertex data if we can in some scenarios.

Currently the virgl "hw" supports little endian defined formats, as
per the gallium
interface, i.e. B8G8R8A8 means blue/red/green/alpha,

http://gallium.readthedocs.org/en/latest/format.html
is the documentation.

>
>> +    VIRTIO_GPU_FORMAT_B5G5R5A1_UNORM  = 5,
>> +    VIRTIO_GPU_FORMAT_B5G6R5_UNORM    = 7,
>
> Do we really wanna go down this route?  I'm inclined to just zap 16bpp
> support.

We have to support 16bpp as an OpenGL format no matter what, and this
is why endianness sucks, we have lots of strange ass formats we need
to send over the wire, that have no nicely defined endianness, like Z24S8.

>
>> +    VIRTIO_GPU_FORMAT_R8_UNORM        = 64,
>
> What is this btw?  Looks like gray or alpha, but why "R8" not "G8" or
> "A8" then?  Why the gap in the enumeration?

Red 8, the enumeration is taken from the gallium formats list, rather than
reinventing our own. Most modern GPU hardware doesn't really have
A8 texture support, as it was deprecated in newer OpenGL.

>
> What about 3d mode?  We are passing blobs between virglrenderer and
> guest driver:  capabilities and gallium 3d command stream.  What happens
> to them in case host and guest endianness don't match?  I think at least
> the capabilities have 32bit values which need to be swapped.  Dunno
> about the gallium commands ...

For 3D we probably need to define the gallium command streams to be
little endian, however the big problem is the data that is stored
inside objects.
Texture and vertex, constants, indices etc. How do we decide to swap these,
when do we swap things, on the DMA transfers to the host, do we just
swap the formats on the host side etc.

I probably need to spend some time working this out with BenH, but
I'm not really sure how we can avoid backing ourselves into a large inefficent
hole at some point.

Dave.