EQ2 Shader 3.0 upgrade

Originally Posted by ChrisRay

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.

Originally Posted by ChrisRay

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.

You have no understanding of shader workloads. It's not less "real world" they're just not the same shader. You're assertion that PP didn't offer speedups was incorrect, that's what I was pointing out. The shaders used in RightMark were not in any way unrealistic. And I haven't taken a look at Half Life 2 shaders, but suffice to say that Half Life 2 used quite a bit of SM1.1 code, and that code ran significantly faster on ATI hardware.

Originally Posted by ChrisRay

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.

You were accusing me of not understanding something about PP and Geforce 6. It was a reading comprehension issue on your part. You were re-stating what I said. Its a waste of time talking to someone who can't spend the time, or have the ability, to understand the topic.

Originally Posted by ChrisRay

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.

Completely pedantic argument. The spec for full precision is a minimum FP24. That's what I clearly wrote in the next post. With regards to the conversation the fact that pp calls were allowed under Direct x 9.0 doesn't change the fact that pp didn't benefit G6 enough to give it an overall advantage in SM1.1 code over X800, which is what is relevant to the question of EQ2 performance.

Originally Posted by ChrisRay

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?

No Chris, they don't. They don't all behave very differently when operating FP16 or higher calls. Geforce 6 & 7 are extremely similar to one another, both are SIMD/MIMD architectures, running full precision for all calls, and while Geforce 8 is a significantly different architecture, with regards to precision it operates precisely the same, in an array of SIMT processing elements (not a very different programming model compared to nv40 & G70/71). FX5800, VLIW, obviously different with lower precision call handling. True story, but you have no idea of how they process SM2.0 calls.

Originally Posted by ChrisRay

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.

Who cares about Geforce 8? Why are you mentining that. You really need to read up on thsi stuff Chris, it's mighty annoying talking to a guy without the basic tools. Dynamic branching performance was certainly improved with Geforce 7 but it was far from useless on Geforce 6. The fact that it wasn't used much probably had a lot more to do with the fact that SM3.0 was only beginning to be supported, and in Far Cry 2's case, I really don't think you understand their rationale behind used pre-warmed shader cache and static branching. Read their GDC 05 presentation on it.

Here's an excerpt: "
1. Dynamic indexing only allowed on input registers; prevents passing light data via constant registers and index them in loop
2. Passing light info via input registers not feasible as there are not enough of them (only 10)
3. Dynamic branching is not free"

Dynamic branching will always incur a fee. It's just that it become less noticeable with sufficiently complex workloads and a high degree of granularity. Crytek's reasoning was that their workload wouldn't benefit from dynamic branching because their shaders were short enough that they could unroll and cache them at load. You're mistaken that their reasoning was that dynamic branching offered no performance benefits on Geforce 6.

Nvidia themselves gives a good explanation of G6 dynamic shader performance, and its usage. It certainly is beneficial with careful use. A "broken" implementation it was not: http://techreport.com/articles.x/6627/2
No one is arguing that it wasn't more of a checkmark feature for SM3.0 compatibility, but it is patently wrong to argue that it wasn't at the same time beneficial for performance.

Finally D.branching performance has NOTHING to do with this discussion, beyond showing that SM3.0 was not broken on Geforce 6.

About your assertion that factors other than shader performance affected performance, sure, and I never argued to the contrary. The fact that you think that's a novel idea is amazing. However in terms of fillrate, especially with triple & quad texturing their performance was nearly identical, and while ATI held the advantage with polygon setup, nvidia had 2x higher z-fill, lower AA hit, ATi had lower AF hit... ok but again, reading issues at work Chris. Find me where I said that the only differentiating factor was shader performance. What I actually said, and what I actually meant, was that differences in real-world shader performance correlated well with differences in EQ2 performance. The fact that you say otherwise just shows that you have no understanding of the concept.

As far as drivers go, a year after release, at the time of the 7800 gtx launch, Geforce 6800 lagged quite a bit:

Here's Anand's take: http://www.anandtech.com/video/showdoc.aspx?i=2451&p=11 " Despite the fact that Everquest 2 is an MMORPG, it has some of the most demanding graphics of any game to date. The extreme quality mode manages to tax the system so severely that even at 1280x1024 we aren't able to get above 25 FPS with the 7800 GTX. ATI pulls ahead of the single 6800U by over 100% in the widescreen 1920x1200 resolution, though in more reasonable settings the performance is closer. "

