PDA

View Full Version : GeForce FX



Halcyon
12-15-2002, 07:36 AM
Ok, i just got done looking at the specs and the previews for this card. Let me just say....I WANT ONE NOW!!!!!!! But...i looked around for the release date and i couldn't find one at all. Is it already out?

SirKnight
12-15-2002, 07:42 AM
Nope. And don't expect them untill sometime in the first 3 or so months of next year.

-SirKnight

jwatte
12-15-2002, 08:33 AM
The press release said "February" AFAIR.

However, looking at the specs, I don't see anything that this card can do more of than the Radeon 9700, which has been available for a while now.

The nVIDIA proprietary vertex and fragment program extensions are more powerful than what the 9700 drivers currently expose, though. Is that worth the wait? You decide. Maybe just get both? :-)

alexsok
12-15-2002, 09:49 AM
Originally posted by jwatte:
The press release said "February" AFAIR.

However, looking at the specs, I don't see anything that this card can do more of than the Radeon 9700, which has been available for a while now.

The nVIDIA proprietary vertex and fragment program extensions are more powerful than what the 9700 drivers currently expose, though. Is that worth the wait? You decide. Maybe just get both? :-)

You kinda contradict yourself there m8 http://www.opengl.org/discussion_boards/ubb/smile.gif
GeForce FX is more powerful than R9700pro, make no mistake about that! It offers several significant advantages such as dynamic flow control in VS, opposed to static flow control offered by R300, a conditional mechanism in PS, longer instructions in PS and an overall better organization of the architecture (i saw the charts), so NV30 is indeed quite a bit more powerful...

The question remaining is whether these advantages be utilized in some way by anyone else, other than OpenGL demo writers (as most people around here are)?

