FSAA and high polygon loads mutually exclusive?

[MikeC]

Modern game with DirectX 8 graphics technology being played at 1024x768 with 4XS AA.

http://www.nvnews.net/#1013480924

Edit - Wow, what a coincidence. I didn't realize that you had mentioned Commanche 4 in your previous post since it spanned the window :smile:

<font size=-1>[ This Message was edited by: MikeC on 2002-02-11 02:54 ]</font>

 

[Doomtrooper]

Mike,

Is Anistropic set to 64 Tap there as were talking Anistropic and FSAA ..all the eye candy ??



<font size=-1>[ This Message was edited by: Doomtrooper on 2002-02-11 03:13 ]</font>

<font size=-1>[ This Message was edited by: Doomtrooper on 2002-02-11 03:14 ]</font>

 

[MikeC]

On 2002-02-11 02:58, Doomtrooper wrote:
Mike,

Is Anistropic set to 64 Tap there as were talking Anistropic and FSAA ..all the eye candy ??

I didn't enable anisotropic. But now that you mention it, I didn't even think about enabling it while I was playing as I was satisfied without it. Actually, the gameplay was fantastic which was refreshing. But I'll enable it and run more tests, but I need to crash - gotta' get up in 6 hours for work.

As I am rewriting our GeForce4 preview, I will definitely measure performance with Commanche 4. Since there's no timedemo, I'll have to use FRAPS and play the game using a predetermined path as I did with Max Payne. Talk at you again in the AM.

 

[Doomtrooper]

On 2002-02-11 03:07, MikeC wrote:

On 2002-02-11 02:58, Doomtrooper wrote:
Mike,

Is Anistropic set to 64 Tap there as were talking Anistropic and FSAA ..all the eye candy ??

I didn't enable anisotropic. But now that you mention it, I didn't even think about enabling it while I was playing as I was satisfied without it. Actually, the gameplay was fantastic which was refreshing. But I'll enable it and run more tests, but I need to crash - gotta' get up in 6 hours for work.

As I am rewriting our GeForce4 preview, I will definitely measure performance with Commanche 4. Since there's no timedemo, I'll have to use FRAPS and play the game using a predetermined path as I did with Max Payne. Talk at you again in the AM.

Mike could you do some shots fighting over water where the PS's come into play like here.

 

[Volenti]

Well if we're simply looking at if/how high polygon loads affect FSAA performance, why don't you use the high poly test in 3dmark 2001?

It's not fillrate/bandwidth limited, (that I know of) so we should be able to see any affects that the high poly load has.

 

[DemoCoder]

You can't just pick any engine as a benchmark. Some engines suck and are totally bottlenecked by poor coding. For example, Max Payne is very sloppily written and performs millions of memory allocations all over the place, totally bottlenecking the game wasting CPU time inside of malloc() and free(). People keep point to, IMHO, super-buggy, non-mature game engines (Giants, Max Payne, Aquanox) as evidence that next-gen DX8 titles are slow, when in fact, they're examples of immature engines.

Aquanox's performance may not be indicative of the performance of a vertex or pixel shader game, but rather, indicative of the performance of the game engine itself. The idea that pixel shaders (which are essentially just a variation on DirectX6/OpenGL blending modes) are responsible for tremendous performance drops is too simplistic.

For all the bashing of Quake3 or Unreal as benchmarks, one thing is for certain: Carmack knows his shit, and Quake3, unlike most other game engines, scales via CPU, FSB speed, and GPU. No other games show such scaling on the P4, or RDRAM/DDR, or faster GPU's, and that's because Quake3 doesn't spend a whole lot of time waiting on spin-locks because of too much synchronization, or because of poorly coded visibility algorithms or custom memory managers.

Carmack has data-flow down pat, as he's had experience since Wolfenstein to tweak and retweak his tactics. Many 3D programmers go straight from working with OpenGL/DirectX examples to writing their first game engine, with none of the requisite experience on how to manage the hardware bottlenecks.


This is why second and third generation console games seem to pull off amazing feats in the improvement of the graphics quality on the same hardware, and the reason is, after 2 or 3 years of coding on the same platform, the console programmers get better at micromanaging data flow.

 

[Teasy]

Doomtrooper, you keep talking about pixel shaders ect, but isn't this thread supposed to be about these comments from you:

As game continue to put more polys on the screen (UT 2) FSAA is not a option.

Not sure if I understand your question but FSAA and high polycount games don't mix

In other words this thread is about your claim that FSAA gets harder to use with playable framerates as poly counts go up. So could you explain why you think that?

Why would number of polygons have any relation to FSAA?.. there not linked. A normal frame at 1024x768 and a FSAA'd frame at 1024x768 uses the same number of polygons.

As Geeforcer has mentioned if a game has so many polygons that its polygon limited that can actually make FSAA free or close to free as the poly limit hides the fillrate/bandwidth hit you get from FSAA.

 

[Oats]

No drop in FPS with 2x FSAA, seems like a poly or cpu thing...

 

[Mystiq]

