Greg
02-19-05, 10:18 PM
Just a few comments to clarify things Nutty has already mentioned...
A single game frame may contain a few hundred thousand vertices, but a few million pixels may be drawn, with each pixel possibly made up of multiple fragments. So the pixel shader usually does more work than the vertex shader.
Since VS and PS 2.0, the inputs and outputs of both shaders are floating point vectors. The instructions are also very similar. In the past, the vertex shader needed to do more complex operations since it did the transform and lighting calcs. Now, many of those calcs are done per pixel.
PS 1.0 (and possibly up to 1.4) were not implemented in hardware as instructions interpreted and executed by a GPU, they were implemented as a configuration state block, just like the old fixed function. That is why on the XBox it is possible to fill out the configuration block instead of writing a PS program. It also explains the extreme limitations of the PS 1.0 set, such as instruction order, sampling and calculation limits.
Now having said that, you can see that both the VS and PS are becoming more like standard DSP processors, like a SSE unit on a pentium 4 or such, and recently, with branching operations. Unless there is a specific reason (such as asyncronous processing of logical VS and PS operations), there is little reason not to merge the processes into shared units. The actualy hardware implementation is really up to the engineers in terms of cost and real world benefit. You remember from the whole NV30 saga that having fancy hardware doesn't mean you can sell it, if it doesn't run current games real fast (at least compared to your competition).
From a coding point of view, although the VS and PS are still logically separate operations, they belong to the same material, or surface effect. I notice one of the projects at work has almost one pixel shader for every vertex shader, showing that they could almost be stored or at least considered together. There is also now a stronger dependance between VS and PS due to arbitrary data passing between them, rather than fixed sizes and semantics.
A single game frame may contain a few hundred thousand vertices, but a few million pixels may be drawn, with each pixel possibly made up of multiple fragments. So the pixel shader usually does more work than the vertex shader.
Since VS and PS 2.0, the inputs and outputs of both shaders are floating point vectors. The instructions are also very similar. In the past, the vertex shader needed to do more complex operations since it did the transform and lighting calcs. Now, many of those calcs are done per pixel.
PS 1.0 (and possibly up to 1.4) were not implemented in hardware as instructions interpreted and executed by a GPU, they were implemented as a configuration state block, just like the old fixed function. That is why on the XBox it is possible to fill out the configuration block instead of writing a PS program. It also explains the extreme limitations of the PS 1.0 set, such as instruction order, sampling and calculation limits.
Now having said that, you can see that both the VS and PS are becoming more like standard DSP processors, like a SSE unit on a pentium 4 or such, and recently, with branching operations. Unless there is a specific reason (such as asyncronous processing of logical VS and PS operations), there is little reason not to merge the processes into shared units. The actualy hardware implementation is really up to the engineers in terms of cost and real world benefit. You remember from the whole NV30 saga that having fancy hardware doesn't mean you can sell it, if it doesn't run current games real fast (at least compared to your competition).
From a coding point of view, although the VS and PS are still logically separate operations, they belong to the same material, or surface effect. I notice one of the projects at work has almost one pixel shader for every vertex shader, showing that they could almost be stored or at least considered together. There is also now a stronger dependance between VS and PS due to arbitrary data passing between them, rather than fixed sizes and semantics.