Some usual funny nonsense from THG...

But then what's the point of using HLSL if you need to go down into assembly language anyway? Then HLSL becomes nothing but a prototype tool.

 

Again, I think that this should be left up to nVidia's driver.

Think about it this way. Valve spent 5x the development time, and then nVidia went and replaced the shaders they painstakingly wrote anyway. They should have just passed the buck to nVidia early-on.

 

This was commented on earlier in the thread by Borsti but I finally found time to reply.

Yes there is something seriously wrong when a 9600 Pro can beat a 5900 Ultra. I agree completely. The question that immediately leaps to mind in my case is what is it? The evidence available to me says the problem lies in the FX5900 Ultra's shader performance.

Every single test and application, synthetic or actual game, I have seen has shown that ATI has MUCH stronger shaders than Nvidia in the current generation. We know that HL2 is a very shader heavy game. The 9600 Pro has four pipes at 400MHz with strong shaders, the 5900 Ultra has four pipes at 450MHz with weak shaders. Given they are running the benches at a fairly low resolution (1024x768) it is likely the game is not bandwidth limited, so the 5900 Ultra's greater memory bandwidth doesn't help. If, as seems likely, it's using single-texturing with shaders then the 5900 Ultra's extra TMU is dropped from the equation. That puts all the work on the shaders. And in a shader-limited situation I would expect ATI's shaders even on the 9600 Pro to be more than enough to make up the 50MHz difference in core speed.

It does sound odd, but if you've been following what's been going on it does make sense. The FX series may be a DX9 part but the performance emphasis in the design was on running DX8 class games quickly rather than DX9 class games.

Those are my two cents on that issue.

 

I do not understand why people use this as a negative point, it is a positive thing, whether your hardware sucks or is awesome helping developers get the most out of it is a good thing and in many ways is the reason that we have directX9 games much sooner than Nv expected.

 

It is sad when these "fluff" sites include the three largest of their kind. Thank goodness for B3D

 

Absolutely!

 

DaveB said

You paint a rather bleak picture, Dave...

 

IF you own an GFFX of any kind, the picture is very bleak......

 

So you mean not do an NV3x path at all? Leave the 5900 U getting < 30fps at 1024x768, with the mainstream cards barely pulling 10fps? And just assume that, if your game is big enough, Nvidia will be replacing all your shaders with completely new ones that drop IQ in unknown ways and may not even be DX9 compatible (if they use FX12, for example)??

At least with an NV3x path, Valve gets to decide (and therefore know) exactly how IQ is being sacrificed in order to get playable framerates. It is their game, after all.

Nor is if feasible in the long term to expect Nvidia's DevRel to be able to rewrite every PS 2.0 shader that will be used in a game, even just the major titles. Nvidia can't be expected to take over for every game developer. It has to be the developer's job to write their own game.

 

Even worse, what about the other 90% of games that don't get the huge press and therefore less attention? In other words, don't count on optimizations for every game you might want.

In addition, when the NV40 (and beyond) ships, do you honestly think NVidia will spend all of this effort on a generation old architecture???

I would hate to be a GFFX owner under those two circumstances. Yeah, 2-3 years life. Not!

This is where ATI is really ahead of the game. Being well suited for the standard DX9 and ARB2 code paths insures a much brighter future. Why can't everyone see this fundamental difference between ATI and Nvidia?

 

The resolution a game runs at makes only a reasonably small difference to the amount of memory bandwidth consumed.

The key question is how much memory is needed per pixel output (that determines the bottleneck). This is reasonably constant for a given scene on a given piece of hardware.

Of course, it can be significant, but it should not be assumed that higher resolutions become more memory bottlenecked (as the higher resolutions also need more pixels). There are competing effects (Z-bandwidth-saving features get more effective; textures spend less time with magnification filtering; refresh consumption might go up, or even down if the refresh rate drops at the higher res; there are others).

 

But isn't 'it just works' better?

 

Chalnoth,

Has it not occured to you that that the NV3X path in Valve might have been written with a lot of input from Nvidia? With a very likely possibility of engineers from Nvidia itself implementing this path?

What's interesting is that the drivers still have to resort to shader replacement...Possibly due to one or more of the following reasons

- It's not possible to express an optimal NV shader through existing DX shader interfaces..For eg:- there is no way to specify FX12 data types through DX9 PS 2.0.

- Driver has to resort to doing some questionable shader shortcuts..Like getting rid of some instructions - because most users wont see a difference in the levels that exist today

- Some legal algorthmic shader optimizations, if implemented in Valve's code may benefit ATI too - So, NV might chose to hide it inside their drivers


Just some theories.

Any ISV would prefer not messing up his code base and the driver doing everything needed for it's hardware. This is the main reason for the acceptance of standardized interfaces through DX

 

http://www.guru3d.com/forum/showthread.php?s=&postid=504742#post504742

My little plug for this site.

 

