3 ms·

> I really wish that everybody would finally admit that the "fixed function pipeline" is dead There is a great deal of space between 'fixed function pipeline'

> I really wish that everybody would finally admit that the "fixed function pipeline" is dead 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 either). > GPUs don't yet have a well-defined memory model Nvidia has a memory model. (I have heard--from an nvidia employee--that amd plays a bit more fast and loose.) https://www.youtube.com/watch?v=VogqOscJYvk https://www.youtube.com/watch?v=VogqOscJYvk > GPUs don't have the equivalent of an MMU--so they can't be partitioned or protected. etc. You do not need an MMU to partition or to protect. (Not to say that GPU security isn't a shitshow.) > The problem is that switching to a "compute" model and making that work well would commodify the GPU--and that's the last thing that AMD and NVIDIA want. https://s22.q4cdn.com/364334381/files/doc_financials/2023/Q223/Rev_by_Mkt_Qtrly_Trend_Q223.pdf https://s22.q4cdn.com/364334381/files/doc_financials/2023/Q2... look at where nvidia's revenue is coming from, and tell me again that they're not already there.

slabity 4y ago
> 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.

slabity 4y ago

> 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.