OpenGL ES 2.0 Enabling and Acceleration in MeeGo Simulator and Emulator

This is a continuum of the first MeeGo conference presentation of "OpenGL acceleration in MeeGo Simulator and Emulator" at http://conference2010.meego.com/session/opengl-acceleration-meego-simula....

As MeeGo graphics system swtiches from GLX/OpenGL to EGL/GLES 2.0, it brings new challenges on EGL/GLES enabling in MeeGo simulator and emulator. The challenge is that there is no software rendering supporting in Mesa for EGL/GLES. So Haitao added a new feature for EGL driver in Mesa for CPU software rendering. With this feature, we could run MeeGo handset and tablet UX again in MeeGo simulator and emulator. This feature code patch has been accepted by Mesa upstream. Please refer to http://cgit.freedesktop.org/mesa/mesa/commit/?id=b43a147128a1144a5fe4afc... and http://cgit.freedesktop.org/mesa/mesa/commit/?id=f55d027ac2e0423eba5d066....

The software rendering is just an enabling and its performance is not good enough. So Zhiyuan added EGL/GLES acceleration for MeeGo emulator Qemu. The approach is to re-use our existing work for OpenGL acceleration and convert the EGL/GLES to GLX/OpenGL in the MeeGo image (the Qemu guest). We leveraged the converter library from Nokia Qemu project at http://meego.gitorious.org/qemu-maemo/gles-libs.

At the third part of this presentation, we will discuss the general approaches to solve the OpenGL |ES acceleration problems in simulator and emulator. The general approach is graphics API forwarding and the forwarding could be done at various level of the graphic stack:
1) At the top level, we could forward the OpenGL| ES out, create host GL| ES context, render the GL| ES API by using host library and synchronize the render buffer back. We have done this in Qemu.
2) At the middle level, we could forward the DRI2 API out, create host GL| ES context, pass the host DRI2 buffer handle to GL| ES application and synchronize the render buffer back. We have done this in Xephyr for OpenGL acceleration.
3) At the lower level, we could forward the DRM API out, re-map the DRI2 buffer and make host render the simulated or emulated buffer directly. This is on the concept stage.
4) At the bottom level, we could define a fake hardware which has its own command buffers. We could forward the command buffer API out and let host render the emulated buffer directly. It could be possible to re-use the fake hardware design used by vmware for this purpose since it has an open source guest driver.