Intresting...
- Thread starter alexsok
- Start date
Ack! No flow control in the pixel shader pipeline?!?!?
Bad ATI!
That is a major flaw (the first I've seen).
Of course, this flaw will not affect games today, and probably not for the next two years, but is a limitation to the advancement of 3D technology.
I'm almost 100% certain that the NV30 will have full flow control in both its PS and VS portions (simply based on Cg...which has support for flow control in both components).
I'd really like to see some corroborating evidence, however, that there is indeed no flow control in the PS portion.
Update:
One other thing...I'm really, really, really hoping that that comment "NVIDIA's upcoming 'NV30' will go several steps further than that" means that nVidia is going for no size limits on the programs...that's what these PS/VS really need...
Bad ATI!
That is a major flaw (the first I've seen).
Of course, this flaw will not affect games today, and probably not for the next two years, but is a limitation to the advancement of 3D technology.
I'm almost 100% certain that the NV30 will have full flow control in both its PS and VS portions (simply based on Cg...which has support for flow control in both components).
I'd really like to see some corroborating evidence, however, that there is indeed no flow control in the PS portion.
Update:
One other thing...I'm really, really, really hoping that that comment "NVIDIA's upcoming 'NV30' will go several steps further than that" means that nVidia is going for no size limits on the programs...that's what these PS/VS really need...
Not that happy...this lack of flow control will certainly slow down the advancement of 3D technology, and nVidia will certainly have it in their PS.
In the short term, this means that nVidia can quite possibly market their hardware for truly high-end rendering (Well, they may also need unlimited VS/PS sizes...but that's not absolutely necessary). That is, it's not altogether unlikely for nVidia to sell variants of the NV30 in massive multi-chip arrays for movie rendering (Disclaimer: there may be some things I'm not aware of that would prevent nVidia from selling an NV30 variant in the very high-end...).
Without flow control, the R300 simply cannot do truly high-end rendering.
Conclusion: NV30 shows more promise for long-term profitability.
The second thing is that it will reduce the technology of games that base the R300 as their min spec. Granted, by that time I'll almost certainly have a much more advanced video card, and those games probably won't be out for another 2-3 years, but I was hoping that after this next generation of games, all programmers could write their code in HLSL's and all but forget about the capabilities of the underlying hardware. This is certainly not possible to do with the R300.
The big question: will it be possible with the NV30? I'm still hopeful, but I'm losing my faith that the NV30 will have unlimited-size PS/VS programs. We'll see...
In the short term, this means that nVidia can quite possibly market their hardware for truly high-end rendering (Well, they may also need unlimited VS/PS sizes...but that's not absolutely necessary). That is, it's not altogether unlikely for nVidia to sell variants of the NV30 in massive multi-chip arrays for movie rendering (Disclaimer: there may be some things I'm not aware of that would prevent nVidia from selling an NV30 variant in the very high-end...).
Without flow control, the R300 simply cannot do truly high-end rendering.
Conclusion: NV30 shows more promise for long-term profitability.
The second thing is that it will reduce the technology of games that base the R300 as their min spec. Granted, by that time I'll almost certainly have a much more advanced video card, and those games probably won't be out for another 2-3 years, but I was hoping that after this next generation of games, all programmers could write their code in HLSL's and all but forget about the capabilities of the underlying hardware. This is certainly not possible to do with the R300.
The big question: will it be possible with the NV30? I'm still hopeful, but I'm losing my faith that the NV30 will have unlimited-size PS/VS programs. We'll see...
OpenGL guy
Veteran
That's a pretty amusing comment. What did you say about the GeForce 4 pixel shaders being inferior to the Radeon 8500's? Where they a "limitation to the advancement of 3D technology", too?Chalnoth said:
ATI has shown some amazing technology with the R300, and the lack of a feature that, by your own words, won't have an impact for the next two years is a "major flaw"... What sort of logic is that?
OpenGL guy said:That's a pretty amusing comment. What did you say about the GeForce 4 pixel shaders being inferior to the Radeon 8500's? Where they a "limitation to the advancement of 3D technology", too?
Yes, they are a limitation to the advancement of 3D technology. Perhaps I had just too high of hopes for the R300's programmability.
Anyway, if you remember my arguments, I stated that the Radeon 8500's PS 1.4 wasn't really much of an advantage for consumers because it wasn't going to be used much, and when it was used, it would almost invariably be for a performance increase (and a performance increase that wouldn't bring it past the GeForce4....). If you turn my words around, you'll see that I was stating pretty clearly that the GeForce3's programmability was limiting the advancement of pixel shaders. I also still have a hard time seriously faulting nVidia for their decisions, as I have yet to see an effect done on a Radeon 8500 that cannot be done on a GeForce3 (granted, the Radeon 8500 can have higher-precision color in some situations...).
Good logic! (j/k)
In all seriousness, I like to think of new hardware in two terms: how each piece will affect the advancement of technology, and how each piece is for the consumer to purchase.
The R300 seems to be a great buy for anybody looking for a very high-end video card in the next two months (or perhaps later, depending on when the NV30 makes it out). I have yet to see anything that would cast a shadow on the viability of the R300 as a good purchase, except the possibility of very high heat dissipation for a video card (but that's just a possibility right now...not a certainty). I'm sure most people will be more than willing to deal with some inevitable driver quirks (not just because it's ATI, but because it's new hardware....though it will be interesting to see how many there are, and comapre them to the NV30 launch...maybe I'll try to keep tabs...) in order to have the very superior performance that the R300 offers.
But, the R300 is not as good for the advancement of 3D technology as I would have liked. Maybe my hopes were too high, but the lack of flow control in the pixel pipeline is a serious strike against it here.
OpenGL guy
Veteran
Says you.Chalnoth said:
Says you.
Says you.
Amazing how you state your opinion as fact.
You haven't even seen the real capabilities of the chip, but you are already branding it a failure. I guess the fact that it has floating-point pixel pipelines, PS 2.0, excellent AA, etc. are all irrelevant to the chip's chance of success? Whatever.OpenGL guy said:Amazing how you state your opinion as fact.
Try this.
Do you believe that the R300 is capable of executing every Renderman shader ever used in a movie?
If not, the R300 cannot be used for truly high-end rendering.
Granted, I will be disappointed again if the NV30 fails to have unlimited-size PS/VS programs, as that would likely make it unqualified for the same things.
There is no flow control, but there is conditional assignment with CND and CMP. This can be used together with loop unrolling to achieve most of what is done in renderman shaders.
Most loops have a constant iteration factor, which will be unrolled. And most of the uses of IF I have seen deal with conditional assignment.
e.g.
for(int i=0; i<#loops; i++)
{
if(X dot Y < C)
Z = Z + D
else
Z = Z + R
}
will be unrolled to
Z = X dot Y < C ? Z + D : Z + R
Z = X dot Y < C ? Z + D : Z + R
Z = X dot Y < C ? Z + D : Z + R
... (#loops)
Z = X dot Y < C ? Z + D : Z + R
each Z = X dot Y < C ? Z + D : Z + R
will be unrolled to
(computed once)
R0 = X dot Y
R1 = R0 - C
R2 = (R1 < 0), R2+R3, R2+R4 (repeated #loop times)
It is not as bad as it sounds and could easily fit most loops into the 96 or 160 instruction limit. The whole OpenGL pixel pipeline shader in 3DLab's paper example can be done via this unrolling.
The only thing they are missing is conditional branching of the program counter. That's not neccessarily a bad thing as far as performance is concerned. Conditional branching causes all sorts of troubles. For example, different pixels will execute in a different number of clocks and scheduling a 4 or 8 pipeline card to deal with this is non-trivial.
Ensuring that each pixel runs in the same number of clocks makes things alot easier.
Most loops have a constant iteration factor, which will be unrolled. And most of the uses of IF I have seen deal with conditional assignment.
e.g.
for(int i=0; i<#loops; i++)
{
if(X dot Y < C)
Z = Z + D
else
Z = Z + R
}
will be unrolled to
Z = X dot Y < C ? Z + D : Z + R
Z = X dot Y < C ? Z + D : Z + R
Z = X dot Y < C ? Z + D : Z + R
... (#loops)
Z = X dot Y < C ? Z + D : Z + R
each Z = X dot Y < C ? Z + D : Z + R
will be unrolled to
(computed once)
R0 = X dot Y
R1 = R0 - C
R2 = (R1 < 0), R2+R3, R2+R4 (repeated #loop times)
It is not as bad as it sounds and could easily fit most loops into the 96 or 160 instruction limit. The whole OpenGL pixel pipeline shader in 3DLab's paper example can be done via this unrolling.
The only thing they are missing is conditional branching of the program counter. That's not neccessarily a bad thing as far as performance is concerned. Conditional branching causes all sorts of troubles. For example, different pixels will execute in a different number of clocks and scheduling a 4 or 8 pipeline card to deal with this is non-trivial.
Ensuring that each pixel runs in the same number of clocks makes things alot easier.
Argh...I think I might have been mistaken about the NV30
Darn
Looking through the Cg manual again, there is no mention of the use of flow control in the pixel shader, so I am actually not sure if the NV30 will or not be able to perform flow control in the pixel shader.
Oh, and unrolling isn't all that useful. I'm not thinking about using flow control to just make programming easier (which is what unrolling is good for...using HLSL's with loops that compile to many lines of code later), but to allow decisions to be made in hardware.
Yes, I am very aware that it is impossible to have flow control and excellent performance at the same time. I really never expected this first generation of hardware to be able to use very much flow control at all (only on rather simple shaders in few situations...one example might be the water surface as seen from underwater...at certain angles, the water is 100% reflective...at others, you can see some of what is above the surface of the water...flow control within the pixel shader would be optimal for this situation).
Darn
Looking through the Cg manual again, there is no mention of the use of flow control in the pixel shader, so I am actually not sure if the NV30 will or not be able to perform flow control in the pixel shader.
Oh, and unrolling isn't all that useful. I'm not thinking about using flow control to just make programming easier (which is what unrolling is good for...using HLSL's with loops that compile to many lines of code later), but to allow decisions to be made in hardware.
Yes, I am very aware that it is impossible to have flow control and excellent performance at the same time. I really never expected this first generation of hardware to be able to use very much flow control at all (only on rather simple shaders in few situations...one example might be the water surface as seen from underwater...at certain angles, the water is 100% reflective...at others, you can see some of what is above the surface of the water...flow control within the pixel shader would be optimal for this situation).
BTW, I would not view putting conditional branches in the shaders as a huge advancement to the state of the art. It is a nice evolutionary advancement.
Huge advancements for me would be stuff like
1) geometry compression (beyond the indexed methods). See Java3D or wavelet methods for example
2) ability to handle geometry amplification issues on the chip, making TruForm(n-patch), HOS, displacement mapping, etc more useful. Most new games are going to want to do shadow volumes, and all current geometry amplificiation schemes hurt collision detection and shadow generation. This "per primitive processor" on the NV30 sounds like it could do the trick by enabling you to create and destroy vertices and send them to the vertex shader. Being able to query about collisions would be good too.
3) very high levels of AA, 16X and beyond. Traditional software renderers use between 16 and 64 samples, adaptive and stochastic. Also, ability to handle temporal multisampling to high degrees (16-64X) Throw in soft shadows while you're at it.
Huge advancements for me would be stuff like
1) geometry compression (beyond the indexed methods). See Java3D or wavelet methods for example
2) ability to handle geometry amplification issues on the chip, making TruForm(n-patch), HOS, displacement mapping, etc more useful. Most new games are going to want to do shadow volumes, and all current geometry amplificiation schemes hurt collision detection and shadow generation. This "per primitive processor" on the NV30 sounds like it could do the trick by enabling you to create and destroy vertices and send them to the vertex shader. Being able to query about collisions would be good too.
3) very high levels of AA, 16X and beyond. Traditional software renderers use between 16 and 64 samples, adaptive and stochastic. Also, ability to handle temporal multisampling to high degrees (16-64X) Throw in soft shadows while you're at it.
Chalnoth said:
You don't need flow control to do this. This is bog standard fresnel reflection and is already implemented and shipping in many games that have water. See Splashdown and Waverace.
Most RenderMan shaders I have seen, which do stuff significantly more complicated than the water example, use conditional assignments, but very few actually require boolean loop conditions.
Yes, they are nice, but they are only needed for a small subset of shaders. Lots and lots of magic can be done via expressions and conditions. Remember, most 3D algorithms are stated as mathematical equations first in papers, usually using the Sigma sum operator, and usually, the upper bound is known.
Unbounded or non-deterministic loops are hard to analyze in computer science, and we tend to shy away from them.
Chalnoth said:OpenGL guy said:Amazing how you state your opinion as fact.
Try this.
Do you believe that the R300 is capable of executing every Renderman shader ever used in a movie?
If not, the R300 cannot be used for truly high-end rendering.
Granted, I will be disappointed again if the NV30 fails to have unlimited-size PS/VS programs, as that would likely make it unqualified for the same things.
My understanding was that research at Stanford had shown that _any_ Renderman shader could be correctly expressed as a multi-pass implementation on pixel shading hardware, with the provision that there had to be a floating-point intermediate color representation for passing information between the passes of the shader. I believe John Carmack mentioned this research in one of his .plan updates a while ago.
So looking at your question here it would appear that, yes, R300 can express any Renderman shader used in any movie...
Maybe it is an advance after all...
- Andy.
Similar threads
