SDK/Qemu/OpenGLES

Currently two different approaches exist for providing hardware acceleration for OpenGL in qemu.

Contents 1 Today 1.1 dgles2 1.2 virtio-gl 2 Future 2.1 Approach 1, dgles2-based virtual gpu 2.2 Approach 2, glx-based transport

Today

dgles2

• EGL, OpenGL ES2, OpenGL ES 1.1
• Transport: custom
• Device interface: custom, arm-specific
• Works on Handset UX arm

Rough overview:

• OpenGL ES application (MeeGo Handset UX for example)
  • links against
• fgles2 library (implements in libEGL, libGLESv2 and libGLES_CM ABI inside TARGET)
  • passes requests to
• kfgles2 kernel module
  • writes message request to Qemu iomem area
• QEMU reads the request parameters and copies memory buffers
  • passes request to
• dgles2 (implements in libEGL, libGLESv2 and libGLES_CM ABI on the HOST)
  • translates to desktop OpenGL
• host OpenGL library (glx on linux, wgl on windows, agl on apple, osmesa as fallback)

virtio-gl

• glx, OpenGL
• Transport: glx
• Device interface: virtio
• Works on x86 Netbook UX and older versions of x86 handset UX

Rough overview:

• OpenGL application (MeeGo Netbook UX for example)
  • links against
• meego-emulator-libgl-x86
  • passes request to
• meego-gl-virtiomem
  • writes glx requests (with buffers) to
• QEMU virtio-gl-pci reads requests
  • passes to host glx libraries
• host OpenGL library (glx on linux, wgl on windows

Future

In future we want to merge these to one approach. Several alternatives are considered:

Approach 1, dgles2-based virtual gpu

• Refactor fgles/kfgles/qemu to use a "virtual gpu" with ram, io and interrupt
  • On X86 change target from meego-emulator-libgl to the "new" fgles library
  • On ARM, make attach the new virtual device to qemu omap

• + Architecturally cleaner
• + Slightly faster on Qemu ARM
• + Compositing can be done faster in the vgpu ram without memcopy
• - More work
• - Support needs to be added to Desktop GL if netbook UX is to be supported
• - Impact on Xorg ?
• - Protocol between guest and qemu needs to defined

Approach 2, glx-based transport

• Run dgles2 _inside_ Qemu with glx backend
  • On X86, use virtio-gl as-is
  • On ARM, make virtio available

• + Faster to implement
• + Uses defined protocol (glx)
• + Desktop GL would continue to work as is.
• - Architecturally slighty hacky
• - glx does not have all egl features
• - Slightly slower on ARM as gles->gl translation is done inside Qemu

Variant for this approach: instead of dgles2, use Mesa egl_glx backend.

• - Works on EGL/GL, doesn't on EGL/GLES. work effort unkown.