Summary

Release Note

Rationale

As more and more User interface code depends on OpenGL (ES), we need to accelerate rendering it. Also, being able to use OpenGL ES on desktop machines is wanted.

User stories

  • As a user, I want run inside emulator software that needs OpenGL ES.
  • As a developer, I want to be able to develop OpenGL ES software on desktop PC.

Assumptions

Design

fgles (fake gles)

  • Library that implements EGL, OpenGL ES 1.1 and 2.0 APIs. does nothing but passes calls to kfgles

kfgles (kernel fgles)

  • Kernel module that passes calls from fgles to qemu via iomem area

qemu hw/gles* code

  • The ugliest piece in the soup. reads gles call arguments from registers and copies buffers from gues userspace to host userspace. The reason why it was done so originally, is that copies in guest userspace (under TCG) is expensive. Needs to be rewritten as a gpu where buffers and call arguments are in a virtual gpu ringbuffer/ram, if upstream acceptance is wanted. (a few (3-4) months full time work)

dgles (desktop gles)

  • Library that implements EGL, OpenGL ES 1.1 and 2.0 APIs. does the actual translation to GLX, Windows GL and Apple GL. Can be used alone without

    Qemu. (Minimum desktop GL version >= ~2.0)

Code Changes

The bulk of code changes is creating a patch for qemu-linaro.

Test/Demo Plan

Unity with OpenGL ES inside Qemu?

Unresolved issues

Upstreaming.

BoF agenda and discussion

Refactored from session notes.

Maemo used a bit of opengl in UI (compositor), but MeeGo uses OpenGL ES for rendering widgets. Thus, accelerated OpenGL ES(2.0) rendering became needed, if acceptable UI performance was wanted. This became a problem for the QEMU based emulator in SDK.

Code was formed starting from a patch sent to qemu list for accelerating OpenGL in qemu (x86->x86). The code was rewritten to support arm->x86, and library to translate GL ES to GL was created.

Alternatives:

  • what is kvm + spice going to do for 3d accelerations?
  • gallium based accelerated 3d as done by vmware?
  • virtio-gl transport from intel also exists, but is not directly upstreamable.
  • something completly different?
  • just wait for OpenGL 4.0 with full EGL/GLES 2.0 compatability?
  • Android has some GLESv2 for emulator merged recently
  • Virtual box has GL support as well.

Work items:

Package dgles2 to ubuntu? Rewrite the transport to upstreamable? And add to vexpress?

  • Make it available at Ubuntu/Debian
    • Make the patches available at the qmeu-linaro package (if not at the archive at least at a PPA)
    • Provide a demo image (or instructions) on how to use it, to get more visibility
    • Understand the side effect of need to maintain the patch set over the cycle
    • could conflict with a newer solution and break current users support
  • Plan a way to push the work upstream
    • Check other solutions
    • Discuss with upstream to see what would be the long term solution
    • Need to find out more about spice, to their plans and such
    • Once we have a conclusion, we can follow the remaining work items to make this available upstream

Upstream comments about 3D approaches: https://lists.linux-foundation.org/pipermail/virtualization/2010-November/015747.html

project contacts: No homepage, mailing list, but public git exists: http://meego.gitorious.org/qemu-maemo/gles-libs


CategorySpec

Platform/DevPlatform/Specs/Oneiric-QemuOpenGLES (last modified 2011-05-18 13:03:30)