5 ms·

Is anyone else astonished at how much is missing in the hardware and how much is emulated?

jsheard 2y ago
The things being emulated are mostly legacy features that are barely used in modern software, if at all, so the overhead of emulating them for backward compatibility isn't the end of the world. I can't blame Apple for not supporting geometry shaders in hardware, when they're widely considered to be a mistake that never should have been standardized in the first place, and Metal never supported them at all so they could only ever come up in old OpenGL code on macOS. https://x.com/pointinpolygon/status/1270695113967181827 https://x.com/pointinpolygon/status/1270695113967181827
- raverbashing 2y ago
  Tessellation does not seem to fit this description though
- parl_match 2y ago
  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.
dtquad 2y ago
The graphics pipeline in modern GPUs are mostly a thin low-level Vulkan/Metal-like layer on top of a massively parallel CUDA-like compute architecture. It's basically all emulated. One of the reasons GPU manufacturers are unwilling to open source their drivers is because a lot of their secret sauce actually happens in software in the drivers on top of the massively parallel CUDA-like compute architecture.
- almostgotcaught 2y ago
  I didn't read the article and don't know about Apple but that's definitely not true for everyone. Source: see amdgpu built on top of HSA. EDIT: to be precise yes ofc every chip is a massively parallel array of compute units but CUDA has absolutely nothing to do with it and no not every company buries the functionality in the driver.
  - hilti 2y ago
    [flagged]
- david-gpu 2y ago
  As a former insider, this is NOT remotely how I would describe reality. I have signed NDAs and don't feel comfortable going into any detail, other than saying that there is a TON going on inside GPUs that is not "basically all emulated".
  - user_7832 2y ago
    Maybe a tall ask, but have you considered writing down all your experiences into a book, and release it after all NDAs expire? I’d love to read more about low level hardware and the behind the scenes stuff involved. I’m sure you’ve got a lot of good stories.
    - almostgotcaught 2y ago
      > I’d love to read more about low level hardware and the behind the scenes stuff involved. I’m sure you’ve got a lot of good stories. I don't know why you think there's anything resembling "good stories" (I don't even know what would constitute a good story - swash buckling adventures?). It's just grimy-ass runtime/driver/firmware code interfacing with hardware features/flaws.
tedunangst 2y ago
Is this really so different from any other mobile derived GPU?
- refulgentis 2y ago
  Idk, TIL, had a career in mobile for 15 years running and I didn't know this was a distinctive quality of mobile GPUs. (makes sense! but all that to say, I'm very interested to hear more, and I'll trade you an answer to that question: "maybe not! sounds like you got some smart stuff to share :)")
- ferbivore 2y ago
  Yes. Apple have their own graphics API. They were able to decide that, say, geometry shaders aren't worth the chip area or engineering effort to support. Other IHVs don't get that choice; for geometry shaders, for instance, they're part of both Vulkan and OpenGLES, there are games and benchmarks that use them, and customers (end-users, gamedevs, review/benchmark sites, SoC vendors) will evaluate GPUs based, in some small part, on how good their geometry shader support is. Same story for tessellation, transform feedback, and whatever else Apple dropped.
  - fingerlocks 2y ago
    I don’t think it’s accurate to say Apple “dropped” these features. Tessellation is done with general purpose compute shaders. You can do the same with “geometry shaders” if the need arises as well
  - dagmx 2y ago
    Other hardware vendors absolutely do the same. Geometry shaders are poor performers on several other vendors for precisely the same reason
    - ferbivore 2y ago
      At least some Qualcomm, Imagination and Broadcom GPUs support geometry shaders in hardware. Not entirely sure about Arm. To be fair, it could be the support isn't very good.

The things being emulated are mostly legacy features that are barely used in modern software, if at all, so the overhead of emulating them for backward compatibility isn't the end of the world. I can't blame Apple for not supporting geometry shaders in hardware, when they're widely considered to be a mistake that never should have been standardized in the first place, and Metal never supported them at all so they could only ever come up in old OpenGL code on macOS. https://x.com/pointinpolygon/status/1270695113967181827 https://x.com/pointinpolygon/status/1270695113967181827

raverbashing 2y ago
Tessellation does not seem to fit this description though
parl_match 2y ago
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.

dtquad 2y ago

The graphics pipeline in modern GPUs are mostly a thin low-level Vulkan/Metal-like layer on top of a massively parallel CUDA-like compute architecture. It's basically all emulated. One of the reasons GPU manufacturers are unwilling to open source their drivers is because a lot of their secret sauce actually happens in software in the drivers on top of the massively parallel CUDA-like compute architecture.

almostgotcaught 2y ago
I didn't read the article and don't know about Apple but that's definitely not true for everyone. Source: see amdgpu built on top of HSA. EDIT: to be precise yes ofc every chip is a massively parallel array of compute units but CUDA has absolutely nothing to do with it and no not every company buries the functionality in the driver.
- hilti 2y ago
  [flagged]
david-gpu 2y ago
As a former insider, this is NOT remotely how I would describe reality. I have signed NDAs and don't feel comfortable going into any detail, other than saying that there is a TON going on inside GPUs that is not "basically all emulated".
- user_7832 2y ago
  Maybe a tall ask, but have you considered writing down all your experiences into a book, and release it after all NDAs expire? I’d love to read more about low level hardware and the behind the scenes stuff involved. I’m sure you’ve got a lot of good stories.
  - almostgotcaught 2y ago
    > I’d love to read more about low level hardware and the behind the scenes stuff involved. I’m sure you’ve got a lot of good stories. I don't know why you think there's anything resembling "good stories" (I don't even know what would constitute a good story - swash buckling adventures?). It's just grimy-ass runtime/driver/firmware code interfacing with hardware features/flaws.

tedunangst 2y ago

Is this really so different from any other mobile derived GPU?

refulgentis 2y ago
Idk, TIL, had a career in mobile for 15 years running and I didn't know this was a distinctive quality of mobile GPUs. (makes sense! but all that to say, I'm very interested to hear more, and I'll trade you an answer to that question: "maybe not! sounds like you got some smart stuff to share :)")
ferbivore 2y ago
Yes. Apple have their own graphics API. They were able to decide that, say, geometry shaders aren't worth the chip area or engineering effort to support. Other IHVs don't get that choice; for geometry shaders, for instance, they're part of both Vulkan and OpenGLES, there are games and benchmarks that use them, and customers (end-users, gamedevs, review/benchmark sites, SoC vendors) will evaluate GPUs based, in some small part, on how good their geometry shader support is. Same story for tessellation, transform feedback, and whatever else Apple dropped.
- fingerlocks 2y ago
  I don’t think it’s accurate to say Apple “dropped” these features. Tessellation is done with general purpose compute shaders. You can do the same with “geometry shaders” if the need arises as well
- dagmx 2y ago
  Other hardware vendors absolutely do the same. Geometry shaders are poor performers on several other vendors for precisely the same reason
  - ferbivore 2y ago
    At least some Qualcomm, Imagination and Broadcom GPUs support geometry shaders in hardware. Not entirely sure about Arm. To be fair, it could be the support isn't very good.