PDA

View Full Version : EQ2 Shader 3.0 upgrade


Pages : [1] 2 3

Sgt_Pitt
06-30-09, 08:04 AM
part 1 http://www.youtube.com/watch?v=Qs6o3Q0xPuE
part 2 http://www.youtube.com/watch?v=nLtHk6QJ5p8

|MaguS|
06-30-09, 08:44 AM
Whty does it look like all they did for the most part was enable dynamic shadows?

EciDemon
06-30-09, 10:13 AM
Whty does it look like all they did for the most part was enable dynamic shadows?

Dunno if this is related with the latest Game update. It added the dynamic GPU shadows using sm 3.0

I must say though, looking at the video there, it only looked as they upped the tourch intensity while at the same time enabeling the Gpu shadows.

Im using a tweaked option setting where i run torch intensity about 5 times more then you normaly can via the options menu and it gives pretty much the same effect.
I could be wrong though.


So is the Gpu shadows any good?
They look artifitial compared to the old cpu based. As an example, if you stand in a shadow area, the new shadows do not cancle out the bumpmappings around you and it looks kinda odd. You can really tell it's an added feature 5 years after release.

They also only cast global shadow from the sun and the moon so any other lightsource will not affect the shadows. This also means the Gpu shadows do not work in dungeons or houses.

Sgt_Pitt
06-30-09, 01:52 PM
No the GPU shadows are a bit buggy.
It's probably the reason why the next stage of the update is converting to SM 3.0, maybe they depend on each other, i don't know.

The Dev also mentioned particle effects eventually making thier way to the GPU as well in a future update.

I'm running CPU shadows anyway and im getting 60fps+ now on high settings with a I7 920 and a GTX260.

Ninja Prime
06-30-09, 10:58 PM
Kinda hard to show off a graphics improvement with a shaky cam video at a bad angle with poor lighting...

Atomizer
07-01-09, 06:21 AM
Well its good news, as with its old method most of the shaders cause the CPU to do most of the work, even with a 8800GTX I found EQ2 was still laggy, while Vanguard, a more graphically advanced(though somehow they managed to make it look alot worse in some areas), runs smooth.
As for the slideshow, to me, it looks like they are comparing the old method, with world lighting OFF, compared to the new method with world lighting on.....because the old versions show no dynamic shadows, yet anyone who has played EQ2 know it has full dynamic world shadows.
So IMO, the biggest benefit will be the speed improvement we will get, so once its fully live I might go back and check it out.

ChrisRay
07-30-09, 04:58 AM
I remember when I swore up and down EQ 1 was using SM 1.1 and everyone thought it was 3.0. Its kinda funny because everyone thought EQ 2 ran badly because it was a broken SM 3.0 model on Geforce 6 cards.

Hindsight is a beautiful thing.

pakotlar
07-30-09, 11:03 AM
I remember when I swore up and down EQ 1 was using SM 1.1 and everyone thought it was 3.0. Its kinda funny because everyone thought EQ 2 ran badly because it was a broken SM 3.0 model on Geforce 6 cards.

Hindsight is a beautiful thing.

It probably ran poorly on Geforce 6 for the Geforce 6's relatively weak handling of SM 2.0 / direct x 9 . Geforce 6 was never a miracle of shader performance, although it didn't lag as badly behind ATI as it had with the 5800/5900. SM 3.0 support was its trump card, due to the possibility of shortening execution time using relatively fine grained and robust dynamic branching (vs. I believe conditional loops with sm2.0). The Geforce 6 had to use partial precision shaders [which is not DX9.0 spec], just like the 5800 to at all compete with ATI in pixel shader performance:

X800 Pixel Shader performance in RightMark: http://www.beyond3d.com/content/reviews/4/17
6800 Ultra in Right Mark: http://www.beyond3d.com/content/reviews/36/21

In SM 1.1 x800 is twice as fast roughly
In SM 2.0 it is between twice as fast and 30% faster

Now with PP (so 16bit floating point vs 24 bit on ATI): Evident in the above benchmarks as well as here: http://www.xbitlabs.com/articles/video/display/r420_28.html#sect0

Games showed this to be true in the real world. Here is a review of the X850, which was, as you remember just a way to get volume out of the X800 XT PE, and came out 6 months before 7800 (gave a good reference point, because by this time all drivers were relatively mature for both camps):
http://www.xbitlabs.com/articles/video/display/ati-radeon-x850_14.html#sect0
http://techreport.com/articles.x/7679/8

However, SM 3.0 offers more powerful dynamic branching support and helps Geforce 6 out quite a bit -->
http://www.firingsquad.com/hardware/far_cry_sm30/page9.asp (not all levels show performance gains, I showed one which does... The gains were mitigated I believe to some extent by increased SM precision and or effects in Far Cry).

but Sm2.0b evens the field: http://www.xbitlabs.com/articles/video/display/farcry20b_6.html#sect1

So it is not at all surprising the EQ2 did not run ideally on Geforce 6 (due to SM2.0 or simpler shaders and no SM3.0 dynamic branching support):

A final example of X800/X850's superiority in SM2.0 heavy games (and Half Life 2 does not support PartialPrecision (PP) calls):
http://www.xbitlabs.com/articles/video/display/ati-radeon-x850_16.html#sect0
http://www.xbitlabs.com/images/video/ati-radeon-x850/canals_candy.gif
http://www.xbitlabs.com/images/video/ati-radeon-x850/canals_pure.gif

After X800 and especially after X850 debuted Geforce 6's value proposition had less to do with its performance (which was ok to good) but its ability to support Direct X 9.0c, 128bit floating point precision, and Shader Model 3.0.

pakotlar
07-30-09, 11:36 AM
Continuation

Everquest II performance was quite weak on 6800: http://www.hardocp.com/article/2005/03/14/visiontek_xtasy_x850_xt_review/8

