NVIDIA 下一代架构"Fermi" 猜测、讨论专题

Edison

摩尔定律是“集成电路上可容纳的晶体管数目，约每隔两年便会增加一倍，性能也将提升一倍，当价格不变时；或者说，每一美元所能买到的电脑性能，将每隔两年翻两倍以上。”

事实上 gt200 的芯片尺寸为 58x.x mm^2 是因为受到 TSMC 遮罩的限制，如果 TSMC 有更大的遮罩容许度，gt200 没准会做到 6xxmm^2，PCIE 供电接近 300w 的上限。

换句话说，即使 NVIDIA 想做的更大，也有各种物理因素约束着他。

ic.expert

主要还是yield的问题吧。一个DIE做的Area越大，光刻和金属沉淀时候的缺陷存在的可能性就越大。所以听说当年ST认为龙芯3的面积太大了，这种良率是没有办法量产的。当年NV30也有这个问题。所以集成电路在进入90NM以后才会有专门的DFM工具出来，以保证可制造性设计。不过以GPU的编程模型来说，Multi-chip还是很容易的一件事情~ 我们提倡某种水产计算，只要有效率，是几个核心，那都不重要：〉

Edison

完全没有这个迹象吧，获得 x86 也没啥实际的好处可言。

xddxdd

学习了，非常感谢

ccw2236

看看就好， 显卡升级太快了。。。。。

Edison

刚刚到 NVIVIDA 的网站逛了一下，一不留神发现今天发布了 CUDA 优化指南 2.3 版，简单看了一下，感觉非常不错，应该说对 CUDA 2.X 以来的各种优化策略有了系统性、细节化的总结。

http://developer.download.nvidia ... cticesGuide_2.3.pdf

Edison

我觉得大芯片的策略不会有什么大的变动，关键是大芯片的性能是否能对得起它的 size。

tyro

大芯片策略我想是肯定的了，因为在系统结构上的优化很难有更巨大的突破，唯一突破的是在晶体管规模上下“工夫”。如果用一个参数 （ 性能/晶体管数）  来表示系统结构的优化程度话，这个数值可能达到瓶颈，而且随着晶体管数规模的增加，性能/晶体管数 这个数值我想更难保持。

Edison

http://www.tml.tkk.fi/~timo/publications/aila2009hpg_paper.pdf

这篇论文是 NVIDIA 将在下月的 HPG 2009 上发布的论文，题目为 Understanding the Efficiency of Ray Traversal on GPUs。

根据这篇论文，NVIDIA 的两位研究员认为影响 Ray Traversal 效率的并非内存子系统，而是 hardware work distribution 难以辨明的低效率，有鉴于此，他们提供了一个简单的解决方案显著地缩减了理论模拟与实际测试的性能差距，从而达成迄今为止最快的 GPU Ray Tracer。

以下是结尾部分：

We have shown that the performance of fastest GPU trace() kernels
can be improved significantly by relying on persistent threads instead
of the hardware work distribution mechanisms. The resulting
level of performance is encouraging, and most importantly the less
coherent ray loads are not much slower than primary rays. It seems
likely that other tasks that have heterogeneous workloads would
benefit from a similar solution.

In additional tests we noticed that in these relatively simple scenes
the performance of our fastest speculative kernel remains around
20–40Mrays/sec even with randomly shuffled global illumination
rays. These ray loads are much less coherent than one could expect
from path tracing, for example, so it seems certain that we would be
able to sustain at least that level of performance in unbiased global
illumination computations.

We have also shown that, contrary to conventional wisdom, ray
tracing performance of GTX285 is not significantly hampered by
the lack of cache hierarchy. In fact, we can also expect good scaling
to more complex scenes as a result of not relying on caches.
However, we do see the first signs of memory-related effects in the
fastest speculative while-while kernel in diffuse interreflection rays.
In these cases a large cache could help.

Additional simulations suggest that a 16-wide machine with identical
computational power could be about 6–19% faster than 32-
wide in these scenes, assuming infinitely fast memory. The difference
was smallest in primary rays and largest in diffuse, and
it also depended on the algorithm (min/average/max (%)): whilewhile
(9/14/19), speculative while-while (6/10/15), if-if (8/10/13),
speculative if-if (6/8/12). This suggests that speculative traversal is
increasingly useful on wider machines. Theoretically a scalar machine
with identical computational power could be about 30% (primary)
to 144% (diffuse) faster than 32-wide SIMD with the used
data structures, again assuming infinitely fast memory.

八角差开

GPU发展的核心说白了就是个算法的改进/优化，都是数学模型！！硬件设计也仅是配合这种算法计算模式，尽可能快的解出相关的方程。不是一般人玩的……

lik

理论上说if-conversion 利用predicate是可以把任何Control Dependency转化为Data Dependency的, 不过要真那么做代码要膨胀成什到地步? 最多也就是做些hyperblock吧.

CAM entry的数量也就是决定了issue window或者reservation station的大小(取决于你的OOO实现方式). 这个只是性能的一个方面.

Prefetch的出现是是为了应付memory wall(Memory速度的增长赶不上processor core的速度增长)的一种方式. 算是个trick, 不是什么本质性的architectural revolution.

我懂得不多, 不好意思.

所有的Control Dependency都是能转化为Data Dependency的，Branch也是如此，都可以通过HW或是SW来解决。如果HW要支持，则必须动用CAM，而CAM上 Entry的数量决定了一切。实际上着相当于一个Dataflow Machine，主要原理 ...
ic.expert 发表于 2009-6-9 19:44

Edison

今天在 NVIDIA CUDA bbs 上看到了一个关于指令吞吐率的测试话题，感觉还是比较有意思的。

以下是这个话题中的 mvgalen 背着他的导师偷偷发布的测试结果：

samsung

Specified=G300 ?

八角差开

若specified＝G300，MS单位计算性能提升不大，有些还慢了……只能堆规格了

Edison

我想这个应该只是指 CUDA guide 里的纸面规格:p。

Edison

在 CUDA Program Guid 2.3 中一些对未来架构信息上的泄漏。

Chapter 3. Programming Interface

"Any application that wants to run on future device architectures must load PTX, not binary code. This is because binary code is architecture-specific and therefore incompatible with future architectures, whereas PTX code is compiled to binary code at load time by the driver."


Chapter 5. Performance Guidelines

"Integer Arithmetic
Throughput of integer add is 8 operations per clock cycle.

Throughput of 32-bit integer multiplication is 2 operations per clock cycle, but __mul24 and __umul24 (see Section C.2) provide signed and unsigned 24-bit integer multiplication with a troughput of 8 operations per clock cycle. On future architectures however,__mul24 will be slower than 32-bit integer multiplication, so we recommend to provide two kernels, one using __mul24 and the other using generic 32-bit integer multiplication, to be called appropriately by the application."


Chapter 5. Performance Guidelines

"Constant Memory

The constant memory space is cached so a read from constant memory costs one memory read from device memory only on a cache miss, otherwise it just costs one read from the constant cache.

For all threads of a half-warp, reading from the constant cache is as fast as reading from a register as long as all threads read the same address. The cost scales linearly with the number of different addresses read by all threads. We recommend having all threads of the entire warp read the same address as opposed to all threads within each of its halves only, as future devices will require it for full speed read."

"The number of blocks per grid should be at least 100 if one wants it to scale to future devices; 1000 blocks will scale across several generations."