diff options
Diffstat (limited to 'linuxgraphicsdrivers.lyx')
| -rw-r--r-- | linuxgraphicsdrivers.lyx | 140 |
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 |