1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

This Is What Started AMD's Open-Source Strategy

Michael Larabel

Published on 17 September 2011
Written by Michael Larabel
Page 5 of 6 - 57 Comments

  1. 3D Support

Given that most state-of-the-art graphics chipsets no longer facilitate a separate fixed-function 3D pipeline block, all OpenGL commands have to be translated into vertex/fragment shaders. The Mesa Project already provides some basic functionality to support this in the OpenGL client library (libGL). The shaders required for transformation and lighting are well known.

At NOVELL we are convinced that we are able to implement OpenGL shader support at least to the extent as it is currently available in the free DRI driver for the R300 chipset generation. This will allow for some basic 3D programs like compositing managers, and it would allow to implement 2D and Xv acceleration support using the OpenGL shader language in Glucose. The complexity of adding loops and conditional branches, which are the main conceptual improvements compared to previous chipsets, is difficult to evaluate without additional information about the interface design of the GPU.

AMD has the option to replace this basic shader support with its own proprietary module to provide extra optimizations that may be required in certain enterprise level use cases. Hooks required by a such a proprietary module which provides shader optimization and arbitration could be added to the 3D driver. The basic 3D implementation would remain free software which would help to diffuse a lot of criticism from the community.

Implementing 3D support will touch four components while 2D support will benefit from some of these changes as well:

  1. DRM kernel module
    This kernel module watches over memory allocation and is required to provide verification of the command buffers before they are passed down to hardware to avoid malicious commands from being executed. Currently all existing DRM drivers provide this command validation in the kernel module. The R600 chipset generation includes a fully programmable command processor (CP). Taking advantage of this CP instruction validation the required functionality could be implemented in the GPU, freeing the CPU from this work and removing a lot of context switches. To do this however, it would be required to limit the programming of the CP to kernel space. As there is presently no infrastructure in place for the implementation of this functionality, this should probably be introduced as an optimization in a second step.
    In any case, to implement such verification steps detailed knowledge of the CP and GPU stream command set is required.
    If NOVELL implements separate 2D acceleration in the X.Org driver this will benefit from support for DMA command buffers, in contrast to the old IO/MMIO-port programming model.
    One big unknown in estimating the complexity of this work is the influence of virtualized buffers that are used everywhere in the new design of the latest ATI chipset generation. An initial implementation might use fixed size buffers only.

  2. libdrm
    This is the user-space part of DRM, mostly coupled to the kernel module. Thus library interfaces to system calls in the kernel need to be added here.

  3. DRI driver
    The main part of the 3D driver resides in the Mesa OpenGL client side library. This library abstracts many details of OpenGL already. Drivers are free to provide acceleration for certain functionalities and short-circuits for special code paths.

  4. X.Org driver
    The communication infrastructure doesn't have to be extended significantly, as almost no driver-dependent code is required there. The 2D driver needs to accommodate for the 3D driver using graphics memory, though, and as the agent in charge of overall control over the graphics hardware needs to setup and enable the 3D components by calling the appropriate hooks.

Development should take place following roughly the steps below (extension lists not complete but exemplary):

  1. Implementation of memory management for z-, shader, and command buffers.

  2. Implementation of command buffer functionality.

  3. Implementation of engine setup and buffer management.

  4. Basic shader support: ARB_fragment_program, ARB_vertex_program.

  5. Primitive support, basic framebuffer blending operations, z- and scissor tests. Clipping.

  6. Emulation of a fixed function pipeline with shaders as far as not already supported in Mesa.

  7. implementation of basic texturing (RGBA8 only), including extended memory management.

Given the complexity of 3D graphics drivers \u2013 and lack of knowledge of the new ATI chipset generation \u2013 a time evaluation is difficult to make. NOVELL is confident, however, to have basic 3D support available (development step 7, shaders without optimization) within six to nine man months.

This comprises only very basic 3D support, additional functionalities will be added as necessary to accommodate for composited desktops like Compiz, first running Xgl (which is simpler due to less required functionality), than AIGLX:

  1. Add EXT_texture_from_pixmap, ARB_texture_non_power_of_two, EXT_subtexture.

  2. Provide AIGLX support.

Subsequently, functionality may be added in order of relevance to get full OpenGL 1.4 support implemented. Mesa's backward compatibility features may help to attain OpenGL 2.1 support automatically, though shaders will have to include loops and conditional branches.

The order given in the list below is just a rough estimate (this list is not exhaustive):

  1. Enhanced shader support: full swizzling, implementation of less common instructions.

  2. Implementation of less common blending operators, stencil buffers, alpha and stencil tests.

  3. More enhanced shader support: loops and conditional jumps, complex instructions.

  4. Enhanced shader support: virtualization, as far as this is not already implemented in 1. and 3.

  5. Implementation of additional texture formats (for environment + normal mapping, float textures, luminance)

  6. Support for antialiasing.

  7. Enhanced shader support: geometry shaders.

  8. Support for pBuffer + frame buffer objects (needs general support in DRI).

  9. Floating point framebuffer (general support in Mesa/DRI).

  10. Improving usage of the CP for command verification and engine setup.

  11. Improving arbitration in the dispatch processor, as far as this is programmable / configurable.

  12. Support for Tessellator (needs new extension).

These functionalities will be verified against simple test programs throughout development. Verification against complex OpenGL programs like games will be performed with the help of the community and AMD.

Latest Linux Hardware Reviews
  1. AMD Launches New FX CPUs, Cuts Prices On Existing Processors
  2. Preview: AMD's FX-9590 Eight-Core At Up To 5.0GHz On Linux
  3. Intel Launches The Core i7 5960X, Mighty Powerful Haswell-E CPUs
  4. AMD Radeon R9 290: Gallium3D vs. Catalyst Drivers
Latest Linux Articles
  1. LLVM Clang 3.5 Brings Some Compiler Performance Improvements
  2. Ondemand vs. Performance CPU Governing For AMD FX CPUs On Linux 3.17
  3. How Intel Graphics On Linux Compare To Open-Source AMD/NVIDIA Drivers
  4. The Fastest NVIDIA GPUs For Open-Source Nouveau With Steam Linux Gaming
Latest Linux News
  1. POCL Is Maturing Well For Running OpenCL On The CPU
  2. New Group Calls For Boycotting Systemd
  3. The Features To Find With The Imminent Release Of LLVM/Clang 3.5
  4. Borderlands 2 Is Coming To Linux
  5. The Witcher 2 Ups The Performance More & Works Around Catalyst Bug
  6. Running Gallium3D's LLVMpipe On The Eight-Core 5GHz CPU
  7. Trying Intel OpenCL On Linux For Video Encoding
  8. GSoC 2014 Yielded Some Improvements For Mesa/X.Org This Year
  9. webOS Lives On As LuneOS With New Release
  10. Marek Lands Radeon Gallium3D HyperZ Improvements
Latest Forum Discussions
  1. Lennart Poettering Talks Up His New Linux Vision That Involves Btrfs
  2. nv and xorg.conf under Debian PPC
  3. AMD graphics doesn't work with AMD Catalyst drivers
  4. Best Radeon for a Power Mac G5?
  5. The dangers of Linux kernel development
  6. Updated and Optimized Ubuntu Free Graphics Drivers
  7. AMD Releases UVD Video Decode Support For R600 GPUs
  8. SSD seems slow