[991060]

It's weird, my customer test shows that NV40 does have early stencil rejection, even if alpha test is enabled.

[Xmas]

Originally Posted by 991060

It's weird, my customer test shows that NV40 does have early stencil rejection, even if alpha test is enabled.

What is weird about that? Stencil test and alpha test can only kill pixels, and both happen before anything is written to memory, so the order of those tests is irrelevant (but they affect operation of hierZ). Now, if you were talking about stencil operation...

[digitalwanderer]

Originally Posted by 991060

It's weird, my customer test shows that NV40 does have early stencil rejection, even if alpha test is enabled.

How are you testing for it?

[Evildeus]

Well, i think that what he meant is: It's weird because the Nv40 does have early stencil rejection as R420, but in humus demo the R420 does take advantage of that whereas the NV40 sees its performance decrease.

[Dave Baumann]

Originally Posted by Evildeus

It's weird because the Nv40 does have early stencil rejection as R420

They may both have early z rejection, but the question is where in the pipeline they are both rejecting.

[Evildeus]

Originally Posted by DaveBaumann

They may both have early z rejection, but the question is where in the pipeline they are both rejecting.

Well, maybe. So it's not even interesting to compare both, now that we seem to know that Nv and Ati are not using the same way as the benchs tend to show.

Now i'm still interesting to see the PS3.0 doing the same thing, and the answers to the drawbacks pointed out over here.

[991060]

Originally Posted by DaveBaumann

They may both have early z rejection, but the question is where in the pipeline they are both rejecting.

This is how I tested:
First disable stencil then run the fillrate tester using 2 instructions, the result was just as expected, about 3200MP/s.
Then set render state so that all pixels were rejected, the result was much higher, around 22000MP/s.(Z writing was disabled, and there's no color output because of the rejection)
Then I enabled alpha test, the result was about the same as the 2nd situation.

The above data clearly showed stencil rejection happens before the pixel shading unit, otherwise I wouldn't get that high fillrate.

edit: spelling.

[digitalwanderer]

Thanks 991060.

[reever]

And when developers talked about the befits of SM3.0 they always mentioned branching and it's main purpose, which always seemed to be helping this problem with per-pixel lights, and now it's possible without SM3.0 albeit using a trick, where is the problem?

[AlStrong]

Originally Posted by Evildeus

You may be right, but it seems to me that the reason of the is to try to demonstre the non-advantage of PS_3.0 branching (and hence Nv40) and it seems that many people (and even new ones) are displeased with this way and even more disagree with the advantages of this particular technic.

Unfortunately the discussion over this technic is a bit difficult as the times of posting are quite incompatible.

Fair enough

[Graphics_Krazy]

Well done Humus.

For those poo-pooing on his parade, he has simply shown that you can take an effect and SPEED it up on a large install base of Hardware. One would think that developers want their cool effects to run on all cards with maximum performance on ALL cards. It shows how well the engine is built, which as someone mention, is what Crytek is selling as well.

IMHO, the greatest rewards in programming is figuring out something others never thought possible. Humus has taken what appeared to be a SM2.0 limitation, and solved it.

Congrats

[991060]

looks like the current HLSL compiler doesn't favor dynamic branching, it just generated SM2.0 style code even if I was using ps_3_0 profile.

[london-boy]

Shame he's advertising it in such a way that can be considered not-so-objective. Look at the results it created on these boards. A tiny little bit more professionalism on his part could do wonders to calm down teh fanbois one here, both Ati's and NVidia's. And let's not forget about the good old PVR fanbois.

[Chalnoth]

It's not really solved except in one specific case, though. A PS3 version of the same rendering algorithm would be able to do all the lighting application in one pass, while still not doing the lighting calculations that don't need to be done. With Humus' algorithm you'll be sending geometry data to the video card many more times than you would with PS3, which may become the limiting factor in some situations.

[digitalwanderer]

Originally Posted by london-boy

Shame he's advertising it in such a way that can be considered not-so-objective. Look at the results it created on these boards. A tiny little bit more professionalism on his part could do wonders to calm down teh fanbois one here, both Ati's and NVidia's. And let's not forget about the good old PVR fanbois.

Yeah, so?

"We're putting out fires with gasoline,
putting out fires with gasoline!"

[london-boy]

Originally Posted by digitalwanderer

"We're putting out fires with gasoline,
putting out fires with gasoline!"

Hey, i'm just saying...

[HAL-10K]

Originally Posted by reever

And when developers talked about the befits of SM3.0 they always mentioned branching and it's main purpose, which always seemed to be helping this problem with per-pixel lights, and now it's possible without SM3.0 albeit using a trick, where is the problem?

This "trick" is just something that has a similar result like dynamic branching. But it does only work with this shader.

So I don't understand why so many guys think that this shows anything important.

It's a tiny optimization for a specific task - nothing compareable with dynamic branching!

[Ragemare]

Personally I don't care what it does I just like all the pretty lights.

[reever]

But it does only work with this shader.

And? Here's a quote from crytek themselves

Q: 7) What aspects of the screenshots seen at the launch event are specific examples of the flexibility and power of Shader 3.0?

A: In current engine there are no visible difference between PS2.0 and PS3.0. PS3.0 is used automatically for per-pixel lighting depending on some conditions to improve speed of rendering.

