What's the use of a pixelshader 3.0 Chip today?
March 31, 2004 / by Demirug / Page 2 of 2 / translated by 3DCenter Translation Team
• 0 * X = 0
This simple mathematical regularity can be used by pixelshader 3.0 hardware to take advantage of performance. Everytime there is a certain probability, that one of the two multiplicators could have the value 0, a further optimization can be applied. Before the calculation of the second factor and the actual multiplication, the first factor could be verified. Is it 0, you can skip the calculation, which is not changing a thing of the final result. Naturally this promises good achievements always when the spared calculation is very complex.
Unreal Tournament 2004 for example, uses the following pixelshader for the pixelcolor calculation of the terrain:
| ps.1.4 texld r0 , t0 texld r1 , t1 texld r2 , t2 texld r3 , t3 mul r1 , r1 , r0.xxxx mad r1 , r2 , r0.yyyy , r1 mad r1 , r3 , r0.zzzz , r1 mul_x2 r0 , r1 , v0 |
The mathematical formula of this shader reads as follows:
colour = 2*(vertexcolor * texture1*texture0.X+texture2*texture0.Y+texture3*texture0.Z))
Due to the many used texturevalues, this shader is of course hopelessly limited through the fillrate. The use of high-class texture filter even deteriorates this situation. If the shader is altered in that way, that this uses pixelshader 3.0 advantages, you can absolutely save fillrate.
| pixelcolor = black IF texture0.X UNEQUAL 0 THEN pixelcolor = pixelcolor + texture0.X * texture1 IF texture0.Y UNEQUAL 0 THEN pixelcolor = pixelcolor + texture0.Y * texture2 IF texture0.Z UNEQUAL 0 THEN pixelcolor = pixelcolor + texture0.Z * texture3 pixelcolour = 2*(pixelcolor * vertexcolor) |
So if it's determined that the texture does not contribute to the pixelcolor before the read in, the read out is spared right away. In case that for every pixel are needed only respectively two of the three textures, the outcome of this is a saving of about 33 percent of fillrate.
• Shadow mapping
With this shadow technique it is ascertained if a pixel's completely in the shade, with the help of a texture containing driver informations. Previous graphic chips had to calculate the color of the pixel in any case, even it has been in the shade.
A graphic chip with pixelshader 3.0 functionality could now, after having checked, if this pixel is completely in the shade, cancel the further calculation of the pixel color immediately. The result here would also be a saving of fillrate and computing power, that is growing with every pixel being in the shade.
• Multiplex
With the pixelshader of DirextX8, so called multiplex-operations were introduced. With these dependant of a value between two others is chosen:
IF a BIGGER 0,5 THEN r = b ELSE r = c
Previos hardware always demanded, that the value for b as for c being already completely calculated, before the multiplex-operation. A pixelshader 3.0 hardware could reshuffle the code in that way, that the testing of a being executed first and then calculating b or c. Such an reshuffle spares the chip to calculate the unneeded part. That means that no matter which of the two values is needed, theres always something spared by comparsion to the original shader.
These were some examples, the driver developers will surely find the one or another possibility. To emphasize once more, would be the fact, that the prefixed possibilities are consistent optimizations, whose can be realised without any changes with the existing games alone by a graphic chip driver. Of course, game developers have far more possibilities. As these are not at hand for the gamer with the availability of a pixelshader 3.0 graphic chip, these optimizations shouldn't be considered here.
Concluding to that, it es assertively pointed out, that all addressed optimizations are of theoretical nature. As for which of them will be realised by a pixelshader 3.0 graphic chip and the appendant drivers with a measureable success, well, we'll just have to wait and see.
|
|
