summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLucas Stach <dev@lynxeye.de>2012-09-18 15:25:05 +0200
committerSt├ęphane Marchesin <marcheu@chromium.org>2012-10-08 15:30:34 -0700
commit4e8d1d601ba246065bf8552e4b96dd0174cc87a8 (patch)
treeffbae250d289424e4cf2dc1e5b40aada69038a8c
parentccd758a616ee4aa7627015c5b173d5f2c22f1d78 (diff)
rework gallium chapter (still incomplete)
-rw-r--r--linuxgraphicsdrivers.lyx140
1 files changed, 69 insertions, 71 deletions
diff --git a/linuxgraphicsdrivers.lyx b/linuxgraphicsdrivers.lyx
index da1fb2c..f2c148a 100644
--- a/linuxgraphicsdrivers.lyx
+++ b/linuxgraphicsdrivers.lyx
@@ -1825,8 +1825,8 @@ Obviously, with so many different memory types, performance is not homogeneous;
not all combination of accesses are fast, depending on whether they involve
the CPU, the GPU, or bus transfers.
Another issue which arises is memory coherence: how can one ensure that
- memory is coherent across devices, in particular that data written by
- the CPU is available to the GPU (or the opposite).
+ memory is coherent across devices, in particular that data written by the
+ CPU is available to the GPU (or the opposite).
These two issues are correlated, as higher performance usually means a
lower level of memory coherence, and vice-versa.
\end_layout
@@ -5900,8 +5900,8 @@ good enough
\end_inset
option if all you need is basic X compatibility.
- Similiarly the xf86-video-modesetting driver implements X.Org on top of an
- existing in-kernel KMS driver, again without hardware specific acceleration.
+ Similiarly the xf86-video-modesetting driver implements X.Org on top of
+ an existing in-kernel KMS driver, again without hardware specific acceleration.
\end_layout
\begin_layout Standard
@@ -6532,11 +6532,12 @@ XAA acceleration
\lang english
XAA was the XFree86 Acceleration Architecture, an interface inside Xorg
- implemented by drivers for 2D acceleration. It was created for XFree86 3.3,
- and was rewritten for XFree86 4.0. EXA was developed as a replacement, and
- after years of offering both interfaces, XAA was removed from the Xorg server
- after the Xorg 1.12 release. XAA is thus useful only for maintaining
- existing drivers and new drivers should write to another interface instead.
+ implemented by drivers for 2D acceleration.
+ It was created for XFree86 3.3, and was rewritten for XFree86 4.0.
+ EXA was developed as a replacement, and after years of offering both interface
+s, XAA was removed from the Xorg server after the Xorg 1.12 release.
+ XAA is thus useful only for maintaining existing drivers and new drivers
+ should write to another interface instead.
\end_layout
\begin_layout Standard
@@ -9109,50 +9110,17 @@ Gallium3D: a plan for a new generation of hardware
\end_layout
\begin_layout Standard
-
-\lang english
-Ten years ago, GPUs were a direct match with all the OpenGL or Direct3D
- functionality; back then the GPUs had specific transistors dedicated to
- each piece of functionality.
- With the explosion in the amount of 3D functionality, this quickly made
- it impractical both for application developers (who saw the 3D APIs growing
- huge) and hardware designers (who faced an explosion of the number of specific
- functionality a GPU needed), and shaders were created.
- Instead of providing specific functionality, the 3D APIs would now let
- the programmers create small shader programs and run them on the GPU.
- As the hardware was now programmable in a way which was a superset of fixed
- functionality, the fixed function pipelines were not required any more
- and were removed from the cards.
- Gallium 3D is modeled around the simple observation that today's GPUs do
- not have fixed pipe any more and only feature shaders, but drivers still
- have to
-\begin_inset Quotes eld
-\end_inset
-
-emulate
-\begin_inset Quotes erd
-\end_inset
-
- fixed function on top of the shaders to provide API compatibility.
- Doing so in every driver would require a lot of code duplication, and the
- Gallium model is to put this code in a common place.
- Therefore gallium drivers become smaller and easier to write and to maintain.
- The same concept is applied to other aspects of the 3D APIs like surface
- handling; things like mipmap generation, surface copies and pixel format
- conversions are all handled in common code and can be shared between multiple
- drivers.
-\end_layout
-
-\begin_layout Standard
-
-\lang english
-everything is a shader, including inside the driver
-\end_layout
-
-\begin_layout Standard
-
-\lang english
-thin layer for fixed pipe -> programmable functionality translation
+With the advent of shaders and thus programmable GPU hardware, the combinatorial
+ space of hardware functions exposed by GPUs got a lot smaller.
+ Gallium3D builds on this observation and tries to abstract away how GPUs
+ work internally into an universally useable interface, where shaders are
+ sitting at the core and the rest of the interface is there to control how
+ they are executed.
+ Keep in mind that Gallium3D is just a thin layer interface inside MESA
+ and so is a moving target.
+ There is no effort going into keeping the interface stable at any point;
+ if something inside it does not fit newly introduced GPUs the interface
+ is changed to cope with those changed capabilities.
\end_layout
\begin_layout Standard
@@ -9164,14 +9132,21 @@ global diagram
\begin_layout Section
\lang english
-State trackers
+Winsys
\end_layout
\begin_layout Standard
-
-\lang english
-A state tracker implements an API (for example OpenGL, OpenVG, Direct3D...)
- by turning it into API-agnostic and hardware-agnostic TGSI calls.
+The name Winsys is actually a bit of a misnaming, but it wasn't changed
+ since Gallium was introduced.
+ The Winsys provides the hardware drivers with an internal fixed interface
+ to talk to the operating system.
+ You can easily imagine a driver for the same hardware working on different
+ OSes, where you have to use differing interfaces to get hardware access
+ through the kernel.
+ The Winsys is meant to abstract those differences away.
+ Consequently drivers that are not meant to run on different OSes don't
+ need to implement a Winsys, although it might prove to be beneficial to
+ stick to this strict layering.
\end_layout
\begin_layout Section
@@ -9183,34 +9158,45 @@ Pipe driver
\begin_layout Standard
\lang english
-A pipe driver is the main part of a hardware-specific driver.
+Pipe drivers are the components that are actually implementing the Gallium
+ interface.
+ They are talking directly to the hardware, through the Winsys or direct
+ usage of the respective operating system routines.
+ The pipe driver has to fully hide how your hardware works internally.
\end_layout
\begin_layout Section
\lang english
-Winsys
+State trackers
\end_layout
\begin_layout Standard
\lang english
-The winsys is in charge of talking to the OS/Platform of choice.
- The pipe driver relies on the Winsys to talk to the hardware.
- For example, this allows having a single pipe driver with multiple winsyses
- targeting different Operating systems.
-\end_layout
-
-\begin_layout Section
-
-\lang english
-Vertex submission
+State trackers are sitting on top of the Gallium interface and implement
+ a specific API like OpenGL, OpenCL or other custom APIs that use the GPU
+ to accelerate something.
+ They do so by turning the API calls into hardware independent acceleration
+ operations covered by Gallium.
+
\end_layout
\begin_layout Standard
\lang english
-The VBO interface
+Gallium abstracts away most of the internals of the GPU, however it can
+ not hide the different featuresets exposed by the large numbers of GPUs
+ used today.
+ Some things are hidden internally, like some drivers using a JIT compiler
+ to do fallbacks when the GPU can't execute a specific shader and it seems
+ worthwhile to do a software fallback, but mostly the differences in capabilitie
+s are also reflected into the Gallium interface.
+ So before a state tracker can use a specific part of the Gallium interface
+ it has to ask the pipe driver it is running on currently if it supports
+ that one feature.
+ This is done using the respective pipe_cap, pipe_caf and pipe_shader_cap
+ function calls, depending on what the state tracker wants to know.
\end_layout
\begin_layout Section
@@ -9241,6 +9227,18 @@ pipe_transfer
\lang english
Shaders in Gallium
+\begin_inset Note Note
+status open
+
+\begin_layout Plain Layout
+
+\lang english
+Do we want to go this deeply into gallium stuff here?
+\end_layout
+
+\end_inset
+
+
\end_layout
\begin_layout Standard