[Ateo]

Originally Posted by turtle

UE3 is DX9...as most of those games are designed towards dx9, with support for DX10. I doubt most of them will add anything new, perhaps just a speed increase...besides perhaps CRYSIS and a couple others.

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

Jacob- This isn't really a UT2007 question this is more a UE3 question; Do you guys have any plans to add DX10 features to UE3?

Sweeney- Oh yea absolutely, we will have full support for DX10, we will use their geometry shader stuff to accelerate shadow generation and other techniques in the engine, we will be using virtual texturing. With both UT2K7 and Gears of War we are offering our textures at extremely high resolution like 2000x2000 resolution which is a higher resolution than you can effectively use on a console because of the limited memory, but it is something that certainly will be appropriate for PC's with virtualized texturing in the future, so we will whole-heartedly be supporting DX10. It’s hard to say what the timeframe will be on that because Vista could ship this year, or next year, or whatever. But, we will certainly be supporting it really well when it comes along.

[Ailuros]

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?

[AlexV]

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.

[Razor1]

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.

[AlexV]

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?

[Razor1]

Originally Posted by Morgoth the Dark Enemy

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

[Rys]

Originally Posted by Razor1

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.

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?

[Demirug]

Originally Posted by Rys

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.

[Razor1]

Originally Posted by Rys

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?

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.

[ants]

Originally Posted by Razor1

...
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
...

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.

[Razor1]

Originally Posted by ants

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.

Yes, probably. Note that you don’t have to write multiple vertex shaders. For example, you could write one shader to handle four lights per vertex and zero out the light contribution from unused lights. The instructions for the extra lights are still executed, though they have no effect. Wasting instructions this way can impact performance in geometry-limited situations. To help alleviate this problem, we’ve developed the NVLink tool which will automatically combine any number of vertex shader fragments for you at runtime or as a pre-process. This tool is available on our developer website.

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.

[Razor1]

http://www.imgmagazine.com/news/stor...ArticleID=3283

This is something similiar.

Single Pass, Per-Pixel Rendering of Multiple Light Sources


Some of the most important effects made possible by SMARTSHADER™ technology involves per-pixel lighting from multiple light sources. Making use of all six texture inputs to the pixel shaders, bumpy objects can be made to accurately reflect light from multiple sources in a single rendering pass. Light sources can include environment maps (providing realistic reflections), point lights, spotlights, glowing objects, and more.

[ants]

Originally Posted by Razor1

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.

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

[Ailuros]

Originally Posted by Morgoth the Dark Enemy

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.

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.

[AlexV]

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.

[oeLangOetan]

Originally Posted by Morgoth the Dark Enemy

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.

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.

[AlexV]

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

[Suflex]

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?!

[Xmas]

Originally Posted by Razor1

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.

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

Fixed function pipeline of a gf 3 was capable of doing 4 lights per pass actaully in its t&l engine.

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

[Ailuros]

Originally Posted by oeLangOetan

A good game is more important than some geniously optimised shaders.

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.

[Razor1]

Originally Posted by Xmas

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).

Yeah, sorry for the confusion, I didn't mean that pipelne numbers limited the lights, just that performance hits start to get very noticable once the number of pipelines (well would say vertex shaders) are fully utilized.

Hmm don't remember if 8 was possible on a gf3, but you are correct 8 lights were a requirement ogl.

[Xmas]

Originally Posted by Razor1

Yeah, sorry for the confusion, I didn't mean that pipelne numbers limited the lights, just that performance hits start to get very noticable once the number of pipelines (well would say vertex shaders) are fully utilized.

Of course you only get a performance hit with vertex lighting if the lighting calculations are the bottleneck. The more lights you use the more likely it is a bottleneck. But VS performance is # of vertex pipelines * VS clock * VS efficiency, and whether it limits performance depends on how quick the other parts of the chip are. There is no direct relation along the lines of "if # of lights > # of pipelines then you get a performance hit". And two directional lights are faster than one spot light.

GeForce 6 and X800 don't have 16 vertex pipelines, btw.

[mao5]

Latest news leaked from ATi Partner, R600 now runs at 1GHz core speed and 1GHz ram speed (double G)on a long PCB with air cooling, I don't know what speed of short PCB. Also ATi Partner such as Asus has already received R600 card sample.

[Arty]

Originally Posted by mao5

Latest news leaked from ATi Partner, R600 now runs at 1GHz core speed and 1GHz ram speed (double G)on a long PCB with air cooling, I don't know what speed of short PCB. Also ATi Partner such as Asus has already received R600 card sample.

Well the A12 rev was already hitting 1GHz speeds.

[zgemboandislic]

Originally Posted by serenity

Well the A12 rev was already hitting 1GHz speeds.

We don't know the state of play with the A13 spin but do understand that ATi has got A12 running at a speed of 1GHz.

That's around half the target speed of the production version, which is now set to arrive some time in "early" 2007 and not before Christmas as originally promised. That gives NVIDIA's faster-than-a-ferret-on-pheromones, DirectX 10 GPU - the G80 - a quarter's head-start or more.:

I really don't get it. Does that mean they were aiming for 2Ghz?