Kepler is certainly a very impressive architecture from a performance/watt, performance/transistor and performance/die points of view. However, the overall performance leap appears to be less than what had been typical in the past generations in percentage terms. Was power efficiently (i.e., performance/watt) given the highest priority over absolute performance in this design? For instance, the performance leaps that happened from say G80 to GT200 or from GT200 to GF100/GF110 appear to have been more significant. It would have been interesting to see just how powerful Kepler could have been had it been built within the framework of a 450-550mm^2 die size on the same 28nm process; or perhaps if the TDP value had been raised from 195W to 250W. A chip of that size could have incorporated dedicated hardware scheduling, and allow for a very potent dual precision GPGPU product, without giving up excellent gaming performance that GTX680 already provides.

The transistor density in Kepler is also a notable achievement. If my calculations are not mistaken, it appears you were able to attain more than two-fold increase in transistor density per mm^2 (GTX580 = 3.0B transistors in 520mm^2 die vs. GTX680 = 3.5B transistors in 294mm^2 die).

I cannot wait to see what you guys can do with Maxwell on an even more advanced manufacturing node!

We will satisfy your curiosity on your last point pretty soon. Will you be attending our GPU Technology Conference (http://bit.ly/jmCGuR) in May? Check the session S0642 - Inside Kepler hosted by Stephen Jones and Lars Nyland (http://bit.ly/Jk8z21).

TSMC Gives NVIDIA Priority for 28 nm Manufacturing
http://www.techpowerup.com/165708/NVIDI ... unity.html

NVIDIA today announced that LLVM, one of the industry's most popular open source compilers, now supports NVIDIA GPUs, dramatically expanding the range of researchers, independent software vendors (ISVs) and programming languages that can take advantage of the benefits of GPU acceleration.

LLVM is a widely used open source compiler infrastructure, with a modular design that makes it easy to add support for programming languages and processor architectures. The CUDA compiler provides C, C++ and Fortran support for accelerating application using the massively parallel NVIDIA GPUs. NVIDIA has worked with LLVM developers to provide the CUDA compiler source code changes to the LLVM core and parallel thread execution backend. As a result, programmers can develop applications for GPU accelerators using a broader selection of programming languages, making GPU computing more accessible and pervasive than ever before.
LLVM supports a wide range of programming languages and front ends, including C/C++, Objective-C, Fortran, Ada, Haskell, Java bytecode, Python, Ruby, ActionScript, GLSL and Rust. It is also the compiler infrastructure NVIDIA uses for its CUDA C/C++ architecture, and it has been widely adopted by leading companies such as Apple, AMD and Adobe.

"Double Negative has ported their fluid dynamics solver over to use their domain-specific language, Jet, which is based on LLVM," said Dan Bailey, researcher at Double Negative and contributor to the LLVM project. "In addition to the existing architectures supported, the new open-source LLVM compiler from NVIDIA has allowed them to effortlessly compile highly optimized code for NVIDIA GPU architectures to massively speed up the computation of simulations used in film visual effects."

"MathWorks uses elements of the LLVM toolchain to add GPU support to the MATLAB language," said Silvina Grad-Freilich, senior manager, parallel computing marketing, MathWorks. "The GPU support with the open source LLVM compiler is valuable for the technical community we serve."

"The code we provided to LLVM is based on proven, mainstream CUDA products, giving programmers the assurance of reliability and full compatibility with the hundreds of millions of NVIDIA GPUs installed in PCs and servers today," said Ian Buck general manager of GPU computing software at NVIDIA. "This is truly a game-changing milestone for GPU computing, giving researchers and programmers an incredible amount of flexibility and choice in programming languages and hardware architectures for their next-generation applications."