Hardware accelerated rendering

Hardware accelerated rendering makes use of specialized hardware, usually a graphics processing unit (GPU), to speed up the process of rendering an image. Many real-time graphics applications make use of hardware acceleration.

= A little bit of history =


 * See also: History of computer graphics, History of graphics processing units

Early computer graphics applications like Spacewar! (1962), Sketchpad (1963) and Pong (1972) used vector graphics and rendered them to CRT displays. The computers driving the displays would continuously execute a set of drawing instructions which would steer the beam of the cathode-ray tube.[citation needed] [is it?] While vector graphics allow for "infinite" resolution, there are limits to how fast you can steer the beam of a cathode-ray tube and still get a reasonable image.[citation needed] Shapes which need an interior color other than black take an inordinate amount of time to draw compared to just drawing the outline.[citation needed]

[Explain bitmaps]. [Explain framebuffers]. The advent of high-density semiconductor-based memory enabled the development of SuperPaint (1973), a system capable of video editing and computer animation.

[Mention early fixed-pipeline hardware in consoles, arcade machines and computer expansion cards].

[Mention early re-programmable pipelines in graphics hardware].

[Beginnings of OpenGL].

[DirectX and OpenGL almost kind-of-sort-of merging?].

[Problems with OpenGL]. Fixed Function Pipeline

[OpenGL recieves various extensions which expose more and more lower-level bits of functionality].

AMD announces in September of 2013 that they're working with DICE to develop Mantle, a console-like API which lies closer to the metal. In doing so, AMD eventually sparked a revolution in the graphics API space.

Microsoft announces DirectX 12 at GDC 2014.

Apple announces Metal on June 2, 2014.

The Khronos Group announces that they're working on a replacement for OpenGL later refered to as "glNext".

AMD shifts gears in response to DirectX12 and the "glNext" initiative and donates the Mantle API to the Khronos Group to help kick-start the development of "glNext". During GDC 2015, the Khronos Group announces Vulkan, the result of the "glNext" initiative.

[Maybe also WebGPU].

= A Brief Comparison of the Various 3D Graphics APIs =

OpenGL

The oldest of the bunch. Deprecated by Apple on their platforms in 2018 in favor of Metal.

OpenGL ES

A stripped down version of OpenGL for use on resource-constrained systems.

WebGL

A JavaScript API based on OpenGL ES for use in web browsers.

DirectX < 12

Microsoft's OpenGL. Supported on Windows and Xbox. Uses COM, which can be frustrating to work with in Rust.

WebGPU

The result of the "WebGL Next" initiative. A simplified version of Vulkan intended for use on the web.

In-browser implementations are currently in progress and you can now run examples in both Firefox Nightly and Chrome Canary with their experimental WebGPU feature flags enabled. Note that Chrome Canary does not implement GPU sandboxing at the moment, so sites using the WebGPU API can read the GPU memory of other processes.

Native implementations, and dawn, also exist.

Metal

Apple's low-level 3D graphics API. Object-oriented. Supported on macOS and iOS. Similar to Vulkan.

DirectX 12

Microsoft's latest and greatest 3D graphics API. Supported on Windows 10 and the Xbox One and later. DirectX 12 Ultimate will make the API more portable between Windows and the Xbox. Like previous versions of DirectX, DirectX 12 uses COM. Similar to Vulkan.

Vulkan

Derived from AMDs Mantle. Exposes a C-based interface. Practically every structure defined by the specification is prefixed with both a  and   field. It helps make the API extensible, but it requires the use of  on the Rust side of things.

Not supported on Apple's platforms, but can be run on top of Metal through projects like and MoltenVK.

= General Concepts =

While the concepts outlined below should be mostly relevant for all of the modern 3D graphics APIs, the technical terms and explanations will mostly be drawing from how Vulkan does things.

Vertex

An application-defined primitive which is fed into and processed by the graphics pipeline.

A vertex often contains a position, but it does not have to do so.

Fragments

Shaders

Shaders are small programs which run directly on the GPU as a part of the graphics pipeline.

OpenGL expects shaders to be fed into the API as GLSL text.

Vulkan expects shaders to be compiled down to a binary representation called SPIR-V.

Metal expects shaders in "Metal Shading Language"

DirectX expect shaders in HLSL.

Vertex Shader

Runs on a per-vertex basis. This is where you transform, rotate and scale your 3D models in world space. This is also where you perform perspective projection.

