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