GeForce FX

Originally posted by davepermen:
anyways, it will be a funny next episode, with the gfFX on the marked… at least, i’ve seen yet reallife™ pictures of it running, and crashing with bsod… hehe was fun

Hmmm. My Radeon 9700 did that a few times (again) today. Using the latest drivers, and the card has been out for months now!
Honestly, even if the raw performance of the two cards was slightly in favour of Radeon, I’d chose the nVidia card any day due to the drivers.
I haven’t seen my program run correctly on one driver release from ATI yet. And the problems are always different with new releases. Eg. with their latest release, the stencil buffer is broken.
Can’t say I’ve had that many problems with nVidia!

Anders

heh, en contraire here nvidia cards never worked that well (and not all nvidia cards worked well on pc’s of my friends, eigther…)

the radeon currently runs with the dx9beta drivers since weeks stable 24/7, coding for ARB_fp, and all that fun, running dx9 demos, dx8 demos, dx8.1 demos, gl demos, games, etc… movies, dvds, and much much more…

so, its quite stable here

Guess we are not using the same functionality then

Anders

the performance of the gfFX is, compared to the raw, brute force speed (“1gig mem”,“500 mhz core”), really slow… it is nearly twice as fast than a radeon9700 simply because of these numbers. but the card isn’t. so the radeon9700 is more advanced in optimized hw… can’t wait for higher clocked radeons…

I can reverse this by saying that Radeon 9700 have more mem bandwidth (256 bit bus/310 mem clock = 19.6Gb/sec vs 128 bit bus/500mem clock 16.2Gb/sec on GeForceFX), yet will perform slower. Current multisample anti-aliasin techniques generally rely on bandwidth, making this important factor (when it comes to speed anyway). For me as a developer, speed is irrelevent, but YMMV.

Nvidia chose to minimize pin count and chip complexity by going with 128bit bus, and equipping it with faster memory, and higher clocked core on .13 process, while ATI went opposite way. It’s a design decision.

[This message has been edited by JackM (edited 12-17-2002).]

yet will perform slower.

If you aren’t stressing the memory bandwidth. And, I would submit that, if you aren’t stressing memory bandwidth, you aren’t doing anything that requires speed anyway. Personally, I’d rather run at 1024x768 with antialiasing than 1600x1200. Of course, that could be because my monitor can’t display 1600x1200

It’s interesting that NVIDIA managed to realize texture fetching commands in a pixel processor without any delays.

Well, since it is impossible to guarentee instant-access to texture data, they have to be lying. No memory architecture can do that, unless all of the textures are in a cache. Since nVidia is still using a relatively conventional memory architecture, that is not possible. As such, this article is incorrect (or, more likely, based on nVidia propaganda).

Guarenteeing instant-access to texture data is like guarenteeing that every memory access is going to hit on the cache. It’s not, and you can’t guarentee that (except in very specific situations).

As for comparing their performance, observe:

8-pixel pipelines. Assuming trilinear filtering (and worst-case), each pipeline will need access to 8 texels. Also assuming worst case, let’s say they’re accessing 32-bit textures. In total, that’s 256 bytes (4 * 8 * 8) of data that the pixel-pipes need.

On a GeForceFX, this happens in 8 memory cycles (16 effective DDR cycles) at 500MHz. In time, that ammounts to 16ns, assuming no latency.

On a Radeon 9700 Pro, this happens in 4 memory clocks (8 effective) at 310MHz. That’
s 12.9ns, assuming no latency.

In short, the GeForce FX, in the perfect world of no latency, can transfer data at only 80% of the speed of a Radeon 9700 Pro. Not only that, the FX’s chip stalls longer. It loses more cycles than the 9700 Pro both because it transfers memory slower and because the FX is clocked faster.

Indeed, nVidia’s bandwidth saving capabilities had better be 20-30% better than ATi’s. Otherwise, you’ll se a 6-month old card outrun the best nVidia can offer.

BTW, anytime you see comments like this in an article:

But we estimate the real efficiency of these algorithms as 1.5 times for ATI and 2.0 times for NVIDIA of a physical bandwidth in typical scenarios.

and they never answer the question, “Based on what?”, disregard the article. They have no basis for that comparison or those numbers, especially since they say that they themselves cannot turn off these features. In short, they just pulled them out of nowhere (or nVidia’s pockets).

[This message has been edited by Korval (edited 12-17-2002).]

This argument is moot until I can walk to the store and buy a GFfx.

The GFfx wins on paper, but who cares?

If you do, I have a Ferrari to sell you…let me just put some paper in my printer.

