NVIDIA Kepler speculation thread

What's so mysterious? Harvested die + launching 7 weeks later = higher volumes at launch.

I said assuming supply keeps up. The mystery is how are yields. All we know is they are better able to meet demand at launch then they were with the 680, but perhaps you're right and it's just 7 weeks of saving up and they'll fall behind with the 670 as well.
 
Seems like 680 could be pushing GK104's limits. It will indeed be interesting to see if 670 remains in stock.

I was thinking that it was originally planned to be the 560's replacement, but the way they popped out a dualie card so fast seems to indicate otherwise. Of course they could also just have lots of contingency plans over at NV. Big Kepler doesn't appear to be planned to make a Thermi-like appearance.

Things would surely be more interesting if Tahiti had turned out faster or if AMD had pushed 7970's clocks more.
 
Funny how only the benchmarks where the GK104 compute is slower gets mentioned over and over again but where the GK104 beats the competition it never gets mentioned at all in forums (like here) or comments of reviews.

http://www.anandtech.com/show/5818/nvidia-geforce-gtx-670-review-feat-evga/15

AESEncryptDecrypt, an OpenCL AES encryption routine

GTX680 is 6% faster that the HD7970
I already detailed in the HD 7970 thread that these results are bogus because the test is broken. In actuality, HD 7970 is about twice the speed of GTX 680. I even detailed how to fix the test to give more reasonable results.

The test will be updated in a future AMD APP SDK release.
 
LuxMark performance has been broken on Nvidia hardware for quite some time due to an OpenCL regression. Using LuxMark benchmark results to make conclusions about raytracing performance in general is like saying

NVIDIA has cut nearly in half the performance of their OpenCL drivers when has introduced OpenCL 1.1 support over a year ago. The problem has never been fixed. I don't know but I would define this as a driver problem (i.e. not a problem of the benchmark).

Cycles (Blender GPU path tracer) is written in CUDA but it runs faster on the 580 than on 680 too.

Do you need more proof ?

In fact, others doing raytracing on Gamer-Kepler have found GK104 to be much better than GF100 (somewhat to my surprise).
http://www.tml.tkk.fi/~timo/HPG2009/

Timo works for NVIDIA and he compares the 680 to the 480 in the results presented.
 
Am i right if i say that what Nvidia in doing is selling the huge mount of bad GK104 cores as 670 for 400US/EUR? :LOL:
 
you realise the 480 and 580 use a nearly identical chip.

Seems like 680 could be pushing GK104's limits. It will indeed be interesting to see if 670 remains in stock.

I was thinking that it was originally planned to be the 560's replacement, but the way they popped out a dualie card so fast seems to indicate otherwise. Of course they could also just have lots of contingency plans over at NV. Big Kepler doesn't appear to be planned to make a Thermi-like appearance.

Things would surely be more interesting if Tahiti had turned out faster or if AMD had pushed 7970's clocks more.

yes, releasing a Big Kepler geforce would have meant putting an unobtainable part on the market, and/or crippled or downclocked to get more availability. all where there's no competition from AMD.
 
Seems like 680 could be pushing GK104's limits. It will indeed be interesting to see if 670 remains in stock.

Yes, yield could be more satisfactory if the chip frequency target was around 800-900 MHz.

Things would surely be more interesting if Tahiti had turned out faster or if AMD had pushed 7970's clocks more.

In this case, hopefully, we could have seen a situation of much more affordable prices. Simply because Tahiti's performance could have been out of touch and NV could have decided to play its cards otherwise.

However, all we observe is the worst possible scenario for customers with low* performance cards at astronomical prices.

Am i right if i say that what Nvidia in doing is selling the huge mount of bad GK104 cores as 670 for 400US/EUR? :LOL:

Yes, and that's why the smartest thing right now would be just to skip this generation, just give 'em time to fix the awful mess they created,
 
NVIDIA has cut nearly in half the performance of their OpenCL drivers when has introduced OpenCL 1.1 support over a year ago. The problem has never been fixed. I don't know but I would define this as a driver problem (i.e. not a problem of the benchmark).

Yes, I agree, this is a driver problem. As I said earlier: evaluating architectures on a class of workload based on a single benchmark, with a known driver problem is silly. Just like evaluating Cayman "games" performance based on Civ5 performance with an old driver - it's not predictive of much.

Cycles (Blender GPU path tracer) is written in CUDA but it runs faster on the 580 than on 680 too.

Do you need more proof ?

Proof of what? That there exist applications which run slower on 680 than 580? I never said otherwise, especially if you take an application optimized for one architecture and run it on another, as Cycles did. To get optimal performance will require retuning the code. This problem is not specific to Nvidia.