Fragment Shader

Runs on a per-fragment basis. This is where the color of the fragments are decided. This is misleadingly called the pixel shader in Direct3D.

Surface
The surface is what the graphics pipeline renders to. This is usually a window.

= OpenGL-Specific Concepts =

The OpenGL context...

= Graphics Rendering In Rust =

glium
The earliest commit available in Glium's repository is was created on October 3, 2014, predating the announcement of Vulkan. Given the size of the commit, it is safe to assume that work on Glium started some time before the work was commited.

On August 27, 2016, Glium's author posted a "post-mortem" on URLO detailing things which he believes "went wrong" with Glium. The author had already reduced his activity on Glium to mostly merging pull requests and eventually seems to have handed the reins over to someone else.

gfx-rs
The  project is perhaps the most notable effort within graphics rendering in Rust.

Initially, the  crate could only run on OpenGL, but gained support for DirectX 11 with the release of  on March 21, 2016. It would later gain support for both Metal and Vulkan with the release of.

It became apparent as time went on that they needed target a lower level of abstraction to achieve the performance they were after. This led to the birth of CoreLL and later. was eventually adopted by WebRender , a GPU-based 2D rendering engine intended for use in Firefox and Servo.

The  repository's main branch is today home to the   crate and its various backends.

wgpu
The  project eventually gave rise to  an implementation of the experimental WebGPU API.

Rust Ecosystem
The graphics ecosystem for Rust is divided in 3 main categories:


 * Rust wrappers, which make it easier to interact in safe Rust with a given C API.
 * Raw FFI bindings, which only output the raw methods a C library will have.
 * Multi-API crates, which provide a single interface to use whatever backend they support.

In addition to these main categories, there are a couple of auxiliary categories of crates which you may or may not need depending on what you plan to do.


 * Shader compilers. When working with Vulkan or the  stack, you're going to need a shader compiler of some sort. While it is possible to pre-compile shaders using external command-line tools, these crates let you do it in your own Rust code.
 * Windowing crates. All of the above will let you draw content, but you usually need something to draw to: a window. These crates will allow you to create one or multiple windows for your program. These crates aren't strictly necessary if you're only leveraging the compute-capabilities of some of these APIs or if you're only generating some output file (e.g. a  or a PNG).

An important crate to note is. This crate provides a single trait:. This trait makes it easier for graphics libraries and windowing libraries to decouple from one another. For example, instead of hard-coding every window library that might exist,  instead can be used with any windowing library which uses the   crate.

Shader Compilers
You'll probably need one of these if you're going to use a library which wants to recieve shaders as SPIR-V.

Shader reflection
It is sometimes useful to determine the type, number and position of the inputs and outputs of a shader at runtime. The OpenGL specification includes functions for this purpose, but such functionality is intentionally left out of the Vulkan specification to lessen the work hardware vendors have to do. The following libraries aim to offer the functionality you're "missing out on" by using Vulkan.

Shader embedding
These crates offer macros which compile shaders defined in other files and then embed SPIR-V inside your executable (or library) in a manner similar to the and  macros in the standard library.

Windowing/Surface creation
If you're rendering something, you probably want to display it to a window. These crates will help you with that.

ash-molten
lets you statically link MoltenVK. This may not be desirable since  doesn't have access to validation layers. on its own already supports linking to MoltenVK at runtime. Static linking also prevents updates to MoltenVK.

vk-mem
provides FFI bindings and a Rust wrapper around AMD's Vulkan Memory Allocator (VMA).

glsl-layout
provides types which conform to the std140 memory layout for interface blocks. It also provides a couple of traits and a macro for defining custom types which conform to std140 layout rules. Has optional support for conversion to and from and  types.

shader-types
provides types which try conforming to the std140 memory layout for interface blocks. Deprecated in favor of due to "fundamental flaws" in how padding was achieved.

OpenGL

 * Glium's Tutorial
 * , a Rust port of https://learnopengl.com
 * , based on https://learnopengl.com
 * , a Rust port of https://vulkan-tutorial.com/
 * Rust and OpenGL from scratch. The link to the next tutorial is always somewhere at the bottom of the blog post.

OpenGL

 * https://learnopengl.com, a really top-notch tutorial. This tutorial also covers a couple of rendering techniques which are transferable to any graphics API.

Vulkan

 * https://vulkan-tutorial.com/