Originally posted by davepermen:
[b]heh, en contraire here nvidia cards never worked that well (and not all nvidia cards worked well on pc’s of my friends, eigther…)

the radeon currently runs with the dx9beta drivers since weeks stable 24/7, coding for ARB_fp, and all that fun, running dx9 demos, dx8 demos, dx8.1 demos, gl demos, games, etc… movies, dvds, and much much more…

so, its quite stable here [/b]

Could you do me a favor and download NeHe’s tutorial 26 or 27 and see if it works. It doesn’t work for me with the dx9beta drivers or the latest ones.

Thanks.
Anders

Originally posted by abrodersen:
Could you do me a favor and download NeHe’s tutorial 26 or 27 and see if it works. It doesn’t work for me with the dx9beta drivers or the latest ones.

What exactly do NeHe’s OpenGL tutorials have anything to do with Dx drivers?

I think I saw “benchmarks” of GFX as soon as it was presented as real card, but I can’t find where, http://www.nvnews.net/ maybe?. And as far as I remember, they were NVIDIAs stats & were pretty nice looking, if I remember right then gap between 9700PRO vs. Ti4/4600 was 2| |3 times smaller than between 9700PRO vs. GFX looked huge leap in 10+ card results, I think Return to castle was the lucky one. However, most likely is only soap bubble.

Originally posted by PK:
What exactly do NeHe’s OpenGL tutorials have anything to do with Dx drivers?

its actually some of the newest gl drivers with it. its just display drivers

Originally posted by abrodersen:
[b] Could you do me a favor and download NeHe’s tutorial 26 or 27 and see if it works. It doesn’t work for me with the dx9beta drivers or the latest ones.

Thanks.
Anders[/b]

26 works perfect, 27 does not have shadows (but WOAH that **** rotates fast if i only trigger the button )

Originally posted by davepermen:
26 works perfect, 27 does not have shadows (but WOAH that **** rotates fast if i only trigger the button )

Ok, thanks. Guess I’ll have to file a report to ATI.

Originally posted by abrodersen:
Ok, thanks. Guess I’ll have to file a report to ATI.

It’s not a driver problem. The full screen quad isn’t drawn the way it should be (it’s being drawn in a perspective projection, should be an ortho) and it gets clipped by the near plane. If you change the Z on the quad from 0.1 to 0.15 the program will work fine.

Originally posted by davepermen:
and crashing with bsod… hehe was fun

Did you also notice they were running Windows XP?

[/troll]

Originally posted by richardve:
[b] Did you also notice they were running Windows XP?

[/troll][/b]

sure i never got my gf2mx working nice with winXP eighter…

and i had some bsod on win2000, as well…

Well I’ve never had a problem with BSOD’s running XP from my video cards. I at first ran a GeForce 256 DDR 32mb and now this GeForce 4 Ti 4400, no problems at all.

-SirKnight

Originally posted by NitroGL:
It’s not a driver problem. The full screen quad isn’t drawn the way it should be (it’s being drawn in a perspective projection, should be an ortho) and it gets clipped by the near plane. If you change the Z on the quad from 0.1 to 0.15 the program will work fine.

Eh??? What full screen quad? Are we both talking about the shadow volume tutorial?
Anyway, that tutorial is just an example. I’ve had lots of problems with the stencil buffer with the latest drivers. Somehow it seams I cannot clear it! A problem that does not exist with the older drivers (nor on nVidia cards).

Anders

Originally posted by abrodersen:
[b] Eh??? What full screen quad? Are we both talking about the shadow volume tutorial?
Anyway, that tutorial is just an example. I’ve had lots of problems with the stencil buffer with the latest drivers. Somehow it seams I cannot clear it! A problem that does not exist with the older drivers (nor on nVidia cards).

Anders[/b]

yes, it doesn’t work for me eighter on gf2mx… it draws a fullscreen quad to draw the shadows, and uses a stencil test to determine where…

are you just watching the moving image, not reading the tutorial?

Originally posted by davepermen:
are you just watching the moving image, not reading the tutorial?

Yes, I’m just looking at the pretty pictures

No, seriously, I was only looking at the tutorial because I had some problems with the stencil buffer combined with the latest ATI drivers, and I was hoping I could find a nice small code sample, showing the same error. Would make it a lot easier to fix the bug. Didn’t exactly read the tutorial, just went for everything using the stencil buffer. Guess this wasn’t the right example

And, yes it is a driver bug I’m experiencing. I had no problems before updating drivers, nor after changing the drivers back to an earlier release. Guess I’ll just have to work harder to find out exactly where the problem arises.
Sorry for wasting your time.

Anders

[This message has been edited by abrodersen (edited 12-19-2002).]