Gary M. (gary83@yahoo.com) on 4/6/12 wrote:
---------------------------
>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.

It's not really opposite at all. Conceptually, you can thihnk of hardware vertex or pixel shaders as heterogeneous cores within a single GPU. That's not at all what's happening.

What you see is different cores for different GPU (e.g. different double precision) and also different memory controllers (e.g. ECC support).

In the CPU world, we are used to seeing the same core, but different 'uncore'.

>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?

I'm not saying that it's 'enough', because it's entirely workload dependent. My point is that Nvidia radically reduced the shared data bandwidth, which hurts computational (rather than graphics) workloads. The point is that it's a trade-off in favor of graphics performance away from HPC.

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

That's certainly an element.

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

That's really not the case. You need double precision for many HPC workloads. It's just that the GK104 is meant for graphics, so there's no reason to pay the overhead of doing double precision (ditto for ECC) because there is no performance benefit.

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

Perhaps. Itanium required porting software though. MIC inherits the x86 code base. Admittedly, it is functionally correct and will require work to get good performance, but that's still far better than other GPUs.

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

Because nobody cares about ECC in a consumer graphics part. It's pure overhead.

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

I believe Quadro and Tesla will use the same chip, which will have ECC for SRAMs and DRAM, plus good double precision. However, what I'm saying in this article is that it won't be the same shader cores that are used in GK104. It's exactly like the Fermi generation. GF100 was a different core than GF104. One was meant for workstations and HPC, the other for graphics.

David