So if you think that comes down to some CPU limitation and a little extra fillrate, that's great. I don't care, it's a waste of effort. You glean nothing new and regurgitate complete nonsense. Outside of your convictions about where EQ2's performance challenges are/were you have literally 0 support, beyond your alleged conversation with nvidia & sony, but like I said authority appeals are pathetic. Smart people don't use them.

It's been a complete waste of time talking to you to be honest. Actually I'd like you to post for all of us this information from Sony saying that SM1.1 performance on Geforce 6 wasn't a factor in its performance profile. Otherwise, let's just agree that you're out of your league.

[ChrisRay]

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/5...e-6600-gt.html
This is getting boring. Please for the love of god do some research.

*Shakes head*

Dynamic Branching is entirely granularity based. You "Could" get a performance benefit from it with very careful usage. What you couldn't do is use it to produce much faster performance on most shaders. And developers would fear the latency would be too great on geforce 6 to make any use of it. On newer hardware. Using Dynamic Branching isn't such a "scare" because said latency is very well hidden.

Far Cry is a perfect example of that. The problem with Nvidia's Dynamic Branching in the Geforce 6 is that it operates at a 64 pixels. Making it very hard to use Dynamic Branching ((with Flow Control)) to bring performance levels up. Notice in this preview that the branching performance doesnt improve at all for the Geforce 7 until 64 pixels are reached.

This is why the geforce 7. ((And consquently the Geforce 6 which is even worse than the geforce 7)) branching isn't useful at all for anything in its lifetime. The branching granularity was way too large for performance to go up using it.

For simple "Fractal Rendering" the geforce 7900GTX would lose up to 60% performance. As you can see. The smaller batches were extremely detrimental to performance. ((Hence The Far Cry Scenerio)) where branching was unable to improve performance because the granularity was simply too large on the Geforce 6800/7800 cards compared to an X1800/X1900 or 8800GTX or better card.

So yes. Dynamic Branching is extremely weak on the Geforce 6/7 cards. And rounds about to points of not very useful. To extremely limited use because you couldn't use it for much. And when you could. Making use of it was more complicated than just using static branching.

The entire point of branching was to improve performance in small areas where the pixel may or may not need softening. ((IE in the shader)) and with the huge branch granularity of the Geforce 6. It's nearly impossible to make optimal use of it. Unlike modern Nvidia/ATI hardware. The Geforce 6 cannot mask its branching granularity.

http://www.behardware.com/articles/6...-8800-gts.html

((since apparently I need links to backup my assertions)).

It's really tough to assemble what you say into a cohesive thread.

The reason you dont understand is because you simply do not understand where I am coming from. My original point was that EQ 2's stuttering problems were not related to SM 3.0. Which at the time. Before everyone started dumping EQ 2's shader code. Was thought to be a SM 3.0 title. Hence I think its rather funny that they are now just talking about EQ 2 being a "SM 3.0" title. Because many. Before that time believed it was.

I was wrong about dynamic flow control with Far Cry, although that was easy to mistake

How on earth you can call this an "Easy" mistake is beyond me. Since you used it to perpetuate your argument that Nvidia needed dynamic branching to be competitive in the first place. Your head is so cluttered with marketing garbage you completely missed the entire point of what Far Cry was trying to do.

All Far Cry shader implementation is run 4 light sources within a single shader using the increased pixel shader instructions available to it from SM 3.0. All ATI"s implementation did was run 3 light sources in a single shader. Reduce due to the fact that it cannot store as many instructions as available in SM 3.0.

Beyond that. Crytek "wanted" to use flow control and dynamic branching for these instructions. But was unable to do so because of the performance impact it had on the Geforce 6 cards. Many at the time even argued that this was not a true SM 3.0 implementation since it could all be done in SM 2.0 with static branching. And the only element of SM 3.0 that it actually used was the increased instruction set. ATI did have a point here as they proved that SM 2.0B could do nearly the same amount of work. Only finding itself limited by the max instructions allowed.

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

