Anonymous user
Graphics stack: Difference between revisions
Jump to navigation
Jump to search
no edit summary
| [unchecked revision] | [unchecked revision] |
mNo edit summary |
No edit summary |
||
Line 1:
'''''[NOTE:''' This article's original text was based on [http://forum.osdev.org/viewtopic.php?f=13&t=31328 a post in the forum]. It needs further cleanup and review. --[[User:Schol-r-lea|Schol-r-lea]] 10:19, 4 February 2017 (CST)]''
== Introduction ==
At the lowest level we have the device drivers, which communicate with the actual hardware. These need to be able to work with either the specific display devices - the video memory, the GPU if any, the video signal generators, and even the monitor - or some common subset of it which it shares with disparate adapters. However, this does not mean that the driver must do all the work alone. The VESA VBE/Core defines a standard minimal interface to the hardware as an extension BIOS, which a complaint video adapter should provide as a way of interfacing with the hardware without needing any proprietary details of the adapter.▼
There is no fixed way to implement video handling, and many hobby operating systems develop their UI as a unit, at least initially. However, for a number of practical reasons, most systems end up separating the details of communicating with the hardware from the process of rendering the image, and that in turn from the management of higher-level concerns such as window layout. In most systems, this leads to a layered approach that could be call the '''''graphics stack''''', analogous to the networking stack.
== A Generalized Graphics Stack ==
There is not fixed model for how to layer the graphics stack, though most are fairly similar. A general model for a graphics stack might look like this:
# Application Layer
# Interoperation Layers
## Desktop Management Layer
## Window Management Layer
# Presentation Layers
## Display Management Layer
## Rendering Layer
# Display Layers
## Device Driver Layer
## Hardware Layer
This is close to most of the well-known graphics stack, such as Microsoft Windows, MacOS, X Window System, and Wayland, though not identical to any of them. The order of layers may differ, some layers may be missing or merged together, and some may have additional layers or even multiple stacks (e.g., has separate Client and Server Stacks, with their own Display Layers, and splits some aspects of the remaining stacks between the Server, which is the program requesting the display, and the Client actually doing the display - since the Client-Server relationship in X is potentially many-to-many, several details cannot be specified by either the Server or the Client.
=== Device Driver Layer ===
▲At the lowest software level, we have the device drivers, which communicate with the actual hardware. These need to be able to work with either the specific display devices - the video memory, the GPU if any, the video signal generators, and even the monitor - or some common subset of it which it shares with disparate adapters. However, this does not mean that the driver must do all the work alone. The VESA VBE/Core defines a standard minimal interface to the hardware as an extension BIOS, which a complaint video adapter should provide as a way of interfacing with the hardware without needing any proprietary details of the adapter.
Somewhere here you would find things like the Mesa driver framework and the Xlib Direct Rendering Manager. This level doesn't have a formal name in most systems, at least not as far as I know of, which is a first abstraction layer which software system (not necessarily the operating system itself) provides to give a uniform model for drawing pixels on the screen, while still exposing the underlying hardware. The split between 2-D and 3-D often starts around here, as a 3-D renderer generally needs a lot more direct hardware access than a 2-D one.
=== Rendering Layer ===
Then next level is the renderer, which is where . This is where you really see 3-D becoming a separate thing, as most systems prior to, say, 2007 would have used a strictly 2-D rendering for everything that didn't specifically require 3-D rendering, due to the need for hardware acceleration for practical real-time 3-D rendering at the time. As Brendan has pointed out before, right now the Cycle of Reincarnation for graphics rendering has been swinging towards CPU-driven rendering since the 2012 or so, though dedicated rendering hardware is still dominant at the moment. Note, however, that the graphics rendering Wheel of Incarnation has been rolling since the very first days of computer graphics in the early 1960s, so it is a good guess that this won't be the last word on the subject.
| |||