TEXT   72

arm mobile graphics stack on x

Guest on 28th May 2022 03:20:56 PM

  1. ## page was renamed from Specs/M/ARMEmbeddedGraphicsPerformanceOnX
  2. ##(see the SpecSpec for an explanation)
  3.  
  4.  * '''Launchpad Entry''': [[https://blueprints.launchpad.net/ubuntu-arm/+spec/arm-m-graphics-stack-on-x ]]
  5.  * '''Created''':
  6.  * '''Contributors''':
  7.  * '''Packages affected''':
  8.  
  9. == Topics ==
  10.  
  11.  * requirements for graphics drivers for a good X11 experience
  12.    * version alignment
  13.  * performance benchmarking on X
  14.  * 3D story on X and arm
  15.  * video/multimedia on X and arm
  16.  
  17.  
  18. === Driver Requirements for X ===
  19.  
  20.  * Kernel driver:
  21.   * Compatibility with kernel 2.6.32 (Lucid) or higher.
  22.   * KMS (Kernel Mode Setting) - hard requirement
  23.     * no transitioning resolution of the bootsplash and X
  24.     * seamless visual experience from bootsplash to X
  25.     * Mode setting happens in the LCD driver
  26.     * faster and more reliable suspend/resume
  27.   * Compatibility with the userspace libdrm 2.4.18 (Lucid) or higher -> usually backwards compatible -- no general need version alignment
  28.     * separation of LVDS control and GPU (due to licencing of external GPU tech) makes DRM/KMS integration harder
  29.     *
  30.   * Support for RandR output hotplug events (so that the xserver receives an event when external screens are connected or disconnected)
  31.   * GEM (Graphics Execution Manager), TTM (Translation Table Maps) or an alternative kernel video memory manager
  32.     * needed for DRI2 to work (aka accelerated redirected/offscreen 3D/GL)
  33.     * needed for OpenGL extensions like FBOs (GL_ARB_framebuffer_object)
  34.     * GEM is usually safe wrt backwards compatiblility
  35.     * GLX_texture_from_pixmap needed because of the window-manager/compositor mutter used by unity
  36.     * XDamage, XFixes, XComposite (might be needed to be supported on the driver side)
  37.     * TTM can be looked at as an implementation detail, as a subset of GEM support
  38.   * Dynamic front buffer resizing as in -intel's UXA (so that we don't have to set the virtual resolution and restart X when dealing with external screens using high resolutions)
  39.  
  40.  * DDX (X.Org) driver:
  41.   * Compatibility with xserver 1.7.x (Lucid) or higher (1.8.x)
  42.     * needs to be aligned version wise
  43.   * Support for RandR 1.3 (especially transformations, scaling, etc.)
  44.     * version does not change frequently -- minimum should be >= 1.2 to get good multi head support
  45.     * current development is ongoing for xinerama support
  46.   * Use of the E-EDID functions in X.org (this is useful for HDMI)
  47.     * currently not well supported as typically arm devices have been directly connected to the display
  48.     * likely will need some other mechanism to get the resolution choices to xrandr
  49.     * currently the resolution is hard coded into the kernel
  50.   * DRI 2 (Direct Rendering Infrastructure) which allows GLX applications to do direct rendering to redirected windows. This makes OpenGL and XV (X video extension) work correctly with compositing managers.
  51.  
  52.  * What is needed to get fast graphics to 'clutter/mutter' level??
  53.    * seems to be a limitation that the graphics drivers are mostly OpenGL ES (sp?) which is a sub-set of that required by these layers
  54.    * graphics performance is also suspected to be lower, particularly compositing off screen is slow
  55.    * one option may be to require full OpenGL drivers and exclude OpenGL ES
  56.      * OpenGL is a software API though; doesn't imply any minimum level of hardware support
  57.      * concerns expressed that requiring too high a level will blow the power budget for some use cases
  58.  
  59.  * Multimedia:
  60.   * Support for either VA-API (Video Acceleration API) or VDPAU (Video Decode and Presentation API for Unix) to allow video programs to offload portions of the video decoding process and video post-processing to the GPU video-hardware.
  61.    * does not really matter to use gstreamer
  62.  
  63.  * 3D driver:
  64.   * OpenGL 2.1 (or later) compliant driver, more specifically we would like to have the following extensions available:
  65.    * GL_ARB_framebuffer_object
  66.    * GL_ARB_vertex_program
  67.    * GL_ARB_fragment_program
  68.    * GL_ARB_texture_non_power_of_two
  69.    * GL_EXT_stencil_two_side
  70.    * GL_ARB_vertex_buffer_object
  71.   * Support for GLSL
  72.   * chromium has bad performance with opengles even with
  73.     *
  74.  
  75.   * minimum hardware requirements
  76.     * opengl hardware with opengles 2.0 or better
  77.     *
  78.  
  79. === Performance / Benchmarking ===
  80.  
  81. Goals:
  82.  * Provide a way to easily test and benchmark their hardware and drivers
  83.   * Custom Images with Benchmarks being auto run
  84.   * Report results to a database  
  85.  * Provide easy way to demo graphics capabilities of devices
  86.   * Full desktop
  87.   * Benchmarks
  88.  
  89. Performance tests:
  90.   * 3D tests
  91.    * phoronix-test-suite (openGL based tests)
  92.      * both performance and correctness tests, is already in the archive for use
  93.      * there are not any OpenGL ES specifc tests, though there are some at Intel not yet committed to the repo
  94.        * will be needed for this effort
  95.      * some of this is available from Khronos group perhaps
  96.      * [Jay] To write some simple tests to test the OpenGL ES 2.0 implementation . Tests to cover what Unity needs as a first step
  97.      * unity relevant tests -> dx team could develop test suites
  98.      * powervr published a testsuite for opengles included in their SDK
  99.      * webos seems to have some simple test tool under http://www.webos-internals.org/wiki/GLES_1.1_3D_Cube_Demo
  100.    * games: needs porting to opengles --
  101.   * 2D tests
  102.    * gtkperf (to test performance with GTK+)
  103.    * cairo-perf-trace (to test performance of apps which use cairo e.g. firefox) http://cworth.org/intel/performance_measurement/
  104.      * make it easy to select the backend for validation: opengl, xrandr, etc.
  105.      * a good game to test OpenGL ES is ioquake3 (ACTION: investigate/package up) - http://github.com/Cpasjuste/quake3_pandora_gles
  106.  
  107.  
  108. === Discussion/Notes ===
  109.  
  110. Discussion notes inline above.
  111.  
  112. Primary deliverables
  113.  * clear documentation of the expected version compatibility levels to have good performance on Ubuntu
  114.  * [Jay Taoko] good test suites to confirm performance and expose choke points
  115.    * allow easy running of those benchmarks with automatic result
  116.  * maybe package opegles games for showcasing the hardware
  117.  * Conduct a survey of the current partners graphical rendering models (immediate vs. deferred)
  118.  
  119. ----
  120. CategorySpec

Raw Paste


Login or Register to edit or fork this paste. It's free.