Gallium

http://www.freedesktop.org/wiki/Software/gallium/

Gallium3D其实是一个接口层，解耦上层操作与驱动之间的联系：

主要接口

• pipe_context 结构体(p_context.h), 其中定义了和context相关的函数集，这些函数主要包括如下功能：

  • Setting rendering state (texture sampler state, blending state, rasterization state, vertex array info, drawing surfaces, etc.)
  • Setting shader state, using the TGSI binary shader representation.
  • Vertex array and indexed vertex array drawing.

• pipe_screen结构体，包含与context无关的信息和函数集

  • Creating textures (and drawing surfaces)
  • Getting “views” into textures
  • Hardware queries (number of texture units, max texture size, etc).
  • Creating generic memory buffers
  • Mapping/unmapping buffers
  • Fencing

• 另外还有一些数据结构定义在p_state.h中

  • Graphics state (blending, texture sampling, rasterization)
  • Texture and surface resources
  • Vertex array layout

State tracker

It’s responsible for translating Mesa state (blend modes, texture state, etc) and drawing commands (like glDrawArrays and glDrawPixels) into pipe objects and operations.

Traditional fixed-function OpenGL components (such as lighting and texture combining) are implemented with shaders. OpenGL commands such as glDrawPixels are translated into textured quadrilateral rendering. Basically, any rendering operation that isn’t directly supported by modern graphics hardware is translated into a hardware-friendly form.

Ancillary Modules

A number of ancillary modules are available to Gallium3D drivers:

1. The Draw module provides point/line/polygon rendering services such as vertex transformation, polygon culling and clipping. It will be used by drivers for hardware which lacks vertex transformation (such as the i915/i945). It may also be instantiated and used directly by the state tracker to implement some API functionality that doesn’t map well to hardware capabilities.

2. The TGSI module provides a universal representation of shaders and CPU-based execution of shaders. All Mesa vertex/fragment programs and shaders are translated into the TGSI representation before being passed to the driver. In turn, the driver will convert the TGSI instructions into GPU-specific instructions. For hardware that lacks vertex or fragment shader support, the TGSI’s executor can be used. The TGSI executor includes support for SSE code generation. Support for other processors (such as Cell) will be added in the future.

3. The RTASM module provides support for Run-Time Assembly/Machine code generation. There are sub-modules for X86/SSE, PPC and Cell machine code generation.

4. The CSO module provides support for Constant State Objects. CSOs help to filter out redundant state changes from getting sent to the driver. State changes can be expensive and we want to avoid them whenever possible.

5. The util module has code for debugging, image manipulation, hashing, math and miscellaneous helper routines.

TGSI, Tungsten Graphics Shader Infrastructure, is an intermediate language for describing shaders. Since Gallium is inherently shaderful, shaders are an important part of the API. TGSI is the only intermediate representation used by all drivers.

术语解释

Resources

Resources represent objects that hold data: textures and buffers.

They are mostly modelled after the resources in Direct3D 10/11, but with a different transfer/update mechanism, and more features for OpenGL support.

Resources can be used in several ways, and it is required to specify all planned uses through an appropriate set of bind flags.

Transfers

Transfers are the mechanism used to access resources with the CPU.

• OpenGL: OpenGL supports mapping buffers and has inline transfer functions for both buffers and textures
• D3D11: D3D11 lacks transfers, but has special resource types that are mappable to the CPU address space

Resource targets

Resource targets determine the type of a resource.

Note that drivers may not actually have the restrictions listed regarding coordinate normalization and wrap modes, and in fact efficient OpenCL support will probably require drivers that don’t have any of them, which will probably be advertised with an appropriate cap.

PIPE_BUFFER

Buffer resource: can be used as a vertex, index, constant buffer (appropriate bind flags must be requested).

Buffers do not really have a format, it’s just bytes, but they are required to have their type set to a R8 format (without a specific “just byte” format, R8_UINT would probably make the most sense, but for historic reasons R8_UNORM is ok too). (This is just to make some shared buffer/texture code easier so format size can be queried.) width0 serves as size, most other resource properties don’t apply but must be set appropriately (depth0/height0/array_size must be 1, last_level 0).

They can be bound to stream output if supported.
TODO: what about the restrictions lifted by the several later GL transform feedback extensions? How does one advertise that in Gallium?

They can be also be bound to a shader stage (for sampling) as usual by creating an appropriate sampler view, if the driver supports PIPE_CAP_TEXTURE_BUFFER_OBJECTS. This supports larger width than a 1d texture would
(TODO limit currently unspecified, minimum must be at least 65536). Only the “direct fetch” sample opcodes are supported (TGSI_OPCODE_TXF, TGSI_OPCODE_SAMPLE_I) so the sampler state (coord wrapping etc.) is mostly ignored (with SAMPLE_I there’s no sampler state at all).

They can be also be bound to the framebuffer (only as color render target, not depth buffer, also there cannot be a depth buffer bound at the same time) as usual by creating an appropriate view (this is not usable in OpenGL). TODO there’s no CAP bit currently for this, there’s also unspecified size etc. limits TODO: is there any chance of supporting GL pixel buffer object acceleration with this?

• OpenGL: vertex buffers in GL 1.5 or GL_ARB_vertex_buffer_object

  • Binding to stream out requires GL 3.0 or GL_NV_transform_feedback
  • Binding as constant buffers requires GL 3.1 or GL_ARB_uniform_buffer_object
  • Binding to a sampling stage requires GL 3.1 or GL_ARB_texture_buffer_object

• D3D11: buffer resources - Binding to a render target requires D3D_FEATURE_LEVEL_10_0

Surfaces

Surfaces are views of a resource that can be bound as a framebuffer to serve as the render target or depth buffer.
TODO: write much more on surfaces

• OpenGL: FBOs are collections of surfaces in GL 3.0 or GL_ARB_framebuffer_object
• D3D11: render target views and depth/stencil views

Sampler views

Sampler views are views of a resource that can be bound to a pipeline stage to be sampled from shaders.
TODO: write much more on sampler views

• OpenGL: texture objects are actually sampler view and resource in a single unit
• D3D11: shader resource views