This was what my original comment was based on... and it was based on a very very old discussion that happened 4 and half years ago. Yes its pretty common knowledge now that the game does not use SM 3.0. Back then it wasn't. Hence why I thought it was funny in hind sight.

One moment you say that people are wrong because they blamed EQ2's poor performance on Geforce 6's SM3.0 implementation,

Thats true. People did believe that. And they were wrong.

next you're arguing that Geforce 6 ran SM1.1 - SM2.0 code at the same speed as X800 & X850,

I did not say that. I said compared to the geforce FX. The Geforce 6/7 hardware capable of running simple PS 2.0 at similar speeds to 1.1. I'm not the one here trying to compare the X800 to the Geforce 6. Thats you buddy.

, 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 would incidental to its lower clock speed

The Geforce 6/7 had lower clock speeds than the X800. But it also had more shader units available to it. I didnt want to get into an argument about the Geforce 6/7 verses the X800 because you had 2 largely different approaches to shading models.

With the Geforce 7. You were rewarded for using excess MADD. While the Geforce 6 was a bit less efficient due to its second shader unit only being a MUL. But the Geforce 7/6 series also had to hide its shader latency behind a texture unit. As only half of its shader units were dedicated. While the other half shared latency with texture mapping.

hris, pixel fillrate, texture fillrate, zfill, AA cycles within the ROPS, were quite similar between the two

No. They weren't. Nvidia used a hybrid approach to its TMU's/Shader units as stated above. Which caused latency in heavy texturing scenarios. Hence depending on the workload. You may have had very different throughput.

Also. The Zfill techniques between the cards were very very different. Nvidia used its double Z approach ((which admittedly was less of an advantage with anti aliasing enabled)) which ATI has not had. And the TMUS were most definately not equal during that age. As Nvidia did not decouple its TMUs from its shader units till the Geforce 8 series.

So dont patronize me and tell me that these cards were largely architecturally similar. They weren't.

[ChrisRay]

You were accusing me of not understanding something about PP and Geforce 6. It was a reading comprehension issue on your part.

I accused you of making an incorrect statement. Thats it.

ompletely pedantic argument. The spec for full precision is a minimum FP24. That's what I clearly wrote in the next post. With regards to the conversation the fact that pp calls were allowed under Direct x 9.0 doesn't change the fact that pp didn't benefit G6 enough to give it an overall advantage in SM1.1 code over X800, which is what is relevant to the question of EQ2 performance.

But thats not what you originally wrote. You wrote PP is not DirectX spec. That was wrong. I have not argued that it not full precision. Because its not. But "is" within DirectX spec. PP isn't really relevant to SM 1.1 so I dont see your point here. I'm not the one discussing the X800. Your the one that seems to care a great deal about the X800.

But your right. PP dont benefit the Geforce 6 that much. They are recommended by Nvidia's documentation as a usage for anytime 32 Bit precision is not neccasarry. Most of the time it wasn't. Now anything less than 32 bit is unacceptable without rendering flaws.

And Again. I'm not the one comparing the X800 here for EQ 2. I am talking about stuttering. You keep bringing up the X800 like it matters.

Dynamic branching will always incur a fee. It's just that it become less noticeable with sufficiently complex workloads. Their reasoning was that their workload didn't need dynamic branching so it wasn't used. You're mistaken on their reasoning behind this.

It doesn't have too. Specially if your branch granularity is good. And you have a good way of masking its latency. You can see several cases where Nvidia/ATI lose no performance with dynamic branching even at less than 4 pixels because they have dedicated hardware to masking its usage on modern hardware. It's real easy to argue that X1800 and Geforce 8800 cards were the first hardware to really feasibly use the dynamic branching capabilities of the hardware. Dont believe me? Look at the benchmarks.

Who cares about Geforce 8? Why are you mentining that. You really need to read up on thsi stuff Chris, it's mighty annoying talking to a guy without the basic tools. Dynamic branching performance was certainly improved with Geforce 7 but it was far from useless on Geforce 6. The fact that it wasn't used much probably had a lot more to do with the fact that SM3.0 was only beginning to be supported, and in Far Cry 2's case, I really don't think you understand their rationale behind used pre-warmed shader cache and static branching. Read their GDC 05 presentation on it.

