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