5 ms·

I wouldn't go so far as to say "mistake that should never have been standardized". Their intended use was always pretty limited, though. There's zero reason for

I wouldn't go so far as to say "mistake that should never have been standardized". Their intended use was always pretty limited, though. There's zero reason for anything built in recent memory to use them.

jsheard 2y ago
They had limited uses and turned out to be incredibly hard to implement efficiently in hardware, so in practice it was nearly always faster to just keep using the proven techniques that GS was supposed to replace. http://www.joshbarczak.com/blog/?p=667 http://www.joshbarczak.com/blog/?p=667
- RantyDave 2y ago
  So why does instancing suck? I would have thought it would be heavily optimised in the driver...
  - p_l 2y ago
    It seems Device Generated Commands might be better case for instancing these days?
- comex 2y ago
  And yet one of the fancy new features being advertised in recent years (in multiple APIs including Metal) is support for mesh shaders – which seem to have a lot in common with geometry shaders, including the output ordering property that that post blames for geometry shaders’ bad performance. I’m not a graphics programmer myself, but this makes me suspect there’s more to the story.
  - dgfitz 2y ago
    If you’re not a graphics programmer, how did you learn of this? I’d love to read about it.
  - HeuristicsCG 2y ago
    if your hardware supports mesh shaders properly, it won't be very hard for it to also support these other features emulated in software (geometry shaders, tessellation, lines etc). But mesh shaders are fairly new, will take a few years for the hardware and software to adapt.
    - adrian_b 2y ago
      They are fairly new at the other GPU makers, but the NVIDIA GPUs have them starting with Turing, 6 years ago. AMD GPUs have them starting with RDNA 2.
  - winterismute 2y ago
    I am not an expert on geometry processing pipelines, however Mesh Shaders are specced differently from GS, essentially one of the big problems with GS is that it's basically impossible for the HW, even after all the render state is set and a shader is bound and compiled (and "searched"), to understand how much memory and compute the execution will take, which breaks a lot of the assumptions that allow SIMD machines to work well. In fact, the main advertised feature of GS was to create geometry out of nothing (unbounded particle effects), while the main advertised feature of Mesh Shaders is GPU-driven and efficient culling of geometry (see for example the recent mesh shader pipeline talk from Remedy on Alan Wake 2). It is true that Mesh Shaders are designed also for amplification, and that word has been chosen specifically to hint that you will be able to "multiply" your primitives but not generating random sequences out of thin air. It is also true however that advances in APIs and HW desgins allowed for some parts that were troublesome at the time of GS not to be so troublesome anymore.

jsheard 2y ago

They had limited uses and turned out to be incredibly hard to implement efficiently in hardware, so in practice it was nearly always faster to just keep using the proven techniques that GS was supposed to replace. http://www.joshbarczak.com/blog/?p=667 http://www.joshbarczak.com/blog/?p=667

RantyDave 2y ago
So why does instancing suck? I would have thought it would be heavily optimised in the driver...
- p_l 2y ago
  It seems Device Generated Commands might be better case for instancing these days?
comex 2y ago
And yet one of the fancy new features being advertised in recent years (in multiple APIs including Metal) is support for mesh shaders – which seem to have a lot in common with geometry shaders, including the output ordering property that that post blames for geometry shaders’ bad performance. I’m not a graphics programmer myself, but this makes me suspect there’s more to the story.
- dgfitz 2y ago
  If you’re not a graphics programmer, how did you learn of this? I’d love to read about it.
- HeuristicsCG 2y ago
  if your hardware supports mesh shaders properly, it won't be very hard for it to also support these other features emulated in software (geometry shaders, tessellation, lines etc). But mesh shaders are fairly new, will take a few years for the hardware and software to adapt.
  - adrian_b 2y ago
    They are fairly new at the other GPU makers, but the NVIDIA GPUs have them starting with Turing, 6 years ago. AMD GPUs have them starting with RDNA 2.
- winterismute 2y ago
  I am not an expert on geometry processing pipelines, however Mesh Shaders are specced differently from GS, essentially one of the big problems with GS is that it's basically impossible for the HW, even after all the render state is set and a shader is bound and compiled (and "searched"), to understand how much memory and compute the execution will take, which breaks a lot of the assumptions that allow SIMD machines to work well. In fact, the main advertised feature of GS was to create geometry out of nothing (unbounded particle effects), while the main advertised feature of Mesh Shaders is GPU-driven and efficient culling of geometry (see for example the recent mesh shader pipeline talk from Remedy on Alan Wake 2). It is true that Mesh Shaders are designed also for amplification, and that word has been chosen specifically to hint that you will be able to "multiply" your primitives but not generating random sequences out of thin air. It is also true however that advances in APIs and HW desgins allowed for some parts that were troublesome at the time of GS not to be so troublesome anymore.