Who cares about the X800? Hardware history timelines are important because they give you an idea of what to expect. AMD marketed their hardware "SM 3.0" Done right. Because they had a much better implementation ((actually usable with limited performance loss at sub 16 pixels. I admit I dont entirely know what they use with there DX10 cards. But the Geforce 8 did it with 32.

I dont misunderstand it at all. The workload Crytek wanted to do with their shaders was simply unable to make use of the Geforce 6's dynamic branching capabilities because the latency of doing so on their 4 light shaders was too large. And don't kid yourself. Not every shader is post 128 instructions. Even today small shaders are used for simpler tasks. And branching can benefit them on X1800 + or 8800 + hardware. At least with the X1800/Geforce 8800 + developers don't have to fear using dynamic branching because the latency is so well masked with dedicated units for it.

hey don't all behave very differently when operating FP16 or higher calls

Yes they do.

Geforce FX 5800/5200/5600 prefer FX16 integer based operations. Unable to run FP16 at any form of acceptable speeds.

Geforce FX 5900/FX5700 replaced 2 integer units with FP16. However lacked the registry space to fully utilize those units. Did not have the capability of Running SM 2.0 code with any floating point proficiency. FP16 did perform better than on the NV30 but was still largely hampered by its registry space as the new units did not solve that problem. FP32 simply increases the registry space usage the problem just got bigger.

Geforce 6 hardware. Offered a greatly increased registry. Therefore using integer calls in place of Floating Point calls did not offer large performance improvements. Which was a big problem with the FX series. And FP32 was no where near as devestating to performance compared to the Geforce FX. This is where the distinction is clearly being drawn. In games such as Half Life 2, Far Cry, Forcing FP16 or FP32 only caused minor performance deficits. ((usually within the range of 2-3 FPS)) The percentage loss for going from FP16 to FP32 is not that large. But there is still some benefit on the Geforce 6 cards.

The geforce 7 series, further improved it with better registry space. Although this change was minor compared to the Geforce FX/6 changes.

The Geforce 8 just ignores PP and performs all operations at full precision. ((which is FP32 by SM 3.0/DX10 specification)). DirectX 10 does not support partial precision. But Geforce 8 will just completely ignore it.

So yes each one of these hardware behaves differently when requesting FP 16 and FP32 operations.

bout your assertion that factors other than shader performance affected performance, sure, and I never argued to the contrary. The fact that you think that's a novel idea is amazing. However, there's very little evidence that at 1280*1024 EQ was fillrate bound, which was the highest comfortable resolution for both cards.

Actually there was some decent evidence to this. I tended to play EQ 2 on a Geforce 6800GT SLI PCIE machine ((shortly after I replaced my AGP Machine)). And using SFR you could still get scaling in EQ 2. The reason for this is Split Frame Rendering will adjust its load based on the pixel fillrate bottleneck. ((And doesnt take into account vertex acceleration)). So you could see in the realm of 20-25% performance increase at 1280x1024 with SFR at the time and 50-60% increases at 1600x1200 with SFR)) But of course this depends "entirely" on the area you are in. Some places were far more leniant to pixel fillrate bottlenecks than others.

Compare Say West Freeport too Commonlands as an example.

[ChrisRay]

Some more dynamic branching benches for you to wrap your head around.

http://www.xbitlabs.com/articles/vid...gf8800_17.html

Showcasing the X1800 being up to 200% faster at dynamic branching. And 150% in lower dynamic branching usage. Remember these are just theoretical tests.

