Over the last decade or so, the GPU has gone from something of a
nice-to-have feature to an absolute must, across a lot of industries. You
can hardly boot a modern system without supporting Vulkan or OpenGL (ES).
Technologies such as LLVMpipe has allowed us to emulate such hardware, at
a significant performance and memory bandwidth loss. It's proven very
useful for purposes such as bringing up new platforms before GPU support
has been added, for instance. And it can be a great solution in some cases
where the amount of data to process is low.
But in some industries, the needs for compute-pipeline processing power
greatly outweigh the needs for graphics-pipeline processing power. Yet
most GPUs still have fixed function graphics-pipeline support, such as
primitive assembly, rasterization, blending. Implementing these in
hardware is a very time-consuming task, and can sometimes brings little
For instance, a modern camera processor needs to perform heavy image
processing algorithms, even though it might not have a display. In such
cases, a GPU compute kernel is typically used.
It should be entirely possible to implement a reusable graphics pipeline
on top of the compute-pipeline, paving the way for simpler GPU designs
while still remaining useful. Think of this approach as something like
LLVMpipe, except generating compute shader kernels instead of CPU code.
Implementing a compute-shader-only GPU is something that's much more
feasible for new players, for instance for an initial open source GPU
|Code of Conduct||Yes|
|GSoC, EVoC or Outreachy||No|
|For which conference do you send the proposal?||X.Org Developers Conference 2022|
|In-person or virtual presentation||In-person|