X850 actually kept up with 7800GTX in certain cases : http://www.pcper.com/article.php?aid=172&type=expert&pid=13

And we all knew everquest II used nothing more than SM 2.0, but 1.1 primarily...this is actually you in 2005: http://forums.nvidia.com/lofiversion/index.php?t1410.html

So unless one was quite uninformed, they would blame Sony for not building SM 3.0 support into Everquest II and "intentionally" hampering the 6800.

In terms of performance engineering ATI had the lead through r430, and regained it only with x1900, through delays and etc. 6800 came first, but lost in performance quite a bit.

ChrisRay
07-30-09, 12:07 PM
EQ 2 is/was shader model 1.1 game. Not a 2.0 game back then. The idea that the X800 alledgely ran it better or worse back then had nothing to do with 2.0's performance on either piece of hardware. So please dont start with the X800/Geforce 6 benchmark and history lineup. It totally does not matter and is actually irrelevant to the problems this game had in the first place.

I spent an enormous amount of time on this issue working with Nvidia on the EQ "Stutter" problem. And it has nothing to do with the games shader usage and implementation. Infact alot of people seem to blame the games performance entirely on its shader 1.1 implementation and thats entirely unfair to Sony. The game had alot of issues when it was first released primarily due to the fact that the game probably wasn't very optimised back then. You can put in a Geforce 6800 or even a Geforce 7600 and get pretty decent gameplay experience. Infact my laptop uses a Geforce 7600 GO with an AMD turion X2 and the game plays exceedinly well on it.

Alot of people believed EQ 2's performance problems were related to SM 3.0 back when the game was released. ((And yes Geforce 6/7 cards will get gains from this usage because its entirely angled at decreasing shader workload by increasing the amount work a single line of shader code can do in a single pass. It's possible that the changed they are talking about are possible on X800 hardware. But I seriously doubt they'll bother using a DX 9.0 extension path that theres only a few remote users of these days that'd actually benefit. IE SM 3.0 is still alive and kicking and will probably be around for several more years to come because SM 3.0 is actually not that far behind DirectX 10. Alot of SM 3.0 optional features simply became mandated by DX10. . SM 2.0B has been dead for quite some time and has no real life to it these days.)).

EQ 2. To this day and always has been a primarily CPU limited title. Sony is working now to take some of the shader 1.1 code and make it run more efficiently on the GPU so that the CPU does not get stalled waiting for shader requests. In contrast and comparison. Even Everquest 1 uses more complicated shaders than EQ 2 does. As it uses pixel shader 2.0 for almost every normal mapped surface in the most recent expansions. I actually expect the SM 3.0 to have very little impact on today's hardware because the game just isnt simply bottlenecked by the GPU. But rather the CPU. Sony is going to have to completely move to a GPU accelerated geometry method for the game to see an enormous speed up by a better implementation method.. Which would hurt backwards compatibility. The beauty of tweaking pixel shader code is it can be toned down/turned off without effecting your lowest common denominator gamer. The same cannot be said for vertex shading. This is why you see alot of "Graphically revamped" MMORPG's focusing on lighting, water, and procedural textures rather than new animations and geometry density.

Curiously. They are talking about working on the games foliage. So that might be a chance to see geometry instancing used to actually improve the CPU bottleneck. But he mentions its down the line.

pakotlar
07-30-09, 04:45 PM
EQ 2 is/was shader model 1.1 game. Not a 2.0 game back then. The idea that the X800 alledgely ran it better or worse back then had nothing to do with 2.0's performance on either piece of hardware. So please dont start with the X800/Geforce 6 benchmark and history lineup. It totally does not matter and is actually irrelevant to the problems this game had in the first place.

I spent an enormous amount of time on this issue working with Nvidia on the EQ "Stutter" problem. And it has nothing to do with the games shader usage and implementation. Infact alot of people seem to blame the games performance entirely on its shader 1.1 implementation and thats entirely unfair to Sony. The game had alot of issues when it was first released primarily due to the fact that the game probably wasn't very optimised back then. You can put in a Geforce 6800 or even a Geforce 7600 and get pretty decent gameplay experience. Infact my laptop uses a Geforce 7600 GO with an AMD turion X2 and the game plays exceedinly well on it.

Alot of people believed EQ 2's performance problems were related to SM 3.0 back when the game was released. ((And yes Geforce 6/7 cards will get gains from this usage because its entirely angled at decreasing shader workload by increasing the amount work a single line of shader code can do in a single pass. It's possible that the changed they are talking about are possible on X800 hardware. But I seriously doubt they'll bother using a DX 9.0 extension path that theres only a few remote users of these days that'd actually benefit. IE SM 3.0 is still alive and kicking and will probably be around for several more years to come because SM 3.0 is actually not that far behind DirectX 10. Alot of SM 3.0 optional features simply became mandated by DX10. . SM 2.0B has been dead for quite some time and has no real life to it these days.)).


Wait what? X800 proved to be faster for shader model iterations from 1.1 to 2.0 I included SM2.0 stuff because I'm not sure if EQ2 had any SM2.0 code or not. It was certainly coded for Direct X 9,Even if EQ2 had no connection to Direct X 9.0 what-so-ever, and despite the fact that it seemed to process a lot of vertex calls on CPU (stencil shadows especially), X800 would still have a leg up due to its faster SM1.1 performance.

Did you miss this part of my post: In SM 1.1 x800 is twice as fast roughly. You don't think that could explain much of the variation in performance between x800 and 6800 (pb)

