Skip to content

BGRA Emulation issues on GLES hosts

Creating this issue to organize the progress towards a more stable and compatible guest-GL on host-GLES experience.

Currently there are several issues surrounding the limited capability of GLES in the context of texture format conversions/views. To work around these inherent issues in the GLES spec, virglrenderer has had support for various extensions added such as EXT_texture_format_BGRA8888, and EXT_sRGB_write_control.

Still, problems persist because BGRA textures are incompatible with glTexStorage*() on GLES, which causes several applications to exhibit rendering bugs, such as GIMP and glxgears. Multisampled default framebuffers are also unsupported, and now marked as illegal resources since 0bf0fa4f, causing the entire viewport to render as black.

The current approach for alleviating BGRA resource issues on GLES hosts is to rely on EXT_texture_format_BGRA8888 as much as possible, and fall back to RGBA storage + red/blue channel swizzling during rendering to emulated surfaces, sampling from emulated textures, and blitting to/from an emulated surface.

Still there seem to be a few holes in the emulation as it exists today, periodically spitting out the following errors:

  • ERROR: GL_INVALID_OPERATION in glTextureView(internalformat GL_BGRA not compatible with origtexture GL_RGBA8)
  • ERROR: GL_INVALID_ENUM in glTexStorage2D(internalformat = GL_BGRA)
  • vrend_resource_create, Illegal resource parameters, error: Unsupported multisample texture format 2

To test, be sure to start qemu with -display sdl,gl=es rather than -display sdl,gl=on.

Using qemu v6.0.0 with -display sdl,gl=es, ToT virglrenderer, and <1mo old guest Mesa, starting the VM immediately exhibits red/blue channel swizzling across the OS ui in my ubuntu guest, which is also exhibited for guest user applications. This, I believe is the result of switching BGRA emulation to "default-on" instead of the previous "default-off" prior to mesa/mesa!6847 (merged). Previously, emulation was enabled for selected user applications (games) that exhibited issues, but now since it's always enabled, emulation is applied to the OS ui as well. By reverting guest mesa to default-off behavior, at least the OS ui, gimp, and glxgears are rendered correctly.

On Chrome OS, we've recently had to set VIRGL_DEBUG=noemubgra for the Xserver process of all of the virgl-enabled guests to work around this. I think at the very least, the default-off behavior should be reinstated, and it may be time to consider an overhaul of the emulation mechanism. This work has been started with a new mesa extension and the WIP virglrenderer integration. More discussion on that is in #216 (closed)

If you give it a try, please comment with your findings.

bgra emulation default-on:
qemu_gles_redblueswap

bgra emulation default-on but manually disabled for glxgears:
qemu_gles_noemubgra

bgra emulation default-off for OS and apps:
qemu_gles_bgra-emulation-default-off

Edited by Ryan Neph
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information