I do, however, object to the statement that ray tracing is a workload that generally runs slower on a 680 than a 580. That's not true, as I pointed out with the existence proof of a ray tracer that runs significantly faster on GK104 than GF100.

Timo works for NVIDIA and he compares the 680 to the 480 in the results presented.

Sure (notice I said GF100, not GF110), but the performance improvement from the 480 to the 580 is just clock speeds. Go ahead and adjust for them, you'll see the 680 is still beating the 580.

Not only that, but Timo's results are for the computationally most difficult part of ray tracing - they don't include shading, which is more regular and benefits more from Kepler's denser architecture, as seen in gaming benchmarks. So if you made a complete ray tracer out of Timo's engine, you'd likely see a bigger speedup over Fermi than his report indicates.

I'm not claiming Kepler is a wonder architecture with magic pixie dust that makes everything faster. Kepler definitely is a retrenchment towards traditional GPU workloads, away from Fermi's generality. But also, you should remember: you're comparing a mid range 104 part with a high end 100 part - to discuss the architecture changes it would make more sense to compare GK110 with GF100. Hopefully we won't have to wait much longer to learn about GK110.
 
over 90% the performance of a 680 for 80% the price, and higher performance per watt : the 670 is a good enough deal :)

it's not really a defective chip, it works as intended and in the end it feels like the difference between a 6800 GT and 6800 ultra (both had full chips)

anyway retail price does not need to be correlated to anything. why can't I buy windows Server 2008 R2 for the price Dell pays a windows home license, I don't know ; it's the same OS but one has disabled features.
 
My card has a default specs of 1058 Mhz base and 1124 Mhz boost clock. With stock settings it actully boosts to 1175 Mhz, at 70c it drops to 1162 Mhz, It pretty much stays at that 1162 in everything I've tried so far. In Heaven benchmark even at 80 % power target the clock mostly stays over 1100 Mhz.

Fan set on auto I can set the clock offset to about +70 Mhz and then the core clock seems to stay at 1230 Mhz when under load. In some applications this requires raising the power target a bit. Temps mostly stay under 80c in my case with the fan auto setting.

Memory seems to OC pretty well as 7 Ghz seems to work, but I haven't done much testing with it yet.

I've got 3754 points so far in 3DMark11 Extreme preset with nVidia beta drivers (3495 Graphics score)

http://3dmark.com/3dm11/3399486

I'm happy with the card and it's performance.
 
Nvidia clarifies - capacity, not yields are the problem.

As far as 28nm yields go things are looking decent. NVIDIA has said that they believe that TSMC’s 28nm process is probably the best of any new node that TSMC has ever done. Like any other process yields will continue to improve over the lifetime of the process of course, but as it stands what NVIDIA is reporting is nothing like the teething issues that 40nm went through in 2009/2010.

The real problem for NVIDIA right now continues to be overall capacity. They have been rather straightforward in stating that they need more 28nm wafer allocations and they need them yesterday. As it stands NVIDIA is expecting to be supply constrained at the wafer level throughout the end of the year, slowly becoming less constrained as capacity improves. For at least the next quarter however this means NVIDIA will be unable to meet channel demand and will have no problem selling everything they can get. This also means that the shortage of GTX 680 and GTX 690 cards may very well continue for another quarter.
 
Another aspect AMD touched on was the availability of their Southern Islands cards, which is sort of a red herring. It is true AMD's 7000 series graphics cards are more readily available in the market, but the fact of the matter is this has nothing to do with production. Instead the issue is Kepler based graphics cards are in high demand. We have talked to a few retailers and the word from them is Kepler is selling at nearly a 4 to 1 ratio over Southern Islands. This leaves plenty of volume available for AMD, but makes it appear as if Nvidia is lacking the same volume, when this is not necessarily the case.


http://www.neoseeker.com/Articles/Hardware/Reviews/Nvidia_GTX_670/16.html

h/t Diltech over at XS
 
Look like problem is common... does the problem only exist with the last driver ?

http://forums.guru3d.com/showthread.php?t=362631



http://translate.google.com/translate?sl=auto&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fwww.pcgames.de%2FGeforce-GTX-680-Thema-239723%2FNews%2FNvidia-Geforce-GTX-680-Vsync-loest-Bildhaenger-aus-Hersteller-sucht-nach-Loesung-883176%2F


Hopefully dont use v-sync stop it and it seems Nvidia is looking on a fix .. ( still annoying for some user i believe )
 
Last edited by a moderator:
Back
Top