Indicating that everything SM1.1 compatible and up ran this game well is completely disingenuous. There was quite a difference between card grades and manufacturers. As indicate in this Hardocp summation: "The VisionTek XTASY X850 XT is definitely the card for you if you are going to be playing EverQuest 2 a lot. The results of our testing in this game were quite surprising given that it is a “The Way it’s Meant to be Played” game. When it comes right down to it, the VisionTek XTASY X850 XT offers a better, more immersive, gaming experience in EverQuest http://www.hardocp.com/article/2005/03/14/visiontek_xtasy_x850_xt_review/12

About the other games I provided, Far Cry 2 was also not a "Shader 2.0" game in the sense that it used only SM 2.0 shaders. Same with Half Life 2. I used [then] shader-heavy game performance on 6800 & x800 to draw real-world correlation to both the RightMark Shader analysis results (including shader performance SM1.1 to 2.0) and to the performance we saw in EQ2. Even if EQ2 used NO direct x 9.0 code the fact that X800 kicked the poo out of 6800 on SM1.1 code still explains some of the variation. Of course, games at the time qualified as "SM2.0" if they used anything pertaining to Shader Model 2.0 spec, or anything not allowed 1.1-1.4 (floating point targets for instance).

There was nothing surprising about EQ2's 6800 performance except for the fact that EQ2 didn't use dynamic branching despite it being an nVidia "optimized" game. That was where people felt duped, and you helped reveal this marketing inconsistency. I think people mostly were just dissapointed how it ran on any platform. The strangest thing about EQ2 was that it was heavily marketed by nVidia. Someone failed in the chain of communication to tell them that there was NO SM3.0 code there :captnkill:

By the way as far as your "EQ2's performance is not limited by the shaders it uses": "You dont believe that implementing SM 2.0 was a magical performance fix for the slow performance in EQ 2. I agree. But that doesnt neccasarily mean there arent certain areas in the game that could benefit from a more unified lighting model. If you have any reason to believe otherwise. I'd like for you to share it. Obviously the entire game wouldnt need to be filled with SM 2.0 type shaders. There are many shaders in HL2, Far Cry ect which dont need high precision longer instructons." I'll let you guess who said that

http://www.nvnews.net/vbulletin/showthread.php?t=41689&page=13

Anyways, we completely agree about them not bothering overhauling their shader code unless it is trivial to do so. And SM3.0 is a great shader model, and is quite similar in terms of capability to DX10 and most likely DX11.

ChrisRay
07-31-09, 02:19 AM
Indicating that everything SM1.1 compatible and up ran this game well is completely disingenuous.

I did not say that. I said this game was built to be backwards compatible with a wide range of hardware. And that 1.1 was its baseline code and that all hardware ran that baseline code. When a developer builds a game. They have to program for what they feel is smallest base use at the time. The engine is now 4 years old. If they were doing it now they wouldnt even support DX 8.0 cards. All I said was the Shader implementation that was in EQ had nothing to do with why EQ 2 performed bad at the time. All the reasons EQ 2 had performance issues on geforce 6/7 cards are now gone in the latest build of EQ 2. And the shader model baseline has not changed any.

Did you miss this part of my post: In SM 1.1 x800 is twice as fast roughly

Nope. I think I wasn't clear enough when I said I did not care about how the X800 performed in this game. Or how the X800 compared to the Geforce 6 period. I could argue for hours about how the Geforce 6/7 series performed verses the X800 and the benefits/downsides of such a decision. But once again. I don't care. And its pointless discussion about hardware no one would buy today. So please. I am begging you. Spare me the X800/Geforce 6 debate,. I could give a crap about it.


There was nothing surprising about EQ2's 6800 performance except for the fact that EQ2 didn't use dynamic branching despite it being an nVidia "optimized" game. That was where people felt duped, and you helped reveal this marketing inconsistency. I think people mostly were just dissapointed how it ran on any platform. The strangest thing about EQ2 was that it was heavily marketed by nVidia. Someone failed in the chain of communication to tell them that there was NO SM3.0 code there

Sorry. But if you felt duped by Sony or Nvidia's marketing here then you were a victom of wishful thinking. Sony never once advertised that EQ 2 was a SM 3.0 game. Sony called EQ 2 a "Next Generation MMORPG". And there are many ways that "next" gen could be interpretted. Sony simply said that the game was built with future hardware in mind. And hardware has progressed alot and its definately helped the game run better.


By the way as far as your "EQ2's performance is not limited by the shaders it uses": "You dont believe that implementing SM 2.0 was a magical performance fix for the slow performance in EQ 2. I agree. But that doesnt neccasarily mean there arent certain areas in the game that could benefit from a more unified lighting model. If you have any reason to believe otherwise. I'd like for you to share it. Obviously the entire game wouldnt need to be filled with SM 2.0 type shaders. There are many shaders in HL2, Far Cry ect which dont need high precision longer instructons." I'll let you guess who said that

http://www.nvnews.net/vbulletin/showthread.php?t=41689&page=13

Will you please stop quoting me from 3-4 years ago> Such posts are completely out of context for today that it doesn't even matter. Yes there are corner cases where older hardware such as the Geforce 6/7 might see some performance improvements with shader code. I already said that.

On today's hardware. It's largely irrelevant due to how much more powerful they are. The best hardware from that time can be beaten for 50 dollars today so theres no excuse to even be using a Geforce 6/7/X800 card these days unless you are one of those people who are married to AGP and if thats the case your platform is more limiting than your graphic card. But today's GPU's have unified shaders so bottlenecking them the same way as the geforce 6/7 is alot more difficult.

SH64
07-31-09, 02:43 AM
WOW you guys are still arguing over this game?! :eek:

ChrisRay
07-31-09, 03:26 AM
Definately wasn't my intention. It was a comical hindsight. Thats all.

