far cry ps3 and stuff

991060 said:
Humus,wouldn't your technique place more burden on vertex shader and memory bandwidth?

It will place more burden on the vertex shader, but that's usually not a problem. Vertex processing is seldom the bottleneck.
 
_arsil said:
This technique isn't new. See:

PEERCY, M. S., OLANO, M., AIREY, J., AND UNGAR, P. J. 2000.
Interactive multi-pass programmable shading. Proceedings of ACM SIGGRAPH 2000

It is also mentioned in:

Timothy J. Purcell Ian Buck William R. Mark Pat Hanrahan
Ray Tracing on Programmable Graphics Hardware

and dozens other papers...

Well, as I said, it doesn't surprise me. The point is not whether the technique is new or not, but that it's usable with high performance on our hardware such that it's a practical replacement for dynamic branching in many situations.
Regarding the papers you posted, they are primarily not concerned about the performance. They are mainly talking about the "how" part. If the hardware doesn't perform top of the pipe stencil rejection there will be no gain in using this technique from a performance point of view.
My main point is that, in most common situations where you'd normally use ps3.0 dynamic branching to speed things up, you can just as well use this technique and get the same performance increase.

_arsil said:
It isn't also replacement for flow control in pixel shaders. Simulating flow control using some early tests (like stencil or Z-Buffer) requires multi-pass rendering, that means you have to pass all geometry multiple times. If your vertex shaders are complex or you have a lot of geometry it isn't a solution.

Also simulating nested loops, nested ifs and jumps isn't an easy problem and will certainly break your shader into 10 or 15 passes.

The geometry will only be a problem if you have a huge amount of polygons. The vertex shader length matters less, since rendering the ifs typically doesn't require a very complex vertex shader.

Nested ifs can also be handled. It will require at most as many passes as there are paths in the shader. In the real world games you're likely to see any massive amount of if nesting anyway. In 90% of the cases we will be dealing with an if-statement in the top of the shader that culls on some simple criteria.
 
991060 said:
Humus, if possible, I'd like to take a look at your demo's source code, maybe I can convert it to SM3.0, then we can see which method is better. :LOL:

Well, I can make a personal demo of it. I'm interested myself how it will compare.
 
DegustatoR said:
FUDie said:
My point was that you don't have to wait for a patch to access all the features of the engine. NVIDIA cards are running with PS 1.1 in place of many (all?) PS 2.0 effects.
All? :D Stop that, it's not even funny anymore. Everybody in the world knows how you love ATI by now...
Do you deny that Far Cry doesn't use as many PS 2.0 effects on NVIDIA cards than ATI cards? If so, then it's clear you are blind.

-FUDie
 
FUDie said:
DegustatoR said:
FUDie said:
My point was that you don't have to wait for a patch to access all the features of the engine. NVIDIA cards are running with PS 1.1 in place of many (all?) PS 2.0 effects.
All? :D Stop that, it's not even funny anymore. Everybody in the world knows how you love ATI by now...
Do you deny that Far Cry doesn't use as many PS 2.0 effects on NVIDIA cards than ATI cards? If so, then it's clear you are blind.

-FUDie

Um, it uses an nvidia path, which of course doesn't use ps 2.0 as often as their last hardware was bad at it. what's so amazing about that? and I can vouch on the other hand that even the 9500 pro runs far cry nicely. nvidia's last batch of hardware just wasn't ideal for that particular game. the shader 3.0 stuff should be nice though.
 
So I'm putting off playing Far Cry for nothing :oops:

I find that 1024x768 looks like a horse's ass on my monitor and I didnt think that my oc'ed 9800pro could handle far cry at a higher resolution and max detail. Guess I should give it a whirl :D
 
trinibwoy said:
So I'm putting off playing Far Cry for nothing :oops:

I find that 1024x768 looks like a horse's ass on my monitor and I didnt think that my oc'ed 9800pro could handle far cry at a higher resolution and max detail. Guess I should give it a whirl :D
i play 1024x768 with 2x fsaa and high aniso and i get a stead 30-60fps on my 9700pro
 
Jack_Tripper said:
http://www.rage3d.com/board/showthread.php?t=33767223

FUD or not teh FUD???

That is the question.

:D

Jack

From my understanding of things, It's true, But I intend to try and find out for certain. For now I am not certain

Chris
 
Jack_Tripper said:
http://www.rage3d.com/board/showthread.php?t=33767223

FUD or not teh FUD???

That is the question.

:D

Jack

well all know its possible with sm 2.0 . So what does it mean ? Nvidia is using twimtp to get features put in for only its game . That is sad that nvidia feels the need to do this .

Oh well. It just paves the way for ati doing it . which means we are all soon going to have to buy two video cards to play games
 
