NVIDIA GF100 & Friends speculation

cypress has twice the alu's. Each alu is just as fast on both rv770 and cypress.
Yes, but we're referring to those WPA-PSK crack results, and the HD5970 is 6.5 times as fast as the HD4870. If you factor in unit counts and clock, that's nearly twice as fast per unit at the same clock (ok more like 70% faster if you want a more exact number).
 
I can't see why you'd disable half your TMU's for the top dog. This rumour doesn't make any kind of sense from any angle.
Why, it does. Let's say that someone "assumed" that it'll have some number of TMUs and then they've announced half that number. So that someone may say two things really: 1. that he was wrong and didn't have a clue about GF100 at all; 2. that it was NV who disabled half of units because it's EVIL and he was and still is right on the money!
So yeah that rumour makes perfect sense to me.
 
Based upon the scenario so far,

It makes 0 financial sense to focus on tesla to the detriment of graphics.

Fermi needs to win in graphics. Period.

And where did I disagree with that ? That's obvious to say the least. NVIDIA is a graphics company first and foremost. "Some" people (the ones that like to spread disinformation) were the ones that wanted everyone to believe that NVIDIA was shifting their focus with Fermi, which was nonsensical back then and it's still nonsensical now.

And as was discussed several times in this thread, the compute specific bits in Fermi are nothing compared to the graphics specific bits.
It just so happens that Fermi was designed to be not only a great graphics performer, while also being a compute monster., which serves NVIDIA's interests in moving forward in markets where there's money to be made, other than graphics.

rpg.314 said:
Based upon my guesses regarding future evolution.

I think fermi is nv's bet that GF100 is priced too high to be of much use for gamers. It'll be able to recoup money from HPC market even if graphics perf is relatively less than what it could be. The mainstream gpu market has all the profits, so as long as the "pure" graphics side is efficient enough, high-end bloat doesn't matter. So fermi's possible loss of halo isn't such a big deal. Now that feature-parity with cpu's has been (well, almost..) achieved, they can just keep pumping up the core count in future generations.

It is risky if the top dog is delayed, since that is where all the graphics-side innovation happens.

That's more or less my thoughts too, though I wouldn't say that NVIDIA is betting on GF100 being priced too high to be of much use for gamers. GF100 IS a chip for gamers, even if it was designed for more than that.
 
TDP is actually one thing I couldn't care less about.
Inbetween my i7(at 3.5Ghz), 12GB RAM, 2 x 21" CRT's, 7.1 soundsetup ect....I couldn't care less about TDP, "performance/watt" ect...it's high end....like talking about miles per gallon in F1 racing: meh!

Just going to point out that F1 races have been won on MPG.
 
It's accurate enough for gaming purposes.
No, it isn't. Not in all cases. Haven't you ever played a game with simulated physics where some swinging object started jerking around uncontrollably?

There are, of course, ways to manage the numerical errors, but I think anybody with experience in games that have physics simulations can attest, they don't always work, and we sometimes get extremely unrealistic behavior.
 
And as was discussed several times in this thread, the compute specific bits in Fermi are nothing compared to the graphics specific bits.
And I am reopening that discussion. Int alu'sl take up fair amount of area (is it ~equal to the spfp alu's?), for no good reason if you are a gamer. So far, the uses cited do not merit the amount of transistors spent on int arithmetic. Hence, the tentative conclusion that gf100 is more dp heavy (by a non-negligible amount) than it needs to be.
 
hmm not really two fronts, its more of one front with two focal points, since both major changes in Fermi actually have similiar goals at the end which is more performance for all applications that run on the GPU.

Hmm germany didn't really have two fronts, its more of one front with two focal points, since both battles actually have similar goals at the end which is more land for germany to lose.

you CAN always try to spin.
 
No, it isn't. Not in all cases. Haven't you ever played a game with simulated physics where some swinging object started jerking around uncontrollably?
That's the advantage of not being a gamer, I don't have to endure the physics hacks. ;)