pakotlar
07-31-09, 06:40 AM
I did not say that. I said this game was built to be backwards compatible with a wide range of hardware. And that 1.1 was its baseline code and that all hardware ran that baseline code. When a developer builds a game. They have to program for what they feel is smallest base use at the time. The engine is now 4 years old. If they were doing it now they wouldnt even support DX 8.0 cards. All I said was the Shader implementation that was in EQ had nothing to do with why EQ 2 performed bad at the time. All the reasons EQ 2 had performance issues on geforce 6/7 cards are now gone in the latest build of EQ 2. And the shader model baseline has not changed any.

Nope. I think I wasn't clear enough when I said I did not care about how the X800 performed in this game. Or how the X800 compared to the Geforce 6 period. I could argue for hours about how the Geforce 6/7 series performed verses the X800 and the benefits/downsides of such a decision. But once again. I don't care. And its pointless discussion about hardware no one would buy today. So please. I am begging you. Spare me the X800/Geforce 6 debate,. I could give a crap about it.

Sorry. But if you felt duped by Sony or Nvidia's marketing here then you were a victom of wishful thinking. Sony never once advertised that EQ 2 was a SM 3.0 game. Sony called EQ 2 a "Next Generation MMORPG". And there are many ways that "next" gen could be interpretted. Sony simply said that the game was built with future hardware in mind. And hardware has progressed alot and its definately helped the game run better.


I could give a crap about it this whole debate. You mentioned a couple of things which were incorrect, I pointed them out. I really don't want to argue with you over whatever it is you're trying to say.

To be honest I'm not really interested on your views about what developers target when they make games. I was speaking specifically about your Sm 3.0 and Geforce 6 comment, which was flat out bs, and some of the things you posted after. Its a public forum, so when you make an assertion based on nothing but your personal opinion you should expect to get called on it.

And I didn't feel duped at all. A lot of other people did though, which you've mentioned yourself over and over again. I never wrote that Sony advertised EQ 2 as anything. I said nvidia advertised it. Thanks, having this kind of debate with you is really pointless.

About your thoughts on the matter. Chris, I'm getting the feeling that its not just the stuff you posted then that's meaningless.

pakotlar
07-31-09, 06:50 AM
Definately wasn't my intention. It was a comical hindsight. Thats all.

Yeah it was just there was no comedy in it because it's based on an non-existant irony. It would have been funny if people all along had actually thought that Geforce 6800 had a broken SM 3.0 implementation, and that EQ2 performed poorly because of that. But no one actually did. No one thought that deeply about its performance, beyond that the 6800 had generally weaker shader performance overall. The funny part is that you imagined a fiction, made an ironical connection to a fictitious revelation, and then vehemetly defended your position. That was funny :)

ChrisRay
07-31-09, 08:46 AM
Yeah it was just there was no comedy in it because it's based on an non-existant irony. It would have been funny if people all along had actually thought that Geforce 6800 had a broken SM 3.0 implementation, and that EQ2 performed poorly because of that. But no one actually did. No one thought that deeply about its performance, beyond that the 6800 had generally weaker shader performance overall. The funny part is that you imagined a fiction, made an ironical connection to a fictitious revelation, and then vehemetly defended your position. That was funny :)

Except. You are wrong. Alot of people did believe EQ2 was a DirectX 9.0 C game and using Shader model 3.0. Thats the entire reason I dumped the shader code. I wanted to disprove that. What it sadly did was create alot of people assuming the performance problems were related to EQ using 1.1 shaders rather than 2.0/3.0 Shaders. There was no concrete information on EQ 2's shader technology and code when the game was released. Even to this day Sony keeps that code close to their chest. In hind sight. I wish I hadn't dumped the code because it created a ton of negative feedback regarding something most did not seem to understand.

The only irony in this thread is people like you who still seem to believe that EQ 2 stuttering problems and underwhelming performance were related to the shader implementation. When infact it had nothing to do with that at all. As I said. Anyone can load up a Geforce 6/7 card these days and get no stuttering at all. Even more amusing is your attempt to turn this into some ancient X800 verses Geforce 6 debate like anyone gives a rat's colon anymore. I spent more time working on this issue with Nvidia than perhaps any other large software problem I have dealt with to date.

Now if you want to pick at someone. I'll try picking at you for a bit,

Now with PP (so 16bit floating point vs 24 bit on ATI): Evident in the above benchmarks as well as here:

Partial Precision on both the geforce 6 and Geforce 7 hardware did not give huge performance benefits. Infact 32 FP only created minor deficits. All partial precision did was lower registry constraints on the Geforce 6 cards. Geforce 6 cards were able to handle Pixel Shader 2.0 as well as shader 1.1. Also, Full 32P only reduced performance by about 10% max on Geforce 6 hardware as it wasn't really that limiting due to the increased registry space available. This performance impact was only decreased when the Geforce 7 series increase3d shader efficiency.

http://www.nvnews.net/vbulletin/showthread.php?t=30854&highlight=Cry

However, SM 3.0 offers more powerful dynamic branching support and helps Geforce 6 out quite a bit -->

Far Cry did not use Dynamic branching. It used Static Branching. The only difference between the ATI/Nvidia pathways was that Nvidia got more shader instructions in a single pass. Where ATI was limited because they couldn't exceed 128 instructions. Not every shader benefited from this. Infact there were only a few places that these performance gains were even relevant. The gains were only seen in heavy lighting situations where the shaders were used to draw lighting. It's not coincidence that EQ 2 is using its new SM 3.0 code to improve lighting and shadowing conditions.

However, SM 3.0 offers more powerful dynamic branching support and helps Geforce 6 out quite a bit -->

Dynamic Branching on the Geforce 6/7 cards was/is very slow. Even today it is not used on these cards because of performance impact. I suggest you read wikpedia to actually learn what the Geforce 6/7 cards did compared to their counterparts at the time. It wasn't until the Geforce 8 series did Nvidia increase their dynamic branching performance to where it was beneficial to be used. This isn't something that was made up. It's pretty common knowledge about the Nv4x hardware.