jvd said:
i play 1024x768 with 2x fsaa and high aniso and i get a stead 30-60fps on my 9700pro

what size monitor do you have? I've had a 17" for 3 years and 1024x768 was fine but I just got a 19" and now that res looks blocky as hell regardless of AA setting.

do you also play with max in game IQ settings?
 
Humus said:
pat777 said:
Can you show me how this drop in works?

Sure. For the case of "early-out" with lighting:

1) Render depth-only pass, include ambient in this pass if you want it. You'll probably want a depth-only pass anyway, so this is for free.

For each light {
2) Draw "tagging" pass that tags pixels that needs to be lit by this light. The shader outputs an alpha > 0 if the pixel is supposed to be lit. Alpha test kills fragments that are unlit. The surviving fragment sets stencil to 1. No depth or color writes are needed, so this pass is very cheap.

3) Draw your lighting as usual. Stencil test kills all unlit fragments early, saving an assload of shading power. For all surviving fragments, set stencil back to zero.
}

This sounds like a neat idea in general, although I think I'm right in saying that alpha test will disable early-z rejection for the tagging pass, which is a bit of a bummer.

For the lights case I reckon a better approach is to render the light extent as (coarse) geometry to set up the stencil -- see Shawn Hargreave's GDC talk (*). This is very cheap transform and fragment-wise.

(*) "Deferred Shading", but the optimisation still applies.
 
Jack_Tripper said:
http://www.rage3d.com/board/showthread.php?t=33767223

FUD or not teh FUD???

That is the question.

:D

Jack

umm... the offset 2.0 shader is already present and I enabled it in small level you can download on the web... offset test map... they obviously can't remove a shader that's already in the game, so offset at the very least is in far cry... the other shaders it's up to them, but there should be a couple I would imagine that have 2.0 fallbacks, and probably a couple 3.0 only things...
 
Mr. Travis said:
umm... the offset 2.0 shader is already present and I enabled it in small level you can download on the web... offset test map... they obviously can't remove a shader that's already in the game, so offset at the very least is in far cry... the other shaders it's up to them, but there should be a couple I would imagine that have 2.0 fallbacks, and probably a couple 3.0 only things...

Yep...it looks great and runs at about 100fps on my X800XT too :D That's why I'm curious as to if I'll be able to get PS2.0 fallbacks for these "3.0 only" features, I'm wonder how long it'll take for someone to "fix" it for us Ati folks.

:p
 
in answer to a previous comment.

HL2 does use HDR, in fact that was one of the big negative things with the Nv3x line. they could not run any of the HDR effects that ATi was.

I am honestly a little Confused that I seem to be the only one remembering this. There were discussions all over the place about it.

ATi was doing HDR in demos, and Valve talked about it on more than one occasion. I am still confused How this HDR is different from the HDR that ATi has been doing for over a year. Specific shaders are being done with High Dynaic Range color. Not the entire game. How is this any different than previous HDR demos, or even the HDR shaders in HL2?
 
Hellbinder said:
HL2 does use HDR, in fact that was one of the big negative things with the Nv3x line. they could not run any of the HDR effects that ATi was.
i heard that hl2 will not use hdr. but the source engine WILL have HDR capibilities for sure. that dx9 demo from last year (the rooftop one) had HDR but those features probally wont be in the game at release, maybe a patch via steam tho.

this is what most of everybody is saying over at Halflife2.net , one of the biggest hl2 community sites out.
 
Humus said:
The geometry will only be a problem if you have a huge amount of polygons. The vertex shader length matters less, since rendering the ifs typically doesn't require a very complex vertex shader.

There is a problem with number of DIP calls. Current generation of graphics cards/OS driver models/ doesn't like more than several hundreds DIP calls per frame. If you have 250k polys and 450 DIP calls per frame you don't want to pass all this thing multiple times through vertex pipeline.

Humus said:
Nested ifs can also be handled. It will require at most as many passes as there are paths in the shader. In the real world games you're likely to see any massive amount of if nesting anyway. In 90% of the cases we will be dealing with an if-statement in the top of the shader that culls on some simple criteria.

It will require at most as many passes as there are paths in the shader. That's true. But that means, that for 3 ifs you have 8 passes. It will hurt...

In many cases you will have to compute some data multiple times. E.g:

Code:
float c;
float a = SomeComplexFunction();
float b = SomeOtherHugeFunction();

if (a > b && b > 0)
   c = a / b;
else
   c = (a – b) * b;
You have to compute a and b in each pass. Of course you could precompute these values earlier and store them in a texture, but it isn't always possible.

There is also one more exception in this technique. It doesn't work at all with transparent surfaces. You have to switch shaders for every transparent triangle which is a kill for a performance.
 
Back
Top