Oscar Eddington (oscare@gmail.com) on 3/28/12 wrote:
> If Nvidia's graphics and compute products diverge
> as explained in this article, doesn't that make
> it difficult to use both a graphics card and a
> tesla card in a workstation for compute?

It will be nearly impossible to keep both a graphics card and a Tesla card running at full speed if these cards have different capabilities. It is too difficult to do load balancing across chips with different capabilities. Nvidia's strategy to diverge their graphics and compute products seems similar to the transition from heterogeneous pixel shaders and vertex shaders to unified shaders except it's going in the opposite direction.

Some amount of bandwidth per flop to shared data is certainly needed for GPU computing but I don't see how Mr. Kanter concludes or has the impression that 1 byte/flop is enough (Fermi) but .33 bytes/flop is not enough (Kepler). What is the basis for this conclusion/impression?

It seems to me that a key strength of Nvidia's Tesla line was that the same software that ran on Tesla also ran on Nvidia's graphics cards. Perhaps Nvidia realized that "dusty deck" Fortran code that uses double precision is better suited to Intel's MIC and Nvidia is going to focus on new codes designed to use mostly single precision. On the other hand, Intel's MIC is starting to smell like another Itanic fiasco. Intel is already saying "We know the performance of our current MIC chip stinks but just wait until our next version comes out." This is exactly what Intel said about each generation of their Itanic microprocessor.

I don't understand why vidia scrapped ECC (Error Correction Code). ECC for on-chip memory takes under 5% of total chip area since only a fraction of GPU chip area is memory. Giving programmers the option to use ECC for DRAM (in exchange for DRAM space) costs next to nothing in GPU chip area. If the Quadro cards based on Kepler don't have ECC, I think Nvidia made a big mistake. Intel's MIC has ECC.