The Geforce 6 had to use partial precision shaders [which is not DX9.0 spec]

Yes PP is DirectX 9.0 Spec. It's been a flag for all DirectX 9.0 compiler since the second iteration of it. For SM 3.0 Compliance you must support a minimum of FP32. However you are not required to use and you can still use partial precision flags in your compiler.

A final example of X800/X850's superiority in SM2.0 heavy games (and Half Life 2 does not support PartialPrecision (PP) calls):

Half Life 2 didn't use PP because there was no gain to be had. Using any kind of DirectX modifying program such as 3Danalyze let you force the entire game in 16 PP. And the performance gain was minimal for Geforce 6 cards ((and 7 consequently)) very similar to my Far Cry post above. The performance benefit was not to be see and some of the shaders had rendering issues due to being designed around a 24 bit precision. Arguably it could have been done in 16 bit but the art team focused its efforts on the 24 bit or higher. However it was not worth the effort as the Geforce 6/7 hardware ran FP32 nearly just as fast. The only hardware that would have seen tremendous speedups was the Nv3x cards. But they were too slow at even FP16 rendering to even bother with. Let alone FP32.



Next time you want to "educate" me on the irony of game code and how "Delusional" I am. At least understand what the hell you are talking about when you reference technology. Because you dont seem to know a damn thing about what you are talking about. Also do me the favor of not quoting me out of context in this silly post war you are trying to have with me. Those posts are nearly 5 years old. Who cares? All they show is I dedicated an enormous amount of my personal time to bug testing EQ 2 for Nvidia.

I could give a crap about it this whole debate. You mentioned a couple of things which were incorrect,

Except. You were wrong the entire time. All you did was create an argument about archaic technology that I'd be surprised if anyone even cared about anymore.

ChrisRay
07-31-09, 09:43 AM
To be honest I'm not really interested on your views about what developers target when they make games. I was speaking specifically about your Sm 3.0 and Geforce 6 comment, which was flat out bs, and some of the things you posted after. Its a public forum, so when you make an assertion based on nothing but your personal opinion you should expect to get called on it.

If you don't care. Then don't post. I worked directly with Nvidia's driver team on this. Relaying feedback, experience, and data. Which is where I learned that the SM 3.0 is not the culprit for the low performance problems in EQ 2. It was in fact a driver/software problem that both Sony and Nvidia had to work together for a fix on. Which mind you they did eventually fix. As I have pointed out numerous times. You can take a Geforce 6/7 into this game now and not have any of the early problems that were experienced by users. After Nvidia confirmed that the game was not being slowed down due to any SM 3.0 implementation. I decided to investigate myself and dump the code for it. I did not make any of this up based on my "personal" opinion. My part of being an Nvidia user Group member is to collect data, Work with Nvidia on hot topics, Driver issues, and test new hardware before it becomes available to the press. So I have a pretty good understanding of the issues I am talking about.

I would love to post my e-mail correspondant with Nvidia on this issue. I cant however since I am restricted by NDA regarding most of my e-mail conversations with Nvidia due to the issues of driver patents and other various NDA issues. Am I pissy about this? Yes. Paticularly because you've taken the time to spit on something that I put alot of time and effort into back when it was relevant to alot of people. Needless to say. I'm done arguing with you. I've already lost my patience. This is not worth losing my temper over. Hence I'm done.

pakotlar
07-31-09, 09:47 AM
Yes PP is DirectX 9.0 Spec. It's been a flag for all DirectX 9.0 compiler since the second iteration of it. For SM 3.0 Compliance you must support a minimum of FP32. However you are not required to use and you can still use partial precision flags in your compiler.

Half Life 2 didn't use PP because there was no gain to be had. Using any kind of DirectX modifying program such as 3Danalyze let you force the entire game in 16 PP. And the performance gain was minimal for Geforce 6 cards ((and 7 consequently)) very similar to my Far Cry post above. The performance benefit was not to be see and some of the shaders had rendering issues due to being designed around a 24 bit precision. Arguably it could have been done in 16 bit but the art team focused its efforts on the 24 bit or higher. However it was not worth the effort as the Geforce 6/7 hardware ran FP32 nearly just as fast. The only hardware that would have seen tremendous speedups was the Nv3x cards. But they were too slow at even FP16 rendering to even bother with. Let alone FP32.

Next time you want to "educate" me on the irony of game code and how "Delusional" I am. At least understand what the hell you are talking about when you reference technology. Because you dont seem to know a damn thing about what you are talking about. Also do me the favor of not quoting me out of context in this silly post war you are trying to have with me. Those posts are nearly 5 years old. Who cares? All they show is I dedicated an enormous amount of my personal time to bug testing EQ 2 for Nvidia.
First off, who claimed that Geforce 6 wasn't orthogonally FP32? Btw, before we continue, quick trivia question: For hardware that is int32 throughout, are there any benefits in rendering at say, Int16 color depth? So if we're talking about a card that renders internally at 32bit integer precision, is there any benefit in lowering the color depth of the game to 16bits?

I'll hit the rest of your post a little later. But these portions are pretty laughable. The reason PP wasn't exposed in HL2 has NOTHING to do with performance benefits. Of course PP has performance benefits. The reason HL2 ran without explicit PP shaders is because PP was never considered to be full DX 9.0 spec, and FP16 shaders often compromised quality. Valve was never happy with nVidia's solution, so they didn't use it. That's it. Anyways NV30/35 drivers "did" force pp in HL2, flaggin certain shaders and replacing them with pp versions exposed through the drivers. Ex: http://techreport.com/articles.x/5642.