PH
12-15-2002, 10:20 AM
The vertex and fragment programs of the GeForceFX are more powerful. However, you can implement the same effects on the 9700, just not in the same way. With high level shading languages that compile into multiple passes this will be transparent to the programmer. In the end it only boils down to which is faster ( of which I'm sure the NV30 is ).

Mishuk
12-15-2002, 10:33 AM
HI!
This card has been sent to the reviewers at November. The mass production of the chip will perform at December, 2002. You may expect the card in next Feb 2003.

Mishuk

M/\dm/\n
12-15-2002, 08:26 PM
I'm wondering why 0.13 basis didn't removed additional heat & frequency hasn't been rised much?

nutball
12-16-2002, 03:19 AM
Originally posted by M/\dm/\n:
I'm wondering why 0.13 basis didn't removed additional heat & frequency hasn't been rised much?

Because there's about twice the number of transistors on NV30 than previous NVIDIA products.

M/\dm/\n
12-16-2002, 03:37 AM
Then they should work at least 2x faster http://www.opengl.org/discussion_boards/ubb/biggrin.gif GF4TI6 300MHZ core GFX 500MHZ core, I think with cooler like that I could get 700MHZ from my GF2GTS http://www.opengl.org/discussion_boards/ubb/biggrin.gif http://www.opengl.org/discussion_boards/ubb/biggrin.gif http://www.opengl.org/discussion_boards/ubb/biggrin.gif http://www.opengl.org/discussion_boards/ubb/biggrin.gif http://www.opengl.org/discussion_boards/ubb/biggrin.gif http://www.opengl.org/discussion_boards/ubb/biggrin.gif http://www.opengl.org/discussion_boards/ubb/biggrin.gif http://www.opengl.org/discussion_boards/ubb/biggrin.gif http://www.opengl.org/discussion_boards/ubb/biggrin.gif http://www.opengl.org/discussion_boards/ubb/biggrin.gif http://www.opengl.org/discussion_boards/ubb/biggrin.gif

[This message has been edited by M/\dm/\n (edited 12-16-2002).]

Humus
12-16-2002, 12:11 PM
Originally posted by nutball:
Because there's about twice the number of transistors on NV30 than previous NVIDIA products.

On the other hand, if you compare to a comparable sized chip like the R300, it's built on .15 and don't require a whole lot of cooling and runs at quite high frequencies too.

JONSKI
12-16-2002, 01:29 PM
There is such a thing as designing a chip just to play the frequency game *cough*Intel*cough**cough*. Let's not forget about the importance of CPI (Clocks-Per-Instruction). I don't want to call anyone a newb, but the reason AMD adopted the Performance Rating system was to reach out to those who don't know about these things and not to lie to anyone. On a similar topic, a benchmark is just a program. The ideal way to judge a piece of hardware would be to actually use it yourself.

zeckensack
12-16-2002, 02:12 PM
CPI? Nope, these are graphics chips!

fillrate=number of pixel pipes*frequency
As long as every clock cycle one pixel pops out of everey pipe, it'll be fine.
Talking CPI in this context is just nonsense ... I'd rather call it bandwith constrained, if anything http://www.opengl.org/discussion_boards/ubb/wink.gif

[This message has been edited by zeckensack (edited 12-16-2002).]

Korval
12-16-2002, 04:47 PM
I think Jonski's point is correct, though slightly misdirected.

Of all the changes and improvements in the NV30, its bandwidth reducing capabilities don't seem that much better than a 9700 Pro. Since that is where the bottleneck will, quite likely, hit anyway, there's no reason to assume that NV30 is going to have a big performance lead over the 9700.

Devulon
12-17-2002, 03:47 AM
The big thing I see on the NV30 is the dependant texture reads. More data is available at more stages (both the vertex programs and fragment programs). Dependent reading is a pain. There is definately some sort of latency associated with it. Dependent reading of a texture means no prefetch essentially. I am sure they had to do a lot of work to hide the latency. Again you can't simply cache all the textures. You will be going to memory eventually. I really would like to see how much of a hit dependent texture reads will cost you.

Devulon

davepermen
12-17-2002, 05:16 AM
Originally posted by Devulon:
The big thing I see on the NV30 is the dependant texture reads. More data is available at more stages (both the vertex programs and fragment programs). Dependent reading is a pain. There is definately some sort of latency associated with it. Dependent reading of a texture means no prefetch essentially. I am sure they had to do a lot of work to hide the latency. Again you can't simply cache all the textures. You will be going to memory eventually. I really would like to see how much of a hit dependent texture reads will cost you.

Devulon



uhm, you can do them on radeon8500 (two reads per texture unit), or on the radeon9700, 32 reads.. no problem. nothing new on the nv30, except read - count (because of the raw instruction count of the fragment program)

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.. http://www.opengl.org/discussion_boards/ubb/biggrin.gif..

SirKnight
12-17-2002, 07:06 AM
Originally posted by davepermen:
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.. http://www.opengl.org/discussion_boards/ubb/biggrin.gif..


A little biased towards the ati since you own one arent we? http://www.opengl.org/discussion_boards/ubb/biggrin.gif How can you say that the 9700 is faster when you have no proof of it? Have you seen benchmarks of the gf fx? Do you have a gf fx? I don't think so. I don't mean to sound rude and no offence to you but making statements like this with out knowing the full details is kinda ignorant. How can anyone believe ATI saying their card is faster and NVIDIA's is slower? It also goes the other way, how can one believe NVIDIA saying their card is faster than ATI's? That can't and shouldn't be believed at all, of course they are going to say their own product is superior and Godly. But once people can get a hold of an GF FX we'll then see who is the champion. http://www.opengl.org/discussion_boards/ubb/biggrin.gif

-SirKnight


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

alexsok
12-17-2002, 07:21 AM
http://www.digit-life.com/articles2/gffx/index3.html


It's interesting that NVIDIA managed to realize texture fetching commands in a pixel processor without any delays. Even dependent texture fetching going one after another are fulfilled at a clock. This can give the GeForce FX a considerable advantage over the R300 in case of complex shaders.

And that's not the only advantage GeForce FX has over R300 architecture wise!

Now, who was saying GeForce FX is inferior to R300? http://www.opengl.org/discussion_boards/ubb/biggrin.gif

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

davepermen
12-17-2002, 09:20 AM
Originally posted by SirKnight:

A little biased towards the ati since you own one arent we? http://www.opengl.org/discussion_boards/ubb/biggrin.gif How can you say that the 9700 is faster when you have no proof of it? Have you seen benchmarks of the gf fx? Do you have a gf fx? I don't think so. I don't mean to sound rude and no offence to you but making statements like this with out knowing the full details is kinda ignorant. How can anyone believe ATI saying their card is faster and NVIDIA's is slower? It also goes the other way, how can one believe NVIDIA saying their card is faster than ATI's? That can't and shouldn't be believed at all, of course they are going to say their own product is superior and Godly. But once people can get a hold of an GF FX we'll then see who is the champion. http://www.opengl.org/discussion_boards/ubb/biggrin.gif

-SirKnight


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

you got it wrong http://www.opengl.org/discussion_boards/ubb/biggrin.gif
just reading the card main speed numbers, you would have to assume its over 2x as fast as the radeon. but it isn't (that is a fact.. its about 10 - 20% on average, that is a guess..). now if you clock a radeon to the same speed, it speeds up about linearly (that is proven), and voilą, you can outperform the gfFX before its out (those are guesses, as no real gfFX was yet in real hands..).

the gfFX benches till now are nvidia only releases, and only compare about gf4. i don't think they are .. wrong.. but.. possibly.. a little biased.. possibly..

i don't see much use in the gfFX, as its very expensive, when its out in 1 or 2 months, but will not outperform (thats a guess) the radeon by much. the additional features are proprietary, so not really useful in dx9, nor in opengl if your main target is.. users.. and not gfFX users..

then again, you can code additional routines, to make use of the gfFX. i just dislike that proprietary extracoding..

oh, and.. what i really dislike is the inability of the gfFX to have floatingpoint cubemaps.. as i'm very much into cubic shadow mapping, floatingpoint cubemaps on gfFX would be very nice.. there are workarounds, sure.. still its a bit annoying..

anyways. the gfFX will be the fastest card when it will be out one day. it will as well be the most expensive card, and a card wich does not support a real standard (=> much of its power will not be really used till the extreme in most situations, say all dx9 games).
i see in price/performance currently the ati products to be the winners of the duell. and the additional "feature" of the ati, to only occupy one slot in the case makes it quite a bit more useable in small cases, when you need special cards in as well.. http://www.opengl.org/discussion_boards/ubb/biggrin.gif

sure, i'm currently ati biased. after years of loving nvidia and supporting them, i found out that somehow, the ati way is more clean, more simple, more robust.. and, it follows the gl standarts..

anyways, it will be a funny next episode, with the gfFX on the marked.. at least, i've seen yet reallife(tm) pictures of it running, and crashing with bsod.. hehe http://www.opengl.org/discussion_boards/ubb/biggrin.gif was fun

Zeno
12-17-2002, 09:26 AM
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.. http://www.opengl.org/discussion_boards/ubb/biggrin.gif..

You make it seem like clock speed doesn't count somehow..."the GFFX is only faster because of it's higher clock". So what? Same is true of Pentium vs Athlon, but the best Pentiums are faster at almost everything than the best Athlons right now, so I would maintain that Intel chose a better method of getting speed, at least for now.

-- Zeno

SirKnight
12-17-2002, 10:37 AM
the gfFX benches till now are nvidia only releases, and only compare about gf4. i don't think they are .. wrong.. but.. possibly.. a little biased.. possibly..


You can bet your bottom it's biased, hehe. http://www.opengl.org/discussion_boards/ubb/biggrin.gif

So the GeForce FX can't fo floating point cubemaps eh? Well that does suck. The shadow mapping using the cube maps would turn out pretty darn good with the floating point format. Too bad, maybe next time. http://www.opengl.org/discussion_boards/ubb/smile.gif



anyways, it will be a funny next episode, with the gfFX on the marked.. at least, i've seen yet reallife(tm) pictures of it running, and crashing with bsod.. hehe http://www.opengl.org/discussion_boards/ubb/biggrin.gif was fun


Ya, LOL! I watched that video and at first was like, hey this thing is pretty cool. Then it crashed TWO times, wow...pure comedy. http://www.opengl.org/discussion_boards/ubb/smile.gif What a way to showcase your product to tons of people on TV eh? http://www.opengl.org/discussion_boards/ubb/wink.gif I bet that nvidia guy controlling the demos was trying _very_ hard to keep a straight face and not cuss the thing out. http://www.opengl.org/discussion_boards/ubb/biggrin.gif It's ashame that happened becuase from what I have read on message boards about that video, people were saying they were thinking of buying the GeForce FX, untill they saw that. Some will disreguard it as just early buggy drivers and will still get one and have faith, but others won't which isn't good for sales. http://www.opengl.org/discussion_boards/ubb/frown.gif

-SirKnight

abrodersen
12-17-2002, 11:01 AM
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(tm) pictures of it running, and crashing with bsod.. hehe http://www.opengl.org/discussion_boards/ubb/biggrin.gif 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

davepermen
12-17-2002, 11:49 AM
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.. http://www.opengl.org/discussion_boards/ubb/biggrin.gif

so, its quite stable here http://www.opengl.org/discussion_boards/ubb/biggrin.gif

abrodersen
12-17-2002, 01:16 PM
Guess we are not using the same functionality then http://www.opengl.org/discussion_boards/ubb/wink.gif

Anders

JackM
12-17-2002, 02:51 PM
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).]