Ok you did, but clipping planes and screen grab detection is not used by other IHVs Lars...Test after Test shows, from generic DX9 demos, to even Nvidia Demos (dawn runs faster on a wrapper and R3.XX class cards) vs. Nvidia cards.
3Dmark 03 showed the same thing before 'driver optimizations' were given the ok.

Is it this Devs fault too ??

http://www.beyond3d.com/forum/viewtopic.php?t=7543&start=0

How about the endless tests done here on this forum from our more skilled programmers, showing the flaws in the architecure ??

I didn't have much of a issue with the article until I saw the comment VALVE must answer to the public about poor Nvidia performance...and my answer to that is Nvidia needs to fix it's hardware

 

No.

I mean go for the partial preicision data types in the code, but don't bother with any sort of instruction reordering and whatnot. It would be best to try to get the HLSL/Cg shader code as short as possible, but it shouldn't be necessary to have to tweak any further than using specific data types.

In this way, any DX9 card should be able to use the exact same HLSL (or Cg) code.

Dealing with the quirkiness of the NV3x architecture, such as going for minimal register usage, or proper instruction ordering for optimal texture access and FP usage should be the domain of the compiler and/or nVidia's driver.

 

I think the perception that poor GeforceFX performance will fall hard on Valves shoulders is a bit overstated. Sure, there will be some who will call Valve up and blindly rage about slow frame rates. However, there are some rather uncomplicated things that Valve will be able to do to defer accountability for the slow frame rates.

It does seem understandable that they ought to be able to tell their customers that simply Valve worked hard to fix the problems with Nvidias meager performance but there was only so much they could do given Nvidias poor architecture choices WRT the GeforceFX series hardware. This is not rocket science, I don't believe that everyone out there are idiots. Hardware tribulations are par for the course in PC land. People would understand that I believe. In other words, I think it is perfectly acceptable to rest the charge on its source. Further I believe that this is exactly what Valves intent is.

Valve has done the right thing with this discharge of information pertaining to the unfortunate performance of Nvidia hardware with their game, before the launch of their software. There won't be a bunch of enthusiast upset about how poorly their GeforceFX plays HalfLife 2. For the most part I believe many will know that Nvidias hardware is slower well in advance. Getting the info to trickle down so to speak is the slower part. Surely the game will have read me's, etc that will explain the problems with Nvidia hardware.

Nvidia seems to dig them selves a little deeper with every thing they bloody well do lately. The idea that Valve is somehow responsible for the poor performance goes against the fact that Nvidias PS2.0 are slow on just about any PS2.0 test out there compared the Radeon 9500 and up..

 

Exactly, Dio. There's a perception that, "Gee, isn't it swell that nVidia will work with developers to help them optimize their code so that nVidia products will run well with their software!" It's like some people imagine developers falling out of their chairs and rolling on the floor in ecstasy to discover this...

What they aren't thinking about is all of the *added work* the developers have to do which takes time away from what they really want to do--which is work on their game software. This is what the API's are for--to get developers away from having to hand-tune and hand-optimize for differing IHV graphics hardware when doing a game, a process that can be very laborious and still not produce the goods. Look at Valve...doubtless Gabe and the guys went orgasmic at the prospect of "working with nVidia" to create an optimized code path for HL2 for nV3x....Heh... By their account they worked at it 500% longer than they had to work to create the straight DX9 API code path, which they say ran like a top with R3x0 with no optimization required (But unfortunately ran like a dog with nV3x.) And what did they get for all their effort? A faster dog--but definitely not a greyhound. In fact, after the glorious experience, Valve concluded it would have been better served to have just thrown nV3x on the DX8 code path and have done with it. They are still debating on whether to use their optimized path for nV35 or whether to put it on DX8.1 at the moment, but have already decided to put the other nV3x cards on the straight DX8 path by default. If I were Gabe I'd put 'em all on DX8 by default and let the user select for DX9 support in the game if he's just hankering to go even slower...

Not trying to be flippant here, but in many ways these things with nVidia this year have turned back the clock on the progress of 3d. It's not going to stop anything, but it's definitely slowed things up. 3dfx's being tardy in 1999 with a 32-bit product (shipped six months late in 2K) was but a very minor bump in the road compared to this. I'd say that if not for R3x0 we'd be going backwards in a real hurry...What's good for developers is for the IHVs to be in line with the APIs--it's no accident or twist of fate that R3x0 runs the ARB2 path and the DX9 path with little to nothing in the way of optimization--and does both a lot better than nV3x. That's the train nVidia needs to board if it wants to continue the trip, IMO...

 

I agree with WaltC.

Nvidia needs to go back to the drawing board and stop producing cores that will only run well under "Pseudo-Glide" if at all. Maybe Nvidia should move on to PCI based add-in boards like the old Voodoo Graphics and Voodoo 2 so we can use them for games that require "Pseudo-Glide" and use our main cards for everything else.

edit added

Maybe they could call it "Pseudo-Graphics" too. It sounds pretty close to Voodoo.

 

Jesus Christ himself, eh? Man, nVidia is in trouble!