Like you just said yourself, PP was introduced in the 2nd revision of Dx9.0. It was a shoehorn attempt by nvidia to give the NV30 a chance to compete. The reason it's called partial precision is because it quite literally is not the full precision required by Direct x 9.0 at a minimum. That's why you have to flag the shader. No need to educate me on things like this Chris.

Here, maybe you should read up on this yourself before berating me with unsupported claims: http://www.beyond3d.com/content/interviews/23/

B3D: "Note the word "choices". DX9 specifies that for hardware to be DX9 "compliant", the minimum specification for floating point is 24-bit. 24-bit Floating Point is essentially equivalent to 96-bit colors"

About 6800. I even provided the links (beyond3d evaluations in my 1st post). The 6800 was FP32 throughout the pipeline of course. However the use of PP alleviated some register pressure, and freed up ~30% performance, depending on the shader (some received no benefit). The 6800 was slower in a vast # of shaders, 1.1 to 2.0, so using PP where possible was still preferrable, although not nearly as critical as in NV30/35's case. Still, with 1.1 shaders you could find examples where ATI's 2nd gen DX 9.0 part performed twice as fast as NV40. In some cases the pp version allowed the Geforce 6 to catch up, or even take over in performance compared to ATI, although of course, in many cases register pressure wasn't a bottleneck and 6 series received no performance gains. Again, all the information is out there.

That's why I'm saying discussing this with you isn't going anywhere. Let's just drop it ok? No one is trying to "educate" you. I really don't care what you believe. It's just that certain things are true, and some of what you're claiming isn't. Like in the above quoted. Literally all of the empirical bits are wrong (minus your dedication to EQ2..).

