The ATI R600 Rumours & Speculation Centrum

Tm Sweeny says UE3 is fully DX10:
http://www.nvnews.net/vbulletin/showthread.php?t=70056

 

Publishers can name any future game what they want for all I care; just because some games will have additional D3D10 paths (with some rather small performance improvements wherever possible) it's a long shot from there to call ALL of those prior listed games anything BUT D3D9.0.

The very same goes for Crysis; a pure D3D9.0 game with a D3D10 path with some possible performance increases. Can you say Far Cry SM3.0 patch?

 

I`d rather not say that, considering that the "SM3.0" patch actually added some optimizations that should`ve been there since day one. Crytek simply didn`t do a good job at optimizing their SM2.0 path, they could`ve achieved quite a bit more with it in terms of efficiency IMO.I`m hoping this is not the case.

 

the sm2.0 path was optimized very well, other then parallax shader (this was added in with the sm2.0b and sm3.0 patch) everything else went very fast, of course depending on which shaders were selected, some of the normal map shaders (1 in particular, which was used for the characters in Far Cry) was extremely fast. Far Cry was a very CPU intensive game when it came out. It also hit graphics cards hard too, but when the gf 6's and x800's the high end cards started showing CPU bottleneck at mid level settings.

 

The parallax shader that was only enabled on that presumably 64-bit patch, and used at the GF6 launch?Perhaps, but i still think that, for example, they could have collapsed some lighting passes for example even with vanilla SM2.0, instead of touting this as a big addition with the 2.0b and 3.0 pass. That`s IMO and from what I`ve seen.

But back to R600, eh?

 

Could have been the 64 bit patch I'm not sure, I just remember it was available on the 1.2 patch we recieved for HDR. Well in truth, lets see the gf 6's and x800's had 16 pipelines, its possible to to do 16 lights in a single pass, each pipeline doing 1 light, but of course that doesn't leave much else for anything else, also then light shaders have to be written for each individual card depending on the number of pipes.

Anyways yeah a bit off topic lol

 

1 light per pipe? Are you seriously thinking about a modern GPU executing like that, or have you been chugging the eggnog seriously hard today?

 

It looks like.

As we talk about FarCry lights.

The 2.0 shader do one light per pass. The 2.x increases this up to 3 lights and the 3.0 could do 4. The factor that limit the number of lights are the number of floating pointer interpolators.

 

Only when lights are casted in the same area where radi's are overlapped will a problem like the 3 to 4 lights with sm 2.0b or 3.0 will ever occur. Other wise there are no problems at all. But per viewable dynamic lights, the number of a lights that can be rendered it can be done per pipeline basis just as it could have been done with a fixed function pipeline. Its a hack that works very well. But the cost is there will have to be many light dynamic light shaders and just increases the complexity of the engine.

 

Huh?

You can not assign lights to a pipe, lol.

The Pixel Shaders don't even have a notion of lights (besides the default uniforms for them)... but you can pass whatever you want in the light parameters and interpret it however you want in the shaders.

 

Yes I know that, but once you go past the certain number of lights what I noticed when you go past the number of pipelines, using different types of light shaders (I really can't show the psuedo code, since I don't own the rights to it) there is a sudden drop in frame rates well its not really bad but signficant enough. Fixed function pipeline of a gf 3 was capable of doing 4 lights per pass actaully in its t&l engine.

GF3 QA document

It also depends on scene complexity. Its arbitrary I agree, but this can be added into a programable shader unit aswell.

I think I should have added its not something a programmer would designate which pipelines will be drawing which lights, sorry for the confusion.

 

http://www.imgmagazine.com/news/story.php?ArticleID=3283

This is something similiar.

 

All depends on the light calculations, what each shader does (the hardware doesn't know or care if you are calculating lights or not). There is no pipeline limit...

Anyway back to the R600

 

Well I could imagine some minor performance increases through bumpmaps in the D3D10 path, yet nothing spectacular either. In such a case it truly wouldn't be possible in D3D9.0.

Albeit I agree with the above, I avoid mentioning it since you can see the reactions above LOL I don't know where and why each single light needed a whole pass in FC and multiple lights (hell even just 2) weren't packed together, since any SM2.0 GPU would have had a benefit from it, but more than often some things work in mysterious ways.

 

Razor, you can theoretically do a shitload of lights with a single pipeline GPU, and you can collapse lighting passes even if you have less "pipelines" than the number of lights, but perhaps I`m not getting your point and if that is so, sorry. And the fixed number of lights quoted for hardwired T&L is something else, it relates to a hardwired limit of the T&L units based on what the OpenGL spec stated.Again, I reiterate that I may not be getting your point, and I`m misunderstanding your points.

What Demi said is correct, but I think that with optimisation more could have been achieved with vanilla SM2.0, and for that matter, with the other paths too. The thing is that the game was so fast that everybody assumed it was a super good coding effort. OTOH, aside from Carmack and the Epic guys(sorry if I`m missing someone here), none bother milking architectures and writing really tight, optimized code these days, it`s like the common direction is:Shit man, that G80 is helluva fast, let`s do some HLSL shaders and be done with it...aren`t we gonna tinker, see if doing something differently helps?No man, it`s fast, it`s fookin fast, no need for that crap-and even if we`re suboptimal, they`re gonna upgrade, and the reviews sporting QuadCores and SLi systems will run great anyway!

Sure, complexity of software has grown considerably, so I`m not really trying to rip a new one to the devs. What I`m hoping is that Crytek will completely juice the SM3.0 path, and use the advantages that DX10 brings where they`re actually needed and meaningful.

 

Clearly you have no idea what you're talking about, Epic and Id can afford to optimize so far with their budgets but most companies can't. If you want the optimisations to pay off it's going to cost you a lot of time that's mostly better spent at fixing (mostly gameplay related) bugs. A good game is more important than some geniously optimised shaders.

 

Thanks dude, can I take a back-seat now that my ignorance has been exposed?You`re a sweetheart for doing it

 

As an end user I can accept the level of (un) optimization of Far Cry, after all it did run on my 9600SE when it was released. But the performance of games like FEAR XP on my 7800GTX is what makes me want to throw away my PC, I mean WTF how did they have the nerve to release it in such a horrible state?!

 

Pipes and lights are completely unrelated. Don't know what you're thinking here.

It was 8 fixed function lights (since that is the minimum required by OpenGL).

 

Not if you're running at glorious single digit framerates in spots with a lot of lights on a new GPU (back then), where there wouldn't had been a single reason for it running that slow. Good gameplay is most certainly a very important factor, but a slideshow is far from being ideal too. If any ISV then doesn't have the luxury to optimize the shaders accordingly, then there's the way more simple sollution to decrease the amount of lights from the get go, if it's at a given time only possible to do one light per pass.