![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
Xenos or X1950/7950x2?
- Thread starter note235
- Start date
Commander Suzdal
2[H]4U
- Joined
- Jul 29, 2004
- Messages
- 2,134
My understanding of unified shaders is that they offer greater flexibility, not inherently greater power. It all depends on how they are used. Although you have the efficiency of not being stuck with too many pixel shaders when you really need more vertex shaders, or whatever combination, there will be overhead involved in managing the assignment of unified shaders to particular tasks, especially if those assignments change on the fly within a given application. Plus, it's a zero-sum game--if you allocate your unified shaders to one area of performance, you don't have them available for another.
Then there's the coding issue. Optimizing your code for a fixed-shader architecture involves known quantities--the hardware can do thus and so, and you learn to use it as effectively as possible for your particular situation. With unified shaders, you are trying to optimize the code to the hardware AND trying to optimize your assignment of the hardware to best fit the code. This could result in a chicken-and-egg feedback loop that would dramatically increase development time.
A more likely scenario in the bottom-line git 'er done real world? A developer decides on a default shader config that they feel offers the best generic performance, then codes their games to that config, just so they can get the game finished in a reasonable time. Thus the supposedly uber-flexible unified shader card gets treated like a fixed-architecture card just so the developer can get some work done.
All that to say, I don't think there's necessarily an inherent performance boost from unified shaders on a per-shader basis. In fact, the overhead of telling the shader what to do, instead of it already "knowing" what it's designed for, may even make them a little slower than dedicated shaders. Any performance gains would come from just being able to put shader power where it's most needed, and if a fixed-architecture card had enough goodies built in, it could probably keep up pretty well. Brute force methods can win out over efficient/elegant methods pretty often in the digital world.
Then there's the coding issue. Optimizing your code for a fixed-shader architecture involves known quantities--the hardware can do thus and so, and you learn to use it as effectively as possible for your particular situation. With unified shaders, you are trying to optimize the code to the hardware AND trying to optimize your assignment of the hardware to best fit the code. This could result in a chicken-and-egg feedback loop that would dramatically increase development time.
A more likely scenario in the bottom-line git 'er done real world? A developer decides on a default shader config that they feel offers the best generic performance, then codes their games to that config, just so they can get the game finished in a reasonable time. Thus the supposedly uber-flexible unified shader card gets treated like a fixed-architecture card just so the developer can get some work done.
All that to say, I don't think there's necessarily an inherent performance boost from unified shaders on a per-shader basis. In fact, the overhead of telling the shader what to do, instead of it already "knowing" what it's designed for, may even make them a little slower than dedicated shaders. Any performance gains would come from just being able to put shader power where it's most needed, and if a fixed-architecture card had enough goodies built in, it could probably keep up pretty well. Brute force methods can win out over efficient/elegant methods pretty often in the digital world.
there would be no point, if you have a unified system along side with a dedicated system, well then you are screwing yourself either way, with the dedicated system you could be adding more TMU's/ALU's/shader's with the unified system, same goes the other way around
so you could either pull a G80, add so many pipelines and hope you don't become limited, or go like the R600 and let the developer decide, but theres no point in combining the two
so you could either pull a G80, add so many pipelines and hope you don't become limited, or go like the R600 and let the developer decide, but theres no point in combining the two