Korval
12-17-2002, 04:02 PM
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 http://www.opengl.org/discussion_boards/ubb/wink.gif


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).]

pkaler
12-17-2002, 04:18 PM
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.

abrodersen
12-17-2002, 10:42 PM
Originally posted by davepermen:
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.. http://www.opengl.org/discussion_boards/ubb/biggrin.gif

so, its quite stable here http://www.opengl.org/discussion_boards/ubb/biggrin.gif

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

pkaler
12-17-2002, 11:43 PM
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?

M/\dm/\n
12-18-2002, 12:20 AM
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.

davepermen
12-18-2002, 12:59 AM
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 http://www.opengl.org/discussion_boards/ubb/biggrin.gif

davepermen
12-18-2002, 08:36 AM
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.

Thanks.
Anders

26 works perfect, 27 does not have shadows (but _WOAH_ that **** rotates fast if i only trigger the button http://www.opengl.org/discussion_boards/ubb/biggrin.gif)

abrodersen
12-18-2002, 11:20 PM
Originally posted by davepermen:
26 works perfect, 27 does not have shadows (but _WOAH_ that **** rotates fast if i only trigger the button http://www.opengl.org/discussion_boards/ubb/biggrin.gif)

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

NitroGL
12-19-2002, 07:34 AM
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.

richardve
12-19-2002, 08:09 AM
Originally posted by davepermen:
and crashing with bsod.. hehe http://www.opengl.org/discussion_boards/ubb/biggrin.gif was fun

Did you also notice they were running Windows XP? http://www.opengl.org/discussion_boards/ubb/biggrin.gif

[/troll]

davepermen
12-19-2002, 08:46 AM
Originally posted by richardve:
Did you also notice they were running Windows XP? http://www.opengl.org/discussion_boards/ubb/biggrin.gif

[/troll]

sure http://www.opengl.org/discussion_boards/ubb/biggrin.gif i never got my gf2mx working nice with winXP eighter.. http://www.opengl.org/discussion_boards/ubb/biggrin.gif

and i had some bsod on win2000, as well..

SirKnight
12-19-2002, 08:58 AM
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. http://www.opengl.org/discussion_boards/ubb/biggrin.gif

-SirKnight

abrodersen
12-19-2002, 09:04 AM
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

davepermen
12-19-2002, 09:33 AM
Originally posted by abrodersen:
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

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? http://www.opengl.org/discussion_boards/ubb/biggrin.gif

abrodersen
12-19-2002, 12:39 PM
Originally posted by davepermen:
are you just watching the moving image, not reading the tutorial? http://www.opengl.org/discussion_boards/ubb/biggrin.gif

Yes, I'm just looking at the pretty pictures http://www.opengl.org/discussion_boards/ubb/biggrin.gif

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 http://www.opengl.org/discussion_boards/ubb/frown.gif

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).]