Gallium3D: Graphics Done Right

Download as pdf or txt
Download as pdf or txt
You are on page 1of 24

Gallium3D

GraphicsDone Right

Zack Rusin [email protected]

Contents

Recap

Gallium3D

General summary Why would you want to use it. Gallium3D latest changes Taking request (no singing)

Zack Rusin [email protected]

DRI Driver Model


drm

App

Mesa

DRI Driver

DRI

Drivers were tied to OS, API, window system. EG, dealing with DRI cliprects in DrawArrays. Driver interface becoming unmanageable.
Zack Rusin [email protected]

DRI Driver Model

Zack Rusin [email protected]

Graphics Pipeline

Essentially the same for all modern API's

Zack Rusin [email protected]

Impose new interfaces


drm

App

Mesa

DRI Driver

DRI

Isolate interactions with API, OS, HW. Identify new interfaces. Split the driver.
Zack Rusin [email protected]

Gallium in 2007
drm

App

Mesa

State tracker

Gallium HW Driver

OS, Winsys DRI

The original plan for Gallium3D. Still more or less correct.

Zack Rusin [email protected]

Since then...

Rapid interface evolution Hopefully starting to stabilize, but there are still some minor issues outstanding. On the horizon: simplify TGSI shader representation Changes in the draw module New insights into fallbacks, driver structure. New utility code

Zack Rusin [email protected]

Since then...

Got some hardware drivers working


I915 (updated to head) softpipe Cell driver i965 Nouveau R300 work

External driver projects:


Zack Rusin [email protected]

Building blocks

Gallium3D at its core is just an interface The actual functionality is split across different modules

Those modules can be mix-and-matched to produce a complete solution

Zack Rusin [email protected]

Building blocks

Important modules within the framework include:

State trackers

Implement API on top of Gallium3D Integration with a windowing system, low level management (surfaces, buffers and fencing) Implements the Gallium3D interface

Winsys

Gallium3D driver

Zack Rusin [email protected]

Building blocks

Important modules within the framework include:

Draw

Software vertex paths constant state objects management

CSO

Buffers management code TGSI code LLVM integration A few others (sct, util)
Zack Rusin [email protected]

Software Rasterizer

App

Mesa

State tracker

softpipe

any winsys X

Codegen through LLVM and simple rtasm. A fairly clear path to performance. A good project for someone?
Zack Rusin [email protected]

Hardware: i915
i915 drm State tracker

App

Mesa

i915

intel winsys DRI

Updated to the latest DRM changes. Near term goal: Rebase to X, DRM head. Later: DRI2, Polish, Performance...
Zack Rusin [email protected]

It works on Windows
DD DX9 State tracker

App

XP/DX9 Runtime

i915

XP winsys HW

This is actually working. Validates the portability claims for Gallium.


Zack Rusin [email protected]

...It'll work anywhere


Your OS Your Graphics API HERE Your Winsys HERE Your WM

App

i915

DirectFB, VxWorks, Kdrive, GLES, Cellphones, Robots, FreeBSD, MiniGLX, EGL, Clusters, etc. Wider audience --> better drivers.
Zack Rusin [email protected]

You don't even need hardware...

App

Mesa

State tracker

i965simple

Simulator Winsys

a file

A nice way to work on hardware you don't actually have available. Easy to capture, analyze dumps offline. TODO: Replay
Zack Rusin [email protected]

Shaders

At the very core of Gallium3D TGSI used throughout

Drivers can either:


Use TGSI directly Employ LLVM code-generation facilities

Zack Rusin [email protected]

LLVM

TGSI compiled into LLVM IR LLVM optimization passes used Drivers implement LLVM code-generator

Zack Rusin [email protected]

Winsys issues
i915 drm State tracker

App

Mesa

i915

intel winsys DRI

GLX implemented by DRI + the Winsys layer Swapbuffers, create surface, etc, seem to bypass this nice stack.
Zack Rusin [email protected]

Winsys issues

Neat diagram above ignores non-drawing aspects of the driver. There is real complexity here:

Surface allocation happens before context creation GL extensions need to know (approximately) before context creation. Swapbuffers

Currently winsys is splitting into two entities: per-screen and per-context. May end up with a parallel stack, ie:
Zack Rusin [email protected]

What's in a winsys?
State tracker HW context

GL App

Context i915 drm

GLX

HW info

Screen DRI

Orange components... A lot of interfaces... Small piece of code, but complex. SOON: Split it up for a clearer stack.
Zack Rusin [email protected]

New diagram

Zack Rusin [email protected]

Summary

We're getting there. Interface churn should start to slow down, but some pain still to come. Focus to shift:

Performance Conformance & correctness Stabilization

Zack Rusin [email protected]

You might also like