At any rate, spfp is good enough for >90% of the uses.
 
No, it isn't. Not in all cases. Haven't you ever played a game with simulated physics where some swinging object started jerking around uncontrollably?

There are, of course, ways to manage the numerical errors, but I think anybody with experience in games that have physics simulations can attest, they don't always work, and we sometimes get extremely unrealistic behavior.

I think that with 3.4028234 × 10^38 (max single precision) numbers u can make science class accuracy force calculations.
The reason for jerking objects could be that the meshes for force interaction are quite limited. For life like accurate physics u would need a very dense mesh.
 
Last edited by a moderator:
Hmm germany didn't really have two fronts, its more of one front with two focal points, since both battles actually have similar goals at the end which is more land for germany to lose.

you CAN always try to spin.

And a little more spin here and it will look like an elite PR department.
 
That's the advantage of not being a gamer, I don't have to endure the physics hacks. ;)

At any rate, spfp is good enough for >90% of the uses.
I would say it's good >90% of the time, not for >90% of uses. The basic issue here is that whenever you have a physical system in the game that remains in motion in a fixed location, you run the risk of even small numerical errors accumulating.

The typical way to deal with this is to add friction to the system: if the system has sufficient friction, then those small numerical errors don't add more energy to the system than is removed by friction, and you never end up with runaway behavior.

But if the system is perturbed enough, the numerical errors become larger in magnitude (numerical errors in floating point calculations are always proportional to the size of the numbers in the calculation) and begin to outstrip friction, and you end up with objects moving faster and faster, which eventually just means they jerk around unrealistically.

By dropping numerical errors by a few orders of magnitude, double precision nearly eliminates the problem entirely.

Now, I suppose if game devs don't care about the occasional situation where objects in their game go haywire, then they are free to ignore the occasional numerical error and just let it be. But if they want their game experience to be seamless, they either have to add a fair amount of added processing to reduce the impact of numerical errors (e.g. iterative methods to eliminate errors, velocity-dependent friction), or they can swallow the performance impact of going double-precision to dramatically reduce them.

I don't know if game devs actually will ever choose to use DP in this manner, but it is certainly a possible use.
 
I think that with 3.4028234 × 10^38 (max single precision) numbers u can make science class accuracy force calculations.
You might think so, but in reality single precision is often only accurate to about 3-4 decimal places.

Edit: Without taking special care to improve the precision, of course. Sometimes the corrections are simple, other times requiring quite a bit of additional processing to recover full machine precision (~7 decimal places for single precision).
 
That's the advantage of not being a gamer, I don't have to endure the physics hacks. ;)

At any rate, spfp is good enough for >90% of the uses.

What he describes actually always happens in Cryostais when using a PPU instead of GPU physics...hell even Crysis physics has shown these bugs:

http://www.youtube.com/watch?v=jdRgLDpRQmw
http://www.youtube.com/watch?v=C7F3iVg3sp4
http://www.youtube.com/watch?v=6ikWLM5yarI

And that game is often "hailed" as being "so much better than physx"...go figure :LOL:

So you are saying that 90% of people see "poltergeists" all the time? :p
 
What he describes actually always happens in Cryostais when using a PPU instead of GPU physics...hell even Crysis physics has shown these bugs:

http://www.youtube.com/watch?v=jdRgLDpRQmw
http://www.youtube.com/watch?v=C7F3iVg3sp4
http://www.youtube.com/watch?v=6ikWLM5yarI

And that game is often "hailed" as being "so much better than physx"...go figure :LOL:

So you are saying that 90% of people see "poltergeists" all the time? :p

My first guess would be that it is a bug in code, instead of a precision problem. But that's just me.
 
Isn't 8192x8129x4bytes ? I think the current limitation of 256mb per buffer of ATI OpenCL comes from there.
Why speculate when the DX Caps Viewer has the answer?
Code:
MaxTextureWidth 16384
MaxTextureHeight 16384
MaxVolumeExtent 16384
Note that the format is irrelevant for these caps.
 
Back
Top