3 ms·

The Turing architecture is a bit more sophisticated than that: "Like Volta, the Turing SM is partitioned into 4 sub-cores (or processing blocks) with each sub-

The Turing architecture is a bit more sophisticated than that: "Like Volta, the Turing SM is partitioned into 4 sub-cores (or processing blocks) with each sub-core having a single warp scheduler and dispatch unit" "Like we saw in Volta, these changes go hand-in-hand with the new scheduling/execution model with independent thread scheduling that Turing also has, though differences were not disclosed at this time. Rather than per-warp like Pascal, Volta and Turing have per-thread scheduling resources, with a program counter and stack per-thread to track thread state, as well as a convergence optimizer to intelligently group active same-warp threads together into SIMT units. So all threads are equally concurrent, regardless of warp, and can yield and reconverge." GPU 'cores' are still not as general as a full CPU core but they are a fair bit more flexible and sophisticated than a SIMD lane. https://www.anandtech.com/show/13282/nvidia-turing-architecture-deep-dive/4 https://www.anandtech.com/show/13282/nvidia-turing-architect...

vardump 7y ago
Interesting. So what are the sub-core limitations execution flow wise? Or is it truly generic? Can there be execution level conflicts? Like execution flow could be taken, but execution resources constraining (stalling) it somehow? I'm only talking about "per clock" view, not about hardware threading. Sometimes these terms are mixed in a bit hard to decipher fashion.
- mattnewport 7y ago
  It's hard to get detailed information on a lot of this as much of it is considered proprietary by NVIDIA. My understanding is that threads are not truly independent as they would be on full CPUs but that the hardware is able to dynamically detect thread divergence (when different lanes / threads of the SIMDish hardware take different branches) and intelligently regroup the threads to minimize divergence. I'm not sure how they then deal with instructions that operate across a warp, it's possible those interfere with the regrouping but they're not commonly used in many typical pixel shader workloads so it may be an overall win. I suspect some of these changes were to make raytracing more efficient (and the Anandtech article suggests as much too). A common problem trying to implement a GPU raytracer on older architectures is performance tanking when rays diverge too much. NVIDIA's Optix did some complicated magic to try and regroup divergent threads but having direct hardware support for it probably makes the raytracing GPU code both simpler and more efficient.
zozbot234 7y ago
The description is unclear, but these look more like hyperthreads/SMT units than true CPU cores. It's talking about "scheduling resources" implemented in hardware, which suggests a SMT model.
- jcranmer 7y ago
  GPUs are already SMT processors, since that's how they handle main memory latency. Instead, I suspect it's essentially dynamic warp formation to handle cases where there's still enough threads to keep all the lanes busy, but they're spread out over several static 16-thread chunks instead of being right next to each other.
  - zozbot234 7y ago
    > GPUs are already SMT processors, since that's how they handle main memory latency. I thought they used a simpler barrel-processor model to handle that. SMT seems a bit more sophisticated.

vardump 7y ago

Interesting. So what are the sub-core limitations execution flow wise? Or is it truly generic? Can there be execution level conflicts? Like execution flow could be taken, but execution resources constraining (stalling) it somehow? I'm only talking about "per clock" view, not about hardware threading. Sometimes these terms are mixed in a bit hard to decipher fashion.

mattnewport 7y ago
It's hard to get detailed information on a lot of this as much of it is considered proprietary by NVIDIA. My understanding is that threads are not truly independent as they would be on full CPUs but that the hardware is able to dynamically detect thread divergence (when different lanes / threads of the SIMDish hardware take different branches) and intelligently regroup the threads to minimize divergence. I'm not sure how they then deal with instructions that operate across a warp, it's possible those interfere with the regrouping but they're not commonly used in many typical pixel shader workloads so it may be an overall win. I suspect some of these changes were to make raytracing more efficient (and the Anandtech article suggests as much too). A common problem trying to implement a GPU raytracer on older architectures is performance tanking when rays diverge too much. NVIDIA's Optix did some complicated magic to try and regroup divergent threads but having direct hardware support for it probably makes the raytracing GPU code both simpler and more efficient.

zozbot234 7y ago

The description is unclear, but these look more like hyperthreads/SMT units than true CPU cores. It's talking about "scheduling resources" implemented in hardware, which suggests a SMT model.

jcranmer 7y ago
GPUs are already SMT processors, since that's how they handle main memory latency. Instead, I suspect it's essentially dynamic warp formation to handle cases where there's still enough threads to keep all the lanes busy, but they're spread out over several static 16-thread chunks instead of being right next to each other.
- zozbot234 7y ago
  > GPUs are already SMT processors, since that's how they handle main memory latency. I thought they used a simpler barrel-processor model to handle that. SMT seems a bit more sophisticated.