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
DRM kernel module
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.
any case, to implement such verification steps detailed knowledge of
the CP and GPU stream command set is required.
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.
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.
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.
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
Development should take place following
roughly the steps below (extension lists not complete but exemplary):
Implementation of memory
management for z-, shader, and command buffers.
Implementation of command buffer
Implementation of engine setup and
Basic shader support:
Primitive support, basic
framebuffer blending operations, z- and scissor tests. Clipping.
Emulation of a fixed function
pipeline with shaders as far as not already supported in Mesa.
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),
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
shader support: full swizzling, implementation of less common
of less common blending operators, stencil buffers, alpha and
enhanced shader support: loops and conditional jumps, complex
shader support: virtualization, as far as this is not already
implemented in 1. and 3.
of additional texture formats (for environment + normal mapping,
float textures, luminance)
shader support: geometry shaders.
pBuffer + frame buffer objects (needs general support in DRI).
point framebuffer (general support in Mesa/DRI).
usage of the CP for command verification and engine setup.
arbitration in the dispatch processor, as far as this is
programmable / configurable.
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.