Half Life 2 Benchmarks (From Valve)
- Thread starter Dave Baumann
- Start date
For AF, yes, since that's almost entirely down to memory bandwidth. For AA, unlikely, since without clever optimizations in the hardware the chip will have to run the pixel shaders multiple times to calculate the pixel color (e.g. 4 times for 4xAA).
So it all depends on what the limit is: if it's vertex shaders then AA probably won't affect performance much. If it's CPU, then AA won't affect it much. If it's pixel shaders, AA will probably be too slow to be playable.
And I can't see it being CPU-limited if the difference between the FX and 9600 Pro is so high: it would have to be GPU-limited somehow. Equally, as someone pointed out, the difference in performance between the 9600 Pro and 9800 Pro is similar to their relative shader performance.
Yes, I thought that was pretty amusing, that the 'optimizations' slowed down the mid-range card
.HardOCP said:
FYI, I've been working on a DX9 product everyday since right around DX9 first came out and I can say that this is exactly what I've been finding (though I'd even remove the part about having DX9 clothing.. but then what I've been working on is far more stressful on DX9 hardware than HL2).
Yes but I just want to note...
The question is not 'is there more in VRAM' (there is) but 'is there enough in AGP' (which there can definitely be, especially with compressed textures) and 'do you have enough latency compensation'. If the latter two are true then AGP will not be a performance hit.WaltC said:
Re: ATI is canadian
Great info and thoughts in this thread. Thoroughly enjoyed reading it. However, I came across one thing I need to comment on...
I can appreciate national pride if it's filtered with a tad bit of realism and knowledge, not ignorance.
Dave Orton, Dave Rolston and Rick Bergman are all American and the main contributors to ATi's turnaround. Prior to the R300 release, ATI was a decidedly Canadian company in culture and innovation. Look where it got them.
Great info and thoughts in this thread. Thoroughly enjoyed reading it. However, I came across one thing I need to comment on...
Cpt.Canuck said:
I can appreciate national pride if it's filtered with a tad bit of realism and knowledge, not ignorance.
Dave Orton, Dave Rolston and Rick Bergman are all American and the main contributors to ATi's turnaround. Prior to the R300 release, ATI was a decidedly Canadian company in culture and innovation. Look where it got them.
Re: ATI is canadian
(Although he keeps thinking he's greek for some weird reason... )
You forgot Terry Makedon, who's also quite responsible for their turn-around and is Canadian.tazdevl said:
(Although he keeps thinking he's greek for some weird reason... )Re: ATI is canadian
I agree, he's definitely another major contributor to ATI's current succeess. However, he didn't set overall corporate strategy, organizational structure and help shape the current corporate culture. Also, not at the same level as the other boys.
digitalwanderer said:You forgot Terry Makedon, who's also quite responsible for their turn-around and is Canadian.tazdevl said:
I agree, he's definitely another major contributor to ATI's current succeess. However, he didn't set overall corporate strategy, organizational structure and help shape the current corporate culture. Also, not at the same level as the other boys.
Re: ATI is canadian
True, but he did beat their drivers into shape....and that was a LOT!tazdevl said:digitalwanderer said:You forgot Terry Makedon, who's also quite responsible for their turn-around and is Canadian.tazdevl said:
I agree, he's definitely another major contributor to ATI's current succeess. However, he didn't set overall corporate strategy, organizational structure and help shape the current corporate culture. Also, not at the same level as the other boys.
KnightBreed
Newcomer
Very true, I had forgotten this point. Somebody earlier pointed out the irony of having to use the hardware's weak point in order to emulate a feature it doesn't natively support.movieman said:
Ilfirin said:
Yeah, but besides John Carmacks remark about the twichyness of the NV30 shader architecture and some performance investigations by people here on the forum, developers haven't exactly been vocal about this. :?
Is it because it doesn't matter to them? Nah, I guess it something to do with the fact that you have everything to loose and nothing to gain by upsetting nVidia. So hush-hush it is.
Movieman:
Welcome aboard!
Unfortunately, your post is almost entirely incorrect.
(Don't worry, it still happens to me quite a lot)
No. It varies based on scene characteristics and the behavior of the texture cache, but AF is generally more of a fillrate hit than a bandwidth hit. Quick explanation:
Modern GPUs are all capable of taking one bilinear sample per pipe per clock. Applying AF (indeed, applying trilinear) therefore means spending multiple clocks on those fragments where it is needed. AF does mean fetching more texels, but assuming the texture cache is behaving as intended this doesn't necessarily mean more fetches from external memory. Meanwhile, spending multiple clocks on a single fragment means less bandwidth is being devoted to the stuff that only gets done once per fragment--z fetch, z write, and color write. As these tend to be the main consumers of DRAM bandwidth, your bandwidth requirements per clock would tend to lessen.
Except that AF also allows you to change the LOD calculation to fetch more detailed mipmaps, which does mean higher texture traffic. In general, AF tends to be at least as much if not more of a fillrate hit than a bandwidth hit, but, as I said, this can vary somewhat. What is not true is that it is primarily a bandwidth hit.
In any case, this is partially irrelevant as AF is only applied to color textures, not to many of the textures used as inputs to shaders, nor to the procedural output of shaders. Turning on AF will impact both workload and IQ less in a fragment shader heavy scene than in a fixed-function scene.
If we were talking supersampling AA (SSAA), you'd be right. But we're talking multisampling (MSAA). MSAA only samples z-values multiple times per fragment; color is calculated only once. Assuming you have the requisite z-samplers and z-calculators per pipe (which it turns out is not entirely true for R3x0's 6xMSAA mode, although the impact will be very slight or nonexistent), the performance hit from MSAA is entirely a matter of bandwidth--extra z reads and writes, and extra color writes of the same color value. (Compression does help a great deal.)
As such, MSAA only antialiases the edges of joined or overlapping polygons. In general, one can't compare MSAA to SSAA directly. Rather you need to compare MSAA + AF as a team against SSAA; while SSAA does the entire scene (inefficiently), MSAA handles the edge aliasing while AF handles the texture aliasing, each more efficiently than SSAA would.
The only problem is what I alluded to before--AF only antialiases textures, not polygon interiors in general. With sufficiently advanced fragment shaders (particularly if their output is a high contrast "texture"), this can leave some areas of the screen in need of antialiasing. The solution in such cases is to build the antialiasing into the shader calculation itself; this is the way it's done for high-end offline renderers. Not that I think this issue will show up in HL2 or any other early DX9 games.
True. However, based on the performance of the NV3x cards, and what we know about their performance characteristics (i.e. they are nearly on par with their R3x0 counterparts in VS 2.0, but woefully underperform in PS 2.0), we know that neither is the case with those cards at these settings.
Nope. MSAA won't have much impact on performance unless bandwidth becomes a problem, which it likely won't until 4xMSAA or so.
It is clearly almost entirely GPU limited at these settings for the NV3x cards, and also, although probably less so, for the 9600 Pro. It is clearly CPU limited at these settings for the 9800 Pro. Whether something is CPU limited, GPU limited, or whathaveyou applies only to a particular combination of game, scene, platform, GPU and settings.
Not at all. The 9800 Pro is getting 1.27x the 9600 Pro's performance, but it has 1.9x the fragment shader resources. (Double the pipes at 95% the clock rate.) If the 9600 Pro is entirely fragment shader limited, we'd expect the 9800 Pro to score around 90fps at these settings with an infinitely fast CPU. If, as is more likely, the 9600 Pro is slightly CPU limited as well, the 9800 Pro's innate theoretical performance would be even higher.
Of course this is irrelevant until someone comes up with an infinitely fast CPU, but it does mean that the 9800 Pro should have a good deal of headroom to increase graphical settings without losing much if any performance.
Welcome aboard!
Unfortunately, your post is almost entirely incorrect.
(Don't worry, it still happens to me quite a lot
)movieman said:
No. It varies based on scene characteristics and the behavior of the texture cache, but AF is generally more of a fillrate hit than a bandwidth hit. Quick explanation:
Modern GPUs are all capable of taking one bilinear sample per pipe per clock. Applying AF (indeed, applying trilinear) therefore means spending multiple clocks on those fragments where it is needed. AF does mean fetching more texels, but assuming the texture cache is behaving as intended this doesn't necessarily mean more fetches from external memory. Meanwhile, spending multiple clocks on a single fragment means less bandwidth is being devoted to the stuff that only gets done once per fragment--z fetch, z write, and color write. As these tend to be the main consumers of DRAM bandwidth, your bandwidth requirements per clock would tend to lessen.
Except that AF also allows you to change the LOD calculation to fetch more detailed mipmaps, which does mean higher texture traffic. In general, AF tends to be at least as much if not more of a fillrate hit than a bandwidth hit, but, as I said, this can vary somewhat. What is not true is that it is primarily a bandwidth hit.
In any case, this is partially irrelevant as AF is only applied to color textures, not to many of the textures used as inputs to shaders, nor to the procedural output of shaders. Turning on AF will impact both workload and IQ less in a fragment shader heavy scene than in a fixed-function scene.
If we were talking supersampling AA (SSAA), you'd be right. But we're talking multisampling (MSAA). MSAA only samples z-values multiple times per fragment; color is calculated only once. Assuming you have the requisite z-samplers and z-calculators per pipe (which it turns out is not entirely true for R3x0's 6xMSAA mode, although the impact will be very slight or nonexistent), the performance hit from MSAA is entirely a matter of bandwidth--extra z reads and writes, and extra color writes of the same color value. (Compression does help a great deal.)
As such, MSAA only antialiases the edges of joined or overlapping polygons. In general, one can't compare MSAA to SSAA directly. Rather you need to compare MSAA + AF as a team against SSAA; while SSAA does the entire scene (inefficiently), MSAA handles the edge aliasing while AF handles the texture aliasing, each more efficiently than SSAA would.
The only problem is what I alluded to before--AF only antialiases textures, not polygon interiors in general. With sufficiently advanced fragment shaders (particularly if their output is a high contrast "texture"), this can leave some areas of the screen in need of antialiasing. The solution in such cases is to build the antialiasing into the shader calculation itself; this is the way it's done for high-end offline renderers. Not that I think this issue will show up in HL2 or any other early DX9 games.
True. However, based on the performance of the NV3x cards, and what we know about their performance characteristics (i.e. they are nearly on par with their R3x0 counterparts in VS 2.0, but woefully underperform in PS 2.0), we know that neither is the case with those cards at these settings.
Nope. MSAA won't have much impact on performance unless bandwidth becomes a problem, which it likely won't until 4xMSAA or so.
It is clearly almost entirely GPU limited at these settings for the NV3x cards, and also, although probably less so, for the 9600 Pro. It is clearly CPU limited at these settings for the 9800 Pro. Whether something is CPU limited, GPU limited, or whathaveyou applies only to a particular combination of game, scene, platform, GPU and settings.
Not at all. The 9800 Pro is getting 1.27x the 9600 Pro's performance, but it has 1.9x the fragment shader resources. (Double the pipes at 95% the clock rate.) If the 9600 Pro is entirely fragment shader limited, we'd expect the 9800 Pro to score around 90fps at these settings with an infinitely fast CPU. If, as is more likely, the 9600 Pro is slightly CPU limited as well, the 9800 Pro's innate theoretical performance would be even higher.
Of course this is irrelevant until someone comes up with an infinitely fast CPU, but it does mean that the 9800 Pro should have a good deal of headroom to increase graphical settings without losing much if any performance.
Joe DeFuria
Legend
LeStoffer said:
Exactly. It will be interesting to see if more developers start "jumping on the nvidia shaders suck" bandwagon now that Valve has come out of the closet, so to speak.
LeStoffer said:
I haven't found a developer yet that hasn't been perfectly open about it when you ask them, it's not like you can be sued for saying the truth. Most just thought it was already public knowledge seeing as the large number of DX9 benchmarks out there that have been displaying similar results for almost a year now. But what would they do anyway? E-mail up some major news site just to say FX cards have horrible DX9 performance?
I think you will, I've been seeing a lot of developers coming out on the boards just over the last day speaking out against nVidia.Joe DeFuria said:LeStoffer said:
Exactly. It will be interesting to see if more developers start "jumping on the nvidia shaders suck" bandwagon now that Valve has come out of the closet, so to speak.
Re: issues that have not been brought up yet....
this got buried pretty quickly, just wanted to try one more time to get some feedback.
later,
epic
this got buried pretty quickly, just wanted to try one more time to get some feedback.
epicstruggle said:
later,
epic
Ilfirin said:
Good, but keep in mind that ordinary people (like me) don't have the opportunity to speak with developers and get their upfront n' frank opinion, so I really had no idea that there seem to be a concensus on the subject after all.
Ilfirin said:
Nah, it is just that there have been plenty of opportunities to vent any 'frustration' during more than half a year so the silence came off as odd to me - and it still does.
Joe DeFuria
Legend
LeStoffer said:
I have to agree.
The opportunity for developers to have stood up and said their own personal experiences was during the 3DMark fiasco. That's when nvidia was claiming how "unlike" game performance 3DMark was.
If, in fact, developers figured that the original 3DMark was more or less accurate, I think they really should have come to FutureMark's defense.
Similar threads
