ARMGLESSupportInUbuntuArchive

  • Launchpad Entry: multimedia-arm-gles-in-ubuntu

  • Created: November 9th, 2010

  • Contributors: Ricardo Salveti

  • Packages affected: qt, clutter, efl, cairo

Summary

Currently most GL/GLES capable applications and toolkits assumes GL by default. Instead of GL, on ARM platforms the use of GLES is desirable, and should be used when possible. Achieve this at the archive by providing run time detection (GL or GLES) when possible or simply choosing GLES as the default on ARM. As current hardware vendor's drivers are quite unstable, an easy way to change back to software rendering (using mesa) will be provided.

Release Note

Instead of using GL by default, on ARM most GL capable applications and toolkits will now use GLES by default. This helps improving performance when GLES 3D drivers are available.

Rationale

As an inheritance of the x86 world, most applications and toolkits are built targeting GL as default, even when GLES is also supported. Run time detection is generally avoided by applications, and few toolkits export the GL specific code in different libraries, or backends, making the possibility to have more than one backend installed at the system harder. As a side effect, at ARM the users are not getting the best performance, when hardware vendor's drivers are available.

Another issue is that GLES drivers in general are unstable, and currently the user is unable to easily change to software rendering when the hardware vendor's driver is already installed. Conflict/replace is correctly provided, but an easier solution as alternatives would make easier for the user.

User stories

  • Alice wants to get the best performance from the GL capable applications at her ARM platform when using the correct 3D drivers.
  • Bob wants an easy way to use GLES software rendering with Mesa, without uninstalling his current drivers.

Assumptions

Design

  • Review what applications and toolkits assumes GL as the default
  • Change the GLES capable applications and toolkits to build with GLES support by default on ARM
  • Work with Linaro Graphics WG to identify the possibility to use runtime detection
  • Change how GLES drivers are deployed, to support an easier method to switch between them

Implementation

BoF agenda and discussion

  • Experience from the Maverick
    • Clutter problems
      • backends with slightly different API with different SONAME
      • building different packages would create a completely different application hierarchy
      • in maverick we unified the frontend APIs and shipped two libraray packages that were interchangable that bring the new gles or GL backend
      • some work on implementing missing frontend functions was done
      • hide symbols that were not supposed to be exported
      • making packages look the same makes harder to select all ES or all GL
        • ideal solution is that all applications have plugins that do the right thing -> this would require that the whole stack is installed for GL and GLES

        • another solution was to pick GLES as the default even on intel -> problem is that not all chipsets are properly supported by GLES -> what about the proprietary drivers? -> can GLES and GL mixed in one application?

        • GLES 2.0 will not be in good enough state this cycle to do the full switch
        • GLES 2.0 for armel only? will not benefit from main desktop testing
  • Problem with runtime selection in toolkits
    • How to not mix GL/GLES contexts
    • Cairo GL backend can create its own context and also gets context passed in from application
    • Can cairo in this case check what type of context this is to select the right backend?
    • Toolkit has to create its own thread for its context
    • Or in corner cases the application is reponsible to pass the context and tell the toolkit what GL type this is
  • consent: for natty use GLES backends on armel and GL on !armel
  • clutter hides the GL from the frontend
  • How can we improve the way GLES drivers are shipped; e.g. mesa software GLES + GLES for mali?
    • previously GL could be installed in parallel and alternatives system was available to switch between drivers
    • nowadays packages are not installable in parallel; hard conflicts exist that prevent easily switching back and forth
    • can we have alternatives for GLES? alternatives have been a pain in GL world and RAOF does not want to repeat that mistake (it broke ABI in the past).
    • Can we do similar as proprietary amd driver on desktop? the mesa gles driver is installed by default, and when install some proprietary gles driver for sgx or other gpu cores, first backup the mesa gles driver by renaming, then replace the mesa driver with the proprietary gles driver; when uninstall the proprietary driver, the mesa gles driver is reverted back.
    • what about SONAME mismatch of vendor vs. mesa; ACTION:
  • Toolkits:
    • clutter
    • efl
    • qt
    • cairo
  • Applications:
    • firefox
  • Decide how to support gles out of ubuntu archive for those
    • build gles instead of gl on armel
    • when possible, select proper backends at runtime
    • this effects cairo, qt, efl, compositors and applications etc.

Actions: (check whiteboard from https://blueprints.launchpad.net/ubuntu/+spec/multimedia-arm-gles-in-ubuntu)

Packages that can be ported

Package

Comment

compiz

Once work is done by Linaro

compiz-fusion-plugins-main

Once work is done by Linaro

kde-window-manager

After KDE 4.7 is released, check https://blueprints.launchpad.net/linaro-graphics-wg/+spec/multimedia-linaro-compositors-1105 for more info

clutter

Wait for revert from Maverick and then change to GLES by default

evas

Change and test

nux

Once work is done by Linaro

qt-x11

Change and test

mesa-utils

Change and test

There are also some games and applications that could be converted to GLES, but probably need work to get the patches right from communities like Pandora and N900 before changing the package itself.


CategorySpec

Specs/N/ARMGLESSupportInUbuntuArchive (last edited 2011-01-14 19:23:15 by 63)