Gallium3d introduction-from DRI to gallium3d

1. G Allium 3D

Gallium3d is a new 3D model. There are a lot of online comments, so I won't talk nonsense here.

This article is translated from Keith whitwell's speech:

TG-gallium driver stack (softpipe, cell and beyond), keith@tungstengraphics.com.

2. Slave DRI Evolved G Allium 3D DRI

 

Before gallium3d, to achieve hardware acceleration, Mesa's dri architecture is as follows:

Figure Mesa dri (non-gallium3d)

The author believes that this model has the following Disadvantages:

(1) leaky interface between Mesa and the driver;

(2) The driving system is huge and increasingly complex;

(3) api OS related things are also written in the driver;

The Mesa dri model causes the DRI driver layer to be too large. The dri driver is usually related to hardware, which leads to great development work to apply new devices.

Therefore, the good idea is that it is necessary to extract hardware-independent things on the DRI driver layer. So they proposed a preliminary idea, namely, dividing it into three layers:

Figure dri driver layering (non-gallium3d)

This model has the following features:

(1) Separate APIs, OS, and HW;

(2) a new interface is created;

(3) Split drive (similar to the first one)

Now the idea of dri-Driven Hierarchy is put into practice and the following model is obtained:

Figure dri driver layering (gallium3d)

This model has the following features:

● Added three modules: State tracker, HW driver, and winsys;

● Tg-gallium driver stack

 

3. G Allium 3D Features and reference implementation

 

Driver Model:

● By gl3 (OpenGL 3.0 ?), Nv_gpu4, i965, and other software and hardware abstract interfaces;

● Normal state object;

● Simple drawing interfaces, such as drawarrays and drawelements;

● Unified shade language in the form of bytecode;

● The render target serves as a private buffer;

● Hardware drivers can be run on new interfaces, such as gl3 and gles;

● Hardware drivers can be run in the new window system;

 

Hardware DRIVER:

● Much simpler than the DRI driver;

● Interface:

-Create/bind/delete status object;

-Draw, 1-2 entries;

-Buffer management;

-Flush

● Each Gallium driver defines its own OS layer (winsys) interface;

● Re-implement the winsys layer to re-target the driver, such as miniglx and EGL;

 

Mesa StateTracker

● Implemented the current Mesa driver model;

● A new hardware driver interface is used.

● Hardware independence and reusable;

● Convert the GL status to a common type object;

● All obscure GL concepts are handled:

-All different GL draw paths;

-Pixel path operations, drawpixels, bitmap, and copyt exsubimage

-Gl texture semantics;

-Texture environment, gl1.5 shader, glsl

 

O/s Dependencies

● Each Gallium driver defines its OS-layer winsys interface;

● The retarget driver can be switched to the winsys layer;

 

Winsys Layer

● Two interfaces are implemented:

-Dri Driver Interface: createdevice, createcontext, swapbuffers (**)

-Winsys interface of hardware driver: buffer management and command submission;

● The following content is encapsulated:

-Dri lock and cliprects

-Swapbuffers, page flipping.

-General operating system related content;

 

Mesa provides the gallium3d driver software reference implementation softpipe:

Figure gallium3d driver reference implementation softpipe

Mesa also provides the gallium3d driver's i915 reference implementation softpipe:

Figure gallium3d driver reference implementation i915