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 3 of 6 - 57 Comments

  1. What help can NOVELL offer?

X.Org Driver for ATI Radeon HD 2000 series

Novell will be happy to implement a driver for AMDs R600 hardware generation for the X Window System as implemented by X.Org.

We suggest the following procedure:

Initially this driver will be developed as a separate module. This module gets loaded automatically by the current 'ati' driver wrapper or as a stand alone driver or depending on the PCI id of the hardware \u2013 once support for this is available. An independent module guarantees minimal interference with ongoing development in the existing 'radeon' driver, while allowing us to exactly match the agreed upon features without delay. Once this driver is published the code can, depending on the desires of the developers community, be merged into the existing 'radeon' driver.

Development of the driver will take place in a step by step process:

        1. Basic Driver

    At first an initial driver will be implemented which will:

  • POST uninitialized hardware,

  • perform basic device initialization (like disabling VGA compatibility),

  • map and enable access to memory and I/O resources,

  • save/initialize and restore of video modes.

This will be implemented to the extent required to initialize a basic single analog output mode. It will utilize the new mode setting architecture of RandR 1.2 from the outset. It will allow to support dynamic reconfiguration of modes and output devices once these are implemented.

At this point work on other subsystems can commence in parallel:

        1. Multiple Output Subsystems

Support for the second display controller, I²C busses, DDC, DVI encoders, and overlay sprites (hardware cursors) will be added. Depending on the availability of hardware, support for directly linked panels (LVDS/TTL) for Mobility devices can also be added at this stage.

The code will be structured that this could easily accomplished, once people start moving mode setting out of the Xsever and into either a separate daemon or into the kernel. Of course NOVELL will be happy to support this work, too.


We estimate that the implementation of a basic driver, dual display support with analog/DVI support, I²C, DDC and overlay sprites will require roughly 3 man months. This is of course a preliminary estimate, as detailed knowledge of the underlying hardware is currently not available. It also depends on the availability of programming information and the level of support from AMD regarding questions about hardware details.

Support for the Xillion HDTV encoder, 30bit color and color correction can be evaluated and estimated later, when more information is available. Implementation of this can take place at a later stage.

        1. 2D Acceleration

To the best of our knowledge the old 2D acceleration engine has been removed from the latest generation of AMD graphics hardware. In this case it will be necessary to use 3D functionalities to implement accelerated 2D rendering.
Currently three options for 2D acceleration exist:

    1. The XAA (X Acceleration Architecture) has been designed as an abstraction to interface X core protocol requests onto functionalities for classical 2D acceleration engines. XAA has been extended only minimally to support the RENDER extension, which is used for most modern graphics operations and compositing. Some best efforts have been made to map RENDER operations on existing XAA functionality. Presently, for most hardware XAA provides the most reliable 2D acceleration architecture still.

    2. EXA is a new architecture that has been designed to accommodate the needs of image composition (alpha blending) better. While it provides the same basic functions and raster operations (ROPs) as XAA as for screen to screen copy or solid fills it also provides infrastructure to support alpha blending.

    3. Glucose: Glucose maps 2D functionalities onto OpenGL requests. Like Xgl \u2013 a fully OpenGL based Xserver implementation previously done bu NOVELL \u2013 it makes full use of an underlying OpenGL implementation to accelerate 2D operations. If such an OpenGL implementation is available no other driver support is required to accelerate 2D graphics. It uses the same code paths as Xgl and allows to intermix RENDER and OpenGL for image transformation and compositing.

    While the first and second approach only require the implementation of a fixed set of functionalities on the 3D engine, the last approach will most likely require a full OpenGL implementation. On the other hand, as a full OpenGL implementation almost is a requirement today, one would get 2D acceleration practically for free. We believe that this acceleration will be sufficiently fast \u2013 if not faster \u2013 than most (incomplete) EXA implementations.

    Still some basic EXA support might be required to ensure backward compatibility to older versions of X11 which do not provide Glucose.

An exact time estimate will depend on the agreed upon feature set. Basic acceleration functions like ScreenToScreenCopy and RectFill can definitely be developed in 3 to 4 man weeks for option a and b once the basic infrastructure is in place. Option c will be easier to implement once an OpenGL implementation exists. It will accelerate almost all possible raster operations but to attain the required quality of the OpenGL implementation more time will be required.

    Regardless of which approach is taken, it is clear that if we fully depend on the 3D engine for even basic 2D rendering we will need to acquire some knowledge on the 3D engine and shader programming to address 2D acceleration. More detailed requirements are listed in the respective sections.

Latest Linux Hardware Reviews
  1. Acer B286HK: A 28-inch UHD LED 4K Monitor For As Low As $350
  2. Intel Xeon E5-1680 v3 & E5-2687W v3 Compared To The Core i7 5960X On Linux
  3. Intel 120GB 530 Series SSD Linux Performance
  4. Btrfs/EXT4/XFS/F2FS RAID 0/1/5/6/10 Linux Benchmarks On Four SSDs
Latest Linux Articles
  1. Mesa Git Yields Performance Improvements For Newer AMD GPUs
  2. Apple OS X 10.10 vs. Ubuntu 14.10 Performance
  3. Mesa 10.5-devel Brings Some Intel Haswell HD Graphics Changes Over Mesa 10.3
  4. NVIDIA vs. Nouveau Drivers With Linux 3.18 + Mesa 10.4-devel
Latest Linux News
  1. Intel Has Last Round Of DRM Changes For Linux 3.19, Starts Dropping DRI1/UMS
  2. Fedora 21 Release Candidate 1 Awaits Your Testing
  3. GCC 5 Adds Support For ARM's Cortex-A17
  4. KWayland Server Component Coming For KDE Plasma 5.2
  5. NVIDIA Posts Tegra Gallium3D Patch For K1+ Support
  6. Ubuntu 14.10 MacBook Air Tests With Linux 3.18, Mesa 10.5
  7. AMD Richland APU Support Added To Coreboot
  8. 2014 Holiday Shopping Reminder, Happy Thanksgiving
  9. Python 3 Support Added To The GNOME Shell
  10. ReactOS Lands Its New Explorer Shell
Latest Forum Discussions
  1. Updated and Optimized Ubuntu Free Graphics Drivers
  2. Hurrican SDL Port
  3. Roadmap to Catalyst 14.10 ?
  4. how to configure module phoromatic ?
  5. PulseAudio 6.0 Is Coming & Other Linux Audio Plans For The Future
  6. Debian Developer Resigns From The Systemd Maintainership Team
  7. Cant get working Kaveri APU - A10-7850k
  8. Script for Fan Speed Control