See unlike you, I enjoy facts! Btw, the fact that you beta tested drivers for nvidia really doesn't impress me. I think it'd be interesting to talk about in a different context. There is a reason why students of debate are taught to immediately call out argument from authority (it's an obvious logical fallacy). You'll never see good logicians or politicians supporting empiricist assertions with their authority in the subject matter. It is immediately picked apart and you look like a fool (because really, what does your authority have to do with the validty of a fact...it is either true or not true). Anyways, I've alraedy given you props for being involved in the exposure of EQ2 as a non-SM3.0 game. So no need to stuff our faces with what we already give you credit for.ngs when you do that. It achieves the opposite effect of what I know you're intending.

pakotlar
07-31-09, 09:54 AM
If you don't care. Then don't post. I worked directly with Nvidia's driver team on this. Relaying feedback, experience, and data. Which is where I learned that the SM 3.0 is not the culprit for the low performance problems in EQ 2. It was in fact a driver/software problem that both Sony and Nvidia had to work together for a fix on. Which mind you they did eventually fix. As I have pointed out numerous times. You can take a Geforce 6/7 into this game now and not have any of the early problems that were experienced by users. After Nvidia confirmed that the game was not being slowed down due to any SM 3.0 implementation. I decided to investigate myself and dump the code for it. I did not make any of this up based on my "personal" opinion. My part of being an Nvidia user Group member is to collect data, Work with Nvidia on hot topics, Driver issues, and test new hardware before it becomes available to the press. So I have a pretty good understanding of the issues I am talking about.

I would love to post my e-mail correspondant with Nvidia on this issue. I cant however since I am restricted by NDA regarding most of my e-mail conversations with Nvidia due to the issues of driver patents and other various NDA issues. Am I pissy about this? Yes. Paticularly because you've taken the time to spit on something that I put alot of time and effort into back when it was relevant to alot of people. Needless to say. I'm done arguing with you. I've already lost my patience. This is not worth losing my temper over. Hence I'm done.

CHRIS, jeezus man, I NEVER ONCE CLAIMED the performance issues had ANYTHING to do with SM3.0. The fact that the game ran a bit slower on nvidia hardware at the time was at least partially related to the fact that nvidia's 6800 nearly always executed shaders a bit slower compared to X800/x850 (not in all cases slower/clock but after taking clock speed into account, nearly always slower). That's why SM3.0 was such a big deal for nvidia at the time. Well that and HDR. Nvidia had no problems with its SM3.0 implementation. It was actually a big selling point in the cases it was exposed (SC:CS was a great example). That made me want one more than anything else. ATI's solution always felt like it was just "getting by" with FP24 pixel shaders, despite the fact that it was often much faster.

Fine, so you're telling me that nvidia spent a bunch of time optimizing its hardware to run the game well? Great, I guess I'll take your word on it. Its what the company was doing from Nv30 up until G71. So it just had less to fix during Geforce 6 days because the 6 series was a significantly better engineered part. I'm not sure if NV40 did any shader replacement, but I'm certain that I could dig that up. Ok, why are you telling me this?

Are we clear buddy?

ChrisRay
07-31-09, 10:05 AM
I'll hit the rest of your post a little later. But these portions are pretty laughable. The reason PP wasn't exposed in HL2 has NOTHING to do with performance benefits. Of course PP has performance benefits.

Minor Performance benefits. Which created issues with glass shaders. If you don't believe me. Take tommti's 3D Analyzer software. And Force "PP" flag on all shaders in Half Life 2. You will set a speedup. But its roughly in the range of 5% and created rendering areas with places like "glass" shaders.

Anyways NV35 "did" force pp in HL2

The NV35. Aka Geforce FX 5900 uses DirectX 8.1 as its default renderer for HL2. It Always has. I wasn't talking about the Geforce 5 cards was I?

bout 6800. I even provided the links (beyond3d links in my 1st post). The 6800 was FP32 throughout the pipeline. However PP alleviated some register pressure on the 6 series, and freed up ~30% performance, depending on the shader (some received no benefit)

Yes. In a full throughput test where the primary bottleneck was registry performance. The Geforce 6 series could lose somewhere to 30% performance using FP32. However this is a "Synthethic" test. IE. It doesn't take into account that no shader is designed to "Run" like these ones in modern games. Shaders pass through pipeline and then another comes through the pipeline. These specific tests are designed to run the same shader code through the GPU pipeline repeatively as a benchmarks. Its not a real world result. This is why you never saw this kind of performance deficit using FP32 verses FP16. The performance benefits in Half Life 2 were not there.


Here is a bit on DX9.0 and partial precision: http://www.beyond3d.com/content/interviews/23/


And your point? I was not arguing that partial precision was good or bad. I said that the performance impact on Geforce 6/7 hardware not large when moving from FP16. Especially compared to Geforce FX. Everyone knows the Geforce FX did not have the registry space to run DirectX 9.0 shaders in FP32 fast. Let alone FP16. The Nv35 in comparison to the NV30 did replace 2 of its integer units with FP units. But was still confined by registry making it unable to cope with heavy registry usage.

Minimum Dx9.0 was always considered S16e7. Ok? PP is an nVidia addition to the spec, which Microsoft allowed.

Thats not what you said. You said PP is not a part of DirectX 9.0 spec. That is wrong. Partial Precision is infact a part of all recent DirectX 9.0 builds. And has been since the debut of the Geforce FX. Yes it may not have originally been intended for DirectX 9.0 specification. It was however updated to be included. I am not saying otherwise either.


It was always clear this was an extension to MS spec at nvidia's request, and not orthodox Directx 9.0. Anyways, like I said, I don't particularly care what you believe.

See unlike you, I enjoy facts!

There is nothing "non factual" about what I said. SM 3.0 was not initially a part of DirectX 9.0 spec either. The fact is. PP is and has been a supported standard for the majority of time DX 9.0 accelerators have been available. Yes it may have been changed. That doesn't change that your initial comment about PP "Not being DX Spec" was wrong. Because it is a part of baseline DirectX 9.0 spec. Before SM 2.0A, Before SM 2.0B, And Before SM 3.0. You seem to suffer a major point of confusion regarding the Geforce 5/ Geforce 6, Geforce 7, and Geforce 8 series. All which behave very different when operating FP16 or higher calls. You do realise that all your links have done is reinforce my original point?

Nvidia had no problems with its SM3.0 implementation.

This is wrong. There were some drawbacks to Nvidia's SM 3.0 implementation. Firstly its Dynamic Branching performance was insufferably slow and unusable. Hence why anything that used SM 3.0 was using Static Branching. ((See Far Cry SM 3.0 implementation. ATI even did a whole campaign of the HD1900XT to where they stated they did "SM 3.0 Right" because their dynamic branching granularity was much better than Nvidias. As well as supporting HDR with AA. ((Though HDR was not specific to SM 3.0)). It wasn't until the Geforce 8 that Nvidia actually supported AA + HDR via the ROPS.

ChrisRay
07-31-09, 10:11 AM
The fact that the game ran a bit slower on nvidia hardware at the time was at least partially related to the fact that nvidia's 6800 nearly always executed shaders a bit slower compared to X800/x850

You have been trying to correlate the initial problems percieved with this game on Nvidia hardware. ((IE the major stuttering problems that many believed to be due to SM 3.0 implementation)) to the shader performance of the Nvidia cards. This is not the case. The performance problems experienced with early builds of Everquest was not shader related. It was an entirely different issue that Sony/Nvidia fixed together. Hence why the same hardware can play the game without stuttering today that was apparent in early builds of the game.

You keep to seem operating under the assumption that this performance problem had anything at all to do with shader performance. It didn't. It was an entirely different issue. There are many functionality issues with a graphic card that go beyond just its shaders. And this issue just happened to be one of the ones that wasn't related to shader performance.

As I said in a prior post. The only reason I dumped EQ 2 shader code was to point that the performance problems were completely unrelated to SM 3.0. Which alot of people believed at the time. Performance variables between the X800/geforce 6 or any piece of hardware are not just limited to the capability of its shader units. Pixel Fillrate, Texture fillrate, Zfill, AA Cycles within the ROPS all play an integral role in performance of a piece of hardware.

At which point. I have gone past the point of sheer annoyance. Hence I am done responding to you. I will close with this. Nothing I have said is factually incorrect. Everything you have linked has reinforced my posts regarding what I have said. That being said. I am going back to the initial discussion.

ChrisRay
07-31-09, 10:32 AM
My original post was directed at the irony that alot of people believed that EQ 2 was using SM 3.0 because of Sony and Nvidia's heavy promotion of the game upon release. Despite neither company making a claim to the game being SM 3.0. Part of my chuckle was internally related to what I remember going through 4 and half years ago in regards to this subject. As I said. In Hind Sight. I regret dumping the shader code. Though it probably would have come to light eventually. It gave alot of people the wrong impression as to why EQ was having performance issues with Geforce 6 cards. Which was unrelated to the shader code.

For anyone who's actually interested in the topic at hand. Regarding EQ 2's use of SM 1.1 and how it has impacted their lighting models. One of the EQ devs has been very kind to discuss it in rather good detail.

http://forums.station.sony.com/eq2/posts/list.m?topic_id=454116

It's very interesting because he talks about how EQ 2 was built from the ground up as a SM 1.1 game. And the engine is partially limited by it. And how the SM 3.0 upgrades will primarily effect lighting and light sources from your charactor. The beauty of such a change is it will likely have no impact on a modern GPU's performance at a moderate resolution. 1680x1050. Due to the fact that the pixel shaders are not the games primary bottleneck. For most people this will be a quality gain at no performance cost. And on some hardware there may be some minor speedups.

He also goes into the possibility of introducing geometry instancing into future foliage. Which could improve performance in some CPU limited scenerios where foliage is a culprit for hurting performance. This is likely the biggest spot where you'll see performance benefits.

pakotlar
07-31-09, 11:05 AM
Except. You are wrong. Alot of people did believe EQ2 was a DirectX 9.0 C game and using Shader model 3.0. Thats the entire reason I dumped the shader code. I wanted to disprove that. What it sadly did was create alot of people assuming the performance problems were related to EQ using 1.1 shaders rather than 2.0/3.0 Shaders. There was no concrete information on EQ 2's shader technology and code when the game was released. Even to this day Sony keeps that code close to their chest. In hind sight. I wish I hadn't dumped the code because it created a ton of negative feedback regarding something most did not seem to understand.

The only irony in this thread is people like you who still seem to believe that EQ 2 stuttering problems and underwhelming performance were related to the shader implementation. When infact it had nothing to do with that at all. As I said. Anyone can load up a Geforce 6/7 card these days and get no stuttering at all. Even more amusing is your attempt to turn this into some ancient X800 verses Geforce 6 debate like anyone gives a rat's colon anymore. I spent more time working on this issue with Nvidia than perhaps any other large software problem I have dealt with to date.

Far Cry did not use Dynamic branching. It used Static Branching. The only difference between the ATI/Nvidia pathways was that Nvidia got more shader instructions in a single pass. Where ATI was limited because they couldn't exceed 128 instructions. Not every shader benefited from this. Infact there were only a few places that these performance gains were even relevant. The gains were only seen in heavy lighting situations where the shaders were used to draw lighting. It's not coincidence that EQ 2 is using its new SM 3.0 code to improve lighting and shadowing conditions.


Dynamic Branching on the Geforce 6/7 cards was/is very slow. Even today it is not used on these cards because of performance impact. I suggest you read wikpedia to actually learn what the Geforce 6/7 cards did compared to their counterparts at the time. It wasn't until the Geforce 8 series did Nvidia increase their dynamic branching performance to where it was beneficial to be used. This isn't something that was made up. It's pretty common knowledge about the Nv4x hardware.



Dynamic Branching on Geforce 6 wasn't optimal but useful. Once again Chris, you're absolutely wrong about its performance impact. It could certainly be beneficial for performance, and was faster than static branching on the hardware. Geforce 6's coarse granularity obviously hampered branching performance, but it wasn't "broken", just less useful than in future iterations. Let's see: http://ixbtlabs.com/articles2/gffx/nv43-p02.html.
http://www.behardware.com/articles/514-2/nvidia-geforce-6600-gt.html
This is getting boring. Please for the love of god do some research.

About Dynamic Branching in Far Cry. I'll check your link out in a second. It does seem that most of the performance benefit came from the longer shader instruction allowance, and that Crytek chose not to use dynamic flow control in lieu of static branches and unrolled loops. Great, why is this important? It still stands that SM3.0 was fine on Geforce 6.

I never commented on EQ2 stuttering, just the lower overall performance.

Finally, once again: Chris, Geforce 6's slower performance with SM1.1 shader code OBVIOUSLY MUST AFFECT ITS PERFORMANCE WITH SM1.1 SHADERS IN-GAME. I hope you understand this. Its not the only factor with regards to EQ2, but given that this is probably the G6800Ultra's weakest point compared to X800XT PE or X850 XT, it is certainly an obvious one. I'm not sure what % of run-time was spent on execution of shader code, but it was clearly significant. The only reason you're arguing this is because someone is challenging your authority. It's silly my friend.

I'm completely sick of talking to you. I can admit when I don't know something. I was wrong about dynamic flow control with Far Cry, although that was easy to mistake, and does not take away from my assertion that SM3.0 helped Geforce 6.0. I'm not sure what you're trying to argue either. One moment you say that people are wrong because they blamed EQ2's poor performance on Geforce 6's SM3.0 implementation, next you're arguing that Geforce 6 performance on SM1.1 - SM2.0 code is a non factor in in-game performance, then you're saying that SM3.0 implementation is broken in Geforce 6 hardware. It's complete nonsense.

SM3.0 improved performance on G6, SM1.1-2.0 was slower overall compared to the competition (sometimes dramatically, especially with SM1.1 shaders), and EQ2 was certainly slower on G6 in part because of its slower performance on SM2.0 MODEL code (1.1-2.0). One caveat here that even without PP calls, Geforce 6 wasn't necessarily slower per clock on all shader code. It sometimes lost quite dramatically (once again, up to 2x slower with SM1.1 shaders) but sometimes the loss was incidental to its lower clock speed.

pakotlar
07-31-09, 11:14 AM
You have been trying to correlate the initial problems percieved with this game on Nvidia hardware. ((IE the major stuttering problems that many believed to be due to SM 3.0 implementation)) to the shader performance of the Nvidia cards. This is not the case. The performance problems experienced with early builds of Everquest was not shader related. It was an entirely different issue that Sony/Nvidia fixed together. Hence why the same hardware can play the game without stuttering today that was apparent in early builds of the game.

You keep to seem operating under the assumption that this performance problem had anything at all to do with shader performance. It didn't. It was an entirely different issue. There are many functionality issues with a graphic card that go beyond just its shaders. And this issue just happened to be one of the ones that wasn't related to shader performance.

As I said in a prior post. The only reason I dumped EQ 2 shader code was to point that the performance problems were completely unrelated to SM 3.0. Which alot of people believed at the time. Performance variables between the X800/geforce 6 or any piece of hardware are not just limited to the capability of its shader units. Pixel Fillrate, Texture fillrate, Zfill, AA Cycles within the ROPS all play an integral role in performance of a piece of hardware.

At which point. I have gone past the point of sheer annoyance. Hence I am done responding to you. I will close with this. Nothing I have said is factually incorrect. Everything you have linked has reinforced my posts regarding what I have said. That being said. I am going back to the initial discussion.

Arguing with you is a fool's errand. You have quite literally no understanding of the subject.