3 ms·
Yes, you are correct! GPUs are essentially, very many simpler cores on a big die, and the reason it works is that the programing model is inherently parallel.
by quelsolaar 6y ago
Yes, you are correct!
GPUs are essentially, very many simpler cores on a big die, and the reason it works is that the programing model is inherently parallel. (You almost always want to compute many pixels)
GPU "cores" are different because they have graphics specific instructions like texture lookups.
They are also different because you want to run the exact same program on many cores at once. So you have have one instruction decoder/dispatcher that control more then one core. This leads to some weird behavior, like if you have a branch in shader code, all cores may compute both branches, but then each core may mask away the result of what ever branch the specific core shouldn't have taken.
- imtringued 6y agoThat's a really weird explanation of SIMD. There are big fat cores in GPUs but each core can process the same instruction stream 32 or 64 times but with different data. If there is only one core but two branches have to be taken it is obvious that the core has to process one branch after the other. Your "there are cores inside my cores" explanation is what's causing the confusion.
- MaxBarraclough 6y ago> if you have a branch in shader code, all cores may compute both branches As imtringued suggests, that's not quite right. In SIMD terms, all lanes of the core will be 'along for the ride' in case of control-flow diverging. The core must run the instructions for both branches, effectively disabling and re-enabling its various lanes as necessary. When disabled, a lane does no work. What SIMD calls a lane, SIMT calls a work-item or (perhaps more confusingly) a thread. The term 'core' refers to the level at which there is independent control-flow, much like in CPUs. See https://en.wikipedia.org/wiki/Single_instruction,_multiple_threads https://en.wikipedia.org/wiki/Single_instruction,_multiple_t...