Another dynamic branching benchmark. Which shows once again. The Geforce 7/6 unable to benefit from it greatly under typical usage. ((Though there seem to be a bug for the Geforce 7. Hard to say if this ever got fixed)((Under openGL this time))

http://forum.beyond3d.com/showthread.php?t=37430

[mullet]

ChrisRay knowledge =

[ChrisRay]

Now that I am calmed down. I will be fair pako. You are right that I dont always write coherently. Especially when I get heated into a debate. I'll often find myself editing my own posts over and over again because even after I post them. I sometimes have difficulty understanding what I wrote because its usually just a rush of thoughts cominng out as I type them. I do apologize for that. I am in a better mood now that I understand your initial post was not entirely understanding of the timeline I was referring too. So it could have been an easy thing to misunderstand.

Oh his another dynamic branching bench from behardware. Which once again shows the major latency problems with even simple branches pre 64 pixels.

http://www.behardware.com/articles/5...800-xt-xl.html

Originally Posted by ChrisRay

Now that I am calmed down. I will be fair pako. You are right that I dont always write coherently. Especially when I get heated into a debate. I'll often find myself editing my own posts over and over again because even after I post them. I sometimes have difficulty understanding what I wrote because its usually just a rush of thoughts cominng out as I type them. I do apologize for that. I am in a better mood now that I understand your initial post was not entirely understanding of the timeline I was referring too. So it could have been an easy thing to misunderstand.

Oh his another dynamic branching bench from behardware. Which once again shows the major latency problems with even simple branches pre 64 pixels.

http://www.behardware.com/articles/5...800-xt-xl.html

Ok, well in that case I'll admit that you're right that it's difficult to draw a correlation between SM1.1 performance in RightMark (or ShaderMark) and how the various shaders perform in EQ2. I got heated too. Neither one of us have have run the shaders themselves, and even if that were the case that x800 was faster, it wouldn't nec. mean that this was the main affecting factor. Plus, performance seemed to be all over the place. I was initially just saying that it would make sense why Geforce 6 struggled a bit more, since it seemed to generally lag behind in shader heavy games, which I assumed EQ2 to be, at least to a similar degree that something like Far Cry was.

Nice find with the benchmark. Wasn't x1800 16pixel granularity and x1900 48? It seems that ~48 - 64 then is the cutoff for acceptable performance degredation. I suppose that's why even nvidia was very careful to suggest its use.

About the Sm3.0 shaders in EQ2, they look cool.

[Sgt_Pitt]

lol they should get you working on eq2 chris

Better yet come check out Fallen Earth, it could use a few performance tweaks. It's in beta atm so see how it goes when its released in about 38 days. It has so much potential to be a great MMO.

It reminds me of the way eq2 ran in cities when it first came out, but this time round i'm using a i7 with a gtx260.

It's having the same rendering town jerkiness problem, i keep posting for them to use occlusion culling because in beta atm it doesn't seem to be.

Fallen earth vid
http://www.youtube.com/watch?v=WQctA...eature=related


yeah EQ2 flies now on max settings with a i7, totally cpu bound it was. it can still slow down with too many light sources and shadows in guild halls though.

[ChrisRay]

Wasn't x1800 16pixel granularity and x1900 48?

I believe thats correct. It was one of the things that I remember them talking about. I'm always a little reluctant to talk about AMD's GPUs because of my lack of experience with them. Either way the X1900's was pretty good at hiding it due to the dedicated unit. I believe right now. The X1800 still has the best granularity of all dynamic branching solutions. But everything ATI/Nvidia have been doing since then has been enough to hide the latency from causing significant performance deficits.

Plus, performance seemed to be all over the place

*nods* EQ 2's performance would dramatically shift dependent on where you are or what you are doing. Animation skinning is actually one of its bigger bottlenecks. As its all drawn on the primary core. I do believe that they were recently making an effort to use secondary cores to assist with animation.

This is why having alot of players casting would constantly cause alot of performance deficit. I tend to this day try to keep number of spellcasters visible to a lower level because of the animation skinning bottleneck.

Either way. I'm Sorry if I got snappy. It just seemed odd to me that you brought up the X800. But after reading your few posts. It does seem clear that we are talking on different timelines about different things in regards to EQ 2's performance. I was commenting entirely on its stuttering problem. Which was a huge issue back then.

[ChrisRay]

lol they should get you working on eq2 chris

Better yet come check out Fallen Earth, it could use a few performance tweaks. It's in beta atm so see how it goes when its released in about 38 days. It has so much potential to be a great MMO.

What? No freerealms? Come on sir! Actually I have been spending my time playing EQ 1, EQ 2, AND vanguard lately. Dont as me why but when I play one for too long I get bored. I actually play free realms a little too. I'm hoping to get an Anti Aliasing fix for it. But I first have to finish my talks with nvidia about what the problem may be,.

[Sgt_Pitt]

Yeah i noticed that AA bug, the water dissapears when its on doesnt it ?

I don't really play eq2 much anymore, i still follow the gfx side of things though. And as for freerealms hmm i got as high as i could in mining without paying extra for the quests, the mining minigame was fun though.