Now doesn't this trick do what they want to do? Certainly if they needed branching for more they wouldn't have mentioned one thing

[Richard]

Originally Posted by trinibwoy

I'm not really trying to justify anything. And your analogy is poor at best Far Cry does support the highest shader model available on ATI cards - 2.0. Running a 2.0 card at 1.1 is in no way analogous to this situation.

I'm not talking about dynamic branching, geometry instancing, or whatever feature card Y doesn't support. I'm talking generally about what CryTek might NOT let some consumers enjoy, like offset mapping. We know nVidia tried to pass those pictures as SM 3.0 when even a nVidia engineer in an interview conceeded those effects were possible in 2.0. And if it's a matter of instruction count there's always 2.0a and 2.0b.

Similar situation, wrong application. I don't think you can equate a benchmark to these extra Far Cry features. Please realize that these features are in a patch and are not what you 'paid for' so to speak. If you though Far Cry was awesome before and willing to buy it, why would you change your mind now? The game hasn't.

When I buy a game I expect it to either be bug-free (ah! Now there's a thought!) or download patches. This isn't a separate feature. It's part of a patch thus it ends up being part of the "package" you buy. As such, when the patch offers feature A for card Z and leaves out card Y when it's perfectly capable of using it (or with a small amount of work) that's when I know the developers want to earn their living not by making the games the consumers want but by producing tech demos for whichever IHV pays the most. That's perfectly fine, but I prefer to spend my money on a developer that cares for consumers (all of them).

Another example, when Gabe said nVidia cards wouldn't have AA (and then HDR) there was an outcry from the nvidia fans (and rightfully so). Eventually these seemingly "difficult" obstacles were overcome. Another example, Neverwinter Nights. Shiny water should have been available under ATi cards, but because bioware apparently only likes their consumers with nVidia cards they lost my $50 (btw, as context I never owned an ATi card and my last two and current one are nVidia cards).

What I'm trying to show is that all situations are different but all come down to this: when a developer can provide the same (or very similar) experience to all consumers he should do so and everyone should encourage this behaviour because today is the brand of cards you hate but tomorrow it's you who's left in the rain.

[Drak]

Originally Posted by Humus

This technique can replace most common dynamic code paths, or at least those that we will see in the near future. It won't do while-statement in the general case. But it will do any kind of if-statement, including nesting, and only run the correct path. For performance optimization, this is the most common use of dynamic branching. So a technique that can replace that is IMHO significant.

Humus, correct me if I'm wrong, but your technique can only emulate an "if-then-else" statement when the output colour is set either in the "then" or "else" block or any nesting thereof. These are the renderstates that Zeno was alluding to. However, it cannot handle computing intermediate variables (not unless you use a very nasty hack of MRTs AFAICS) which is what dynamic branching is really about.

edit: typo

[trinibwoy]

Originally Posted by Mordenkainen

When I buy a game I expect it to either be bug-free (ah! Now there's a thought!) or download patches. This isn't a separate feature. It's part of a patch thus it ends up being part of the "package" you buy.

Yes but most patches are to resolve issues with the game as shipped. I don't think the SM3.0 patch qualifies as such. Did you purchase the game expecting them to add displacement mapping in a future patch? You must have pretty high expectations for your games

Another example, when Gabe said nVidia cards wouldn't have AA (and then HDR) there was an outcry from the nvidia fans (and rightfully so). Eventually these seemingly "difficult" obstacles were overcome.

Yes, this is an analagous situation and hopefully ATI card owners will get the opportunity to take advantage of the new features.

Another example, Neverwinter Nights. Shiny water should have been available under ATi cards, but because bioware apparently only likes their consumers with nVidia cards they lost my $50 (btw, as context I never owned an ATi card and my last two and current one are nVidia cards).

You expect us to believe that you own an Nvidia card but you didn't purchase a game because it didn't have 'shiny water' on ATI cards? Yeah right.

What I'm trying to show is that all situations are different but all come down to this: when a developer can provide the same (or very similar) experience to all consumers he should do so and everyone should encourage this behaviour because today is the brand of cards you hate but tomorrow it's you who's left in the rain.

Well for one, anybody who 'hates' a video card brand is a retard. And secondly, you are right, the developers should provide the same experience during game development. There are some that will disagree but I don't exactly see that stance extending to add-on features. Would Crytek have even given us those features if it wasn't for Nvidia? Shouldn't Nvidia benefit by their active involvement in getting them out there. If Crytek wanted displacement mapping in Far Cry at the outset wouldn't it be included in the shipping version in PS2.0 guise?

[pat777]

Another example, when Gabe said nVidia cards wouldn't have AA (and then HDR) there was an outcry from the nvidia fans (and rightfully so). Eventually these seemingly "difficult" obstacles were overcome.

I think that's because R3xx had part of SM 3.0 called centroid sampling. AA didn't work on NV3x because HL2 uses lightmaps(a lot of them).

[FUDie]

Originally Posted by pat777

I think that's because R3xx had part of SM 3.0 called centroid sampling. AA didn't work on NV3x because HL2 uses lightmaps(a lot of them).

Lightmaps weren't the issue, it was texture packing that was the issue.

-FUDie

[rwolf]

I am still waiting for Humusmark2004.