3 ms·

> There is a great deal of space between 'fixed function pipeline' (which no one is using) and 'all compute all the time' (which pretty much no one is using for

> There is a great deal of space between 'fixed function pipeline' (which no one is using) and 'all compute all the time' (which pretty much no one is using for real-time graphics). Assuming "fixed function pipeline" means the currently standard programmable pipeline that most people use (and not the extremely old fixed-function pipeline), is there really much of a difference from 100% compute pipelines? If compute shaders had the ability to manually invoke the hardware rasterizer, what functional difference would there be? The only other major difference I can think of is how the non-compute pipelines can optimize keeping data in registers/cache between different shader steps that can't really be done with compute shaders.

Const-me 4y ago
> non-compute pipelines can optimize keeping data in registers/cache between different shader steps that can't really be done with compute shaders That’s exactly the problem addressed by mesh shaders. Each thread group of the mesh shader outputs a batch of triangles to be rasterized. These batches have a hard limit of 32kb of output data per batch. I think such a small size limit is there so the vertex + primitive data stays in the faster memory, inside the GPU chip.
- slabity 4y ago
  I agree, but that only reinforces the point that there doesn't even seem to be much of a difference between the older graphical pipeline and a 100% compute pipeline. If graphics drivers could just allow compute shaders to manually call the rasterizer and give functionality to control what data stays in memory in different parts of a pipeline/command-buffer, then you'd be able to implement both the older graphical pipeline and the newer task/mesh shader pipeline entirely in compute shaders. I'm not entirely experienced in how graphics hardware works at a lower level though, so I'm sure I must be missing something important.

Const-me 4y ago

> non-compute pipelines can optimize keeping data in registers/cache between different shader steps that can't really be done with compute shaders That’s exactly the problem addressed by mesh shaders. Each thread group of the mesh shader outputs a batch of triangles to be rasterized. These batches have a hard limit of 32kb of output data per batch. I think such a small size limit is there so the vertex + primitive data stays in the faster memory, inside the GPU chip.

slabity 4y ago
I agree, but that only reinforces the point that there doesn't even seem to be much of a difference between the older graphical pipeline and a 100% compute pipeline. If graphics drivers could just allow compute shaders to manually call the rasterizer and give functionality to control what data stays in memory in different parts of a pipeline/command-buffer, then you'd be able to implement both the older graphical pipeline and the newer task/mesh shader pipeline entirely in compute shaders. I'm not entirely experienced in how graphics hardware works at a lower level though, so I'm sure I must be missing something important.