Technically if the framerate is high enough, couldn't the multiple sampes required for multi sampling AA come from the previous frames? I mean high enough where many frames that are rendered in a series, that if you could see a slide show, would be very much the same. Or am I hitting a dead end here? :smile:

PS: If I'm being ignorant, let me know.

<font size=-1>[ This Message was edited by: Mystiq on 2002-02-11 05:22 ]</font>

 

[Doomtrooper]

On 2002-02-11 04:47, Teasy wrote:
Doomtrooper, you keep talking about pixel shaders ect, but isn't this thread supposed to be about these comments from you:

As game continue to put more polys on the screen (UT 2) FSAA is not a option.

Not sure if I understand your question but FSAA and high polycount games don't mix

In other words this thread is about your claim that FSAA gets harder to use with playable framerates as poly counts go up. So could you explain why you think that?

Why would number of polygons have any relation to FSAA?.. there not linked. A normal frame at 1024x768 and a FSAA'd frame at 1024x768 uses the same number of polygons.

As Geeforcer has mentioned if a game has so many polygons that its polygon limited that can actually make FSAA free or close to free as the poly limit hides the fillrate/bandwidth hit you get from FSAA.

Teasy,

I think its obvious isn't it, I mean its so blatantly obvious I can't beleive people are even questioning it. I'll refer back to a Geforce 4 Ti 4600 running with 4X FSAA shot...notice the FRAME COUNTER.
BTW I never stated just high polys, but with advanced effects like Pixel Shaders many times.

Without FSAA

4xS-Accuview

So based on this do you think 4X AA is playable..and this Demo is actually pretty light...not many ship textures like you'd experience say Online etc...
I really have no idea what is causing this but what I DO know that its choking on a advanced engine with lots of polys and advanced effects and FSAA is not viable here. This is my main concern here has more games like Aquanox are released FSAA will have to take a backseat.

The card still has to basically redraw the screen so my guess is fill rate..






<font size=-1>[ This Message was edited by: Doomtrooper on 2002-02-11 05:54 ]</font>

 

[Livecoma]

I thought the topic was about performance hits for AA under a geometry limited situation.

Here's how I see it...

Say a game puts much more stress on a cards geometry performance then its bandwidth subsystem. The performance deficit created from straining the T&amp;L pipe will effectively mask the performance hit from enabling a bandwidth using feature like AA. If the bandwidth deficit becomes greater then the T&amp;L deficit the performance will drop further. Make sense?

That's why in a situation like that you may be able to sneak in 2x FSAA without taking a FPS hit, but using a mode like 4xS (@ 1024*768+) will most certiaintly surpass any geometry deficit you have...

I find this "debate" really weird lol.

<font size=-1>[ This Message was edited by: Livecoma on 2002-02-11 06:35 ]</font>

 

[Sharkfood]

I think first we need to define "FSAA"

As NVidia has now split this to mean specifically "edge/primitive antialiasing only" with it's HRAA RG/OGMS modes, this also leave texture aliasing intact. The new "Accuview" is an interesting rebuttal to this.

In general, edge and texture aliasing should be accomodated if a realistic thesis for "FSAA" is to be compared.

In CPU bound conditions, obviously adding more fillrate or bandwidth hunger can come at an "almost free" price as the added rendering muscle sometimes wont offset the severe latency from CPU operations. If the engine can't generate frames fast enough to keep the videocard fed, adding more workload to the videocard will obviously start to take up that slack- it's the overhead that determines how much slack there is to take up. :smile:

I don't honestly see a massive difference between high-poly and low-poly having some substantial difference in AA cost, except maybe in deferred rendering conditions like TBR/Kyro type of conditions. There is *some* penalty but it's almost immeasurable. You might take a 10x7 high poly versus low poly and obviously see some additional z-hits with MS on the higher polygon example, but these are z-misses otherwise so what's the savings? Not much? Could stand some testing to solidify but I wouldnt think anything dramatic.

In general, higher polygon examples today are either so poorly written, or the underlying drivers are so poorly written (layered/COM/D3D,etc.) that most of them are indeed CPU bound even on 2.0ghz CPU's and above.

From a much more simplistic point of view- additional polygon load slows performance. AA and/or AA+anisotropy also slows performance... the two together are additive. Nothing is ever really "free"- just the illusion of such if other bottlenecks are shrouding the reality.

Just my $0.02,
-Shark

<font size=-1>[ This Message was edited by: Sharkfood on 2002-02-11 07:42 ]</font>

 

[Typedef Enum]

" If you aren't going to provide anything useful then don't say anything at all. In future pointless swipes at from any user to any user will be removed. Discussion is good, pointless swipes is bad!"

Dave...

I honestly said "man..." because I had an entire message toasted when I hit the Submit button.

<font size=-1>[ This Message was edited by: Typedef Enum on 2002-02-11 08:06 ]</font>

 

[nggalai]

Hi XMas,

many thanks for your post. As people here seem to have overseen it: a quote.

MSAA only costs bandwidth and a very small amount of fill rate (for less-than-half covered edge pixels). So enabling MSAA in a geometry-limited situation will be virtually free.

Of course, if a game isn't playable without AA, it won't become playable with AA enabled. But that sure doesn't mean that AA and high poly loads are mutually exclusive. If you are geometry-limited , MSAA is almost free, in contrast to bandwidth-limited situations where it comes at a high cost.

I think people here are mistaking the influence of high bandwidth/fillrate effects for those of high polygon load. The reason Commanche and Aquanox/Aquamark don't run too well with FSAA enabled is not the polygon load, which is nothing to write home about anyway, but the many bandwidth-intense operations. Aquamark uses pixel shaders and up to 4 texture layers--small wonder FSAA won't do any longer. Also, DemoCoder has already mentioned it: the Krass engine is rather new and immature.

I think it's clear that the performance drop you encounter when enabling FSAA has only very little to do with actual geometry load.

ta,
.rb

Edit/Addendum: I am told the Krass engine as used in Aquamark can use up to 6 texture layers for some effects, even. I'll have to check with my Massive contact for the particulars, mind.rb
_________________
www.nggalai.com -- it's not so much bad as it is an experience.

<font size=-1>[ This Message was edited by: nggalai on 2002-02-11 08:56 ]</font>
________
Kawasaki VN1500R

 

[LeStoffer]

On 2002-02-11 06:34, Livecoma wrote:
I find this "debate" really weird lol.

Ditto. It seems that we're all in agreement on this matter (besides Doomtrooper that is!).

Regards, LeStoffer

 

[Doomtrooper]

Actually I really don't care what causes the slowdown, but reality is 'YOU CAN'T USE IT'. My original point was FSAA is becoming unusable with more modern engines.

You can twist it all around with technical mumbo jumbo but the frame counters don't lie. Here is whats is known as a fact:

1)Enabling 4X FSAA with Anistropic filtering on MOHAA is unplayable with a +30 player server
2)Aquanox is unplayable with 4X AA

Two fairly recent games, then Reference Mike C shots running Commanche 4, those frames are on a Geforce 4...not a Geforce 3.

I don't see the problem getting any better either, as more complex egnines are released which is what we all want this issue will only get worse.
The Codecreature engine video I downloaded shows some pretty impressive stuff. The use of Pixel Shaders is pretty heavy and thats without high poly models etc...So whats gonna happen when you try to enable FSAA on a ENGINE that looks like 'NATURE' on 3Dmark 2001.

I'm not a coder or a engineer but you don't need to be either one of those to see the results FSAA is doing in modern game engines.

Thx

 

[Dave Baumann]

The question is whether Doomtrooper specifically is talking about high poly loads, or newer engines in general?

I can see the point that when JC talks about FPS rates of 30 on a GF3 in the new Doom engine its difficult to see how, what are traditionally slower processes such as FSAA and Anisotropic filtering can become the norm.

The difficulty we have at the moment is that in all honest current game engines are not stressing the hardware because the high end hardware has advanced far quicker than the game engines (and the low end hardware that many developers still aim for). Game engines seem to be stabilizing on a 2-4 year cycle, whereas the high end hardware moves every 6-9 months.

I don’t think poly rates will necessarily have much impact on FSAA, but other parts of up-coming game engines, such as the level of mutitexuring required, and later the number of Per Pixel computations, can have an effect in the short term (until newer accelerators overtake the engines again). With high multitexturing / multipass games where bandwidth is an issue then I’d imagine FSAA may be an issue for the short term; when things start moving to more ‘per pixel’ operations on chip (so its not so dependant on bandwidth as much clock cycles/instructions per cycle) then bandwidth may not be so much the primary issue and FSAA become more viable again.

In both cases though I can see that Multisampling is far more desirable than Supersampling; Supersampling requires 4 times the per texture operations which will be intensive. However, I’d guess that Anisotropic filtering will put more load on in high multitexture situations so MS+Aniso may be an issue as well.

 

[CosmoKramer]

Some of you are really..thick for being experts in this field...

DoomTrooper has repeatedly said that he's not talking about high polycounts but ADVANCED EFFECTS in ADVANCED ENGINES.

I understood right away what he meant; it is trivial.

 

[nggalai]

CosmoKramer,

thanks, we like you too. :smile: No, seriously now: guess why I started a new thread? So we can discuss the question that Doom's posts in the Articles-thread implied.

It's of no importance what Doomtrooper "meant," this is a discussion specifically about the question found in the thread topic. Nothing more, nothing less. Or rather, it was intended to be as much, the discussion seems to have diverted again . . .
ta,
.rb

_________________
www.nggalai.com -- it's not so much bad as it is an experience.

<font size=-1>[ This Message was edited by: nggalai on 2002-02-11 18:07 ]</font>
________
volcano vaporizers

 

[Galilee]

I wouldnt way Aquanox is unplayable with FSAA.
no FSAA:
http://www.stud.ntnu.no/~vidaralm/Img/aqua.jpg
2X FSAA
http://www.stud.ntnu.no/~vidaralm/Img/aqua2X.jpg
4X FSAA
http://www.stud.ntnu.no/~vidaralm/Img/aqua4X.jpg


<font size=-1>[ This Message was edited by: Galilee on 2002-02-11 17:48 ]</font>