中文第一计算机图形学社区OpenGPU 版权所有2007-2018

 找回密码
 注册

扫一扫,访问微社区

搜索
查看: 17012|回复: 31

大家对Fermi ISA的汇编器/微构架感兴趣吗?

[复制链接]
发表于 2011-9-19 11:16:31 | 显示全部楼层 |阅读模式
本帖最后由 nooron 于 2011-9-19 11:15 编辑

hi大家好

我是新来这个地方的。早段时间做了一个Fermi ISA的汇编器,asfermi。版主maxiaohan建议我专门发个帖子来讨论讨论,或者开个子论坛什么的。因为我担心大家的兴趣不够,所以先过来问一问大家的意见。

先介绍一下asfermi吧:
Google Code网址:code.google.com/p/asfermi (页面都是英文的)
  • Fermi是NVIDIA当前的构架,asfermi是一个Fermi指令集的汇编器。
  • asfermi目前支持70个Fermi ISA的指令(Fermi ISA总共大约有150~160个指令),各个指令的opcode都有被详细的记录在wiki里面,想自己做code generation的人可以参考。
  • 输出方面,asfermi支持32位和64位的cubin。在使用的时候,cubin里面的kernel可以用driver api来调用。
  • 源代码方面,asfermi使用cuobjdump(NVIDIA提供的反汇编器)的输出的格式,配合一些以感叹号开头的指令来声明kernel, 参数,shared mem size,constant memory object等等。


这个汇编器是为gpgpu做的,所以目前还不支持任何texture和surface memory/video的指令。目前这70个支持的指令在大多数情况下应该都已经够用了。需要用图形指令的朋友可以自己去把各个图形指令的opcode挖出来(asfermi下有一个cubin editor,我就用这个把那70个指令的opcode给挖出来的)。

微构架
当然,不知道微构架的细节而去写汇编大约和浪费时间是差不多的,所以有了汇编器之后,还需要对Fermi的微构架进行大量的microbenchmarking(微基准?很奇怪的翻译。。),获取足够的微构架信息,然后才可以有效地进行汇编编程。一些我肯定需要测量的东西列在了这个页面(各位麻烦自己看一下吧,那些东西要我翻译起来实在头疼)。实际做起来要测量的东西肯定比列出来的要多。早段时间我还有时间的时候已经开始了第一步的微基准,初步的结果在这里。不过自那之后就再也没有时间了,而且我要到今年十二月以后才会再次有时间去继续做微基准。

做asfermi的原因:优化。有了足够的微构架信息的话,设计算法和执行(implementation)的时候可以得到很大的帮助。在不改变算法的情况下,PathScale的工程师一般可以做出10%到30%的速度提升(PathScale有他们自己的汇编器,有足够的微构架信息,但都是不公开的,相比之下,asfermi的所有东西全, 从ISA opcode到微构架信息,都是公开的)。不过,对于那些不能够很好的执行在GPU上的算法来说,针对微构架的汇编编程应该可以提供更大的速度提升。目前GPU上最快的radix sort大约可以做到800 million 32-bit values/s,我早段时间算来算去,认为针对微构架的implementation应该可以把速度提升到1.5~3 billion values/s。当然啦,不同的算法肯定是有不同的改进空间的,不过10%到3x的速度提升,在某些应用中,是值得付出一些努力的。这是我的目的,我只管软件。弄硬件的人或许会对register file, cache还有scheduler的细节,比如说硬件的scheduling算法,感兴趣。这些东西最终都是需要被测量出来的。

GPU汇编编程很麻烦,因为有很多寄存器(0~62)要管。asfermi提供了一个小窍门可以简化这一点。不过将来(明年)我会把asfermi做成一个low-level compiler,支持一些基本的C的语法,支持寄存器分配(register allocation),并且支持自动的指令重新排序(instruction reordering),所以到时候FERMI的低级编程应该可以被简化很多。




好了,介绍了一大堆,该回到刚开始的问题了:这个论坛有多少人会对这样一个GPU汇编器和微构架感兴趣呢?大家想进行微构架和Fermi/Kepler/Souther Island/MIC的汇编编程讨论吗?(明年等这三个新构架都出来之后,我会选我认为最有前景的一个再做一个汇编器,如果相应的汇编器不存在的话)

最后,感谢大家的阅读!
多选投票: ( 最多可选 2 项 ), 共有 55 人参与投票
7.94% (5)
1.59% (1)
60.32% (38)
22.22% (14)
7.94% (5)
您所在的用户组没有投票权限

评分

3

查看全部评分

发表于 2011-9-19 13:41:34 | 显示全部楼层
大牛专业。

我对GPU的工具链不了解,弱弱地问个ABC问题。是说NV官方不提供汇编器,所以需要自己写一个吗?



回复

使用道具 举报

 楼主| 发表于 2011-9-19 15:01:11 | 显示全部楼层
cqq 发表于 2011-9-19 13:41
大牛专业。

我对GPU的工具链不了解,弱弱地问个ABC问题。是说NV官方不提供汇编器,所以需要自己写一个吗? ...

就是这样的,NV为了可移植性只提供PTX的汇编器,而不提供native ISA 的汇编器
回复

使用道具 举报

头像被屏蔽
发表于 2011-9-19 21:14:20 | 显示全部楼层
提示: 作者被禁止或删除 内容自动屏蔽
回复

使用道具 举报

发表于 2011-9-19 22:15:30 | 显示全部楼层
binary的格式是哪里知道的?
回复

使用道具 举报

 楼主| 发表于 2011-9-20 02:19:51 | 显示全部楼层
zenny_chen 发表于 2011-9-19 21:14
呵呵,关注中~~
目前GPU的微架构的详细资料很难找,不像CPU那种。如果有足够详细的GPU架构信息的话,即便 ...

对呀!就是这样呀!
回复

使用道具 举报

 楼主| 发表于 2011-9-20 02:22:20 | 显示全部楼层
queeten 发表于 2011-9-19 22:15
binary的格式是哪里知道的?

cubin就是elf file。至于ISA,当然是反复对比挖出来的了。NVIDIA的cubin做的不怎么标准,但也没什么问题。不过cubin里面的一些细节我倒是忘记记载在wiki里面了。。。也许某天。。。嗯
回复

使用道具 举报

发表于 2011-9-22 03:53:04 | 显示全部楼层
nooron 发表于 2011-9-20 02:22
cubin就是elf file。至于ISA,当然是反复对比挖出来的了。NVIDIA的cubin做的不怎么标准,但也没什么问题 ...

大牛写得真好。我看了下测试结果,问两个肤浅问题:

>> Even-numbered warps are often 1 step slower than odd-numbered warps.

这个1 step不是指1 cycle吧?根据你的结果,SM好像是一次issue奇偶两个warp指令?

另,S2R读出来的Clock cycle值,是Reg File read时候的cycle?不是issue or fetch时候的cycle值?
回复

使用道具 举报

发表于 2011-9-22 10:27:32 | 显示全部楼层
最大的问题就是每代的ISA都会有很大的变化
回复

使用道具 举报

发表于 2011-9-22 10:31:32 | 显示全部楼层
draziwest 发表于 2011-9-22 10:27
最大的问题就是每代的ISA都会有很大的变化

嗯,ISA确实一直有一定的变化。下一步楼主可以考虑做Kepler ISA assembler了。
回复

使用道具 举报

发表于 2011-9-22 11:10:40 | 显示全部楼层
Kepler还要等会呢,考虑现阶段的Fermi用户群意义也挺大的

话说NVIDIA自己不觉得麻烦么如果每代ISA都大改的话。下一代不至于这一代完全不一样吧
回复

使用道具 举报

 楼主| 发表于 2011-9-22 19:37:30 | 显示全部楼层
maxiaohan 发表于 2011-9-22 03:53
大牛写得真好。我看了下测试结果,问两个肤浅问题:

>> Even-numbered warps are often 1 step slower t ...

对,就是一个cycle。一个SM有两个scheduler,所以一次当然issue两个指令,一个给某个奇数warp,另一个给某个偶数warp

至于S2R R*, SR_Clock**的结果。。。你仔细算一下就会发现,除非NV的implementation有bug,不然在哪个stage读出来的值真的对其他东西没有任何影响,也就无法测量。如果NV的执行正确的话,应该是在issue之后的某个stage。
回复

使用道具 举报

 楼主| 发表于 2011-9-22 19:47:27 | 显示全部楼层
draziwest 发表于 2011-9-22 10:27
最大的问题就是每代的ISA都会有很大的变化

只要NV继续提供cuobjdump就没问题。我平均下来1个小时可以破译1到2个指令的样子,整个指令集(160~170个指令)也只需要一百多个小时。如果有三四个人一起做的话一个礼拜就可以全部完成破译。若是没有cuobjdump的话,破解整个指令集应该就是不可能的了。ptxas做得太乱了,让逆向工程几乎不太可能取得太多结果,因此只能用differential analysis。

AMD对Southern Island的构架似乎比以往更为公开。我估计下次他们toolkit升级的时候有可能会把汇编器的支持重新加进去。希望NV也会遵循一条类似的路线。

评分

1

查看全部评分

回复

使用道具 举报

发表于 2011-9-22 23:07:12 | 显示全部楼层
nooron 发表于 2011-9-22 19:37
对,就是一个cycle。一个SM有两个scheduler,所以一次当然issue两个指令,一个给某个奇数warp,另一个给 ...

就是说s2r读出来的cycle值是issue之后某个stage的cycle值?不是issue当时的cycle值?

不过你说的对,应该没有影响。
回复

使用道具 举报

发表于 2011-9-22 23:11:43 | 显示全部楼层
nooron 发表于 2011-9-22 19:47
只要NV继续提供cuobjdump就没问题。我平均下来1个小时可以破译1到2个指令的样子,整个指令集(160~170个 ...

amd一直提供汇编器吧?
回复

使用道具 举报

 楼主| 发表于 2011-9-22 23:54:46 | 显示全部楼层
maxiaohan 发表于 2011-9-22 23:11
amd一直提供汇编器吧?

我不确定哎,听说是在Evergreen之后的ISA支持就drop掉了。
回复

使用道具 举报

发表于 2011-9-23 02:55:26 | 显示全部楼层
nooron 发表于 2011-9-22 23:54
我不确定哎,听说是在Evergreen之后的ISA支持就drop掉了。

amd shader analyzer可以制定target为Cayman的;并且全面支持vliw4。
回复

使用道具 举报

发表于 2011-9-23 07:08:52 | 显示全部楼层
nooron 发表于 2011-9-22 19:47
只要NV继续提供cuobjdump就没问题。我平均下来1个小时可以破译1到2个指令的样子,整个指令集(160~170个 ...

不仅仅如此。还需要大量的microbenchmark得到如何schedule指令可以达到最佳的performance。当然可能很多信息应该可以从cuobjdump的结果猜出来。
回复

使用道具 举报

发表于 2011-9-23 17:04:43 | 显示全部楼层
本帖最后由 draziwest 于 2011-9-23 17:05 编辑

>目前GPU上最快的radix sort大约可以做到800 million 32-bit values/s,
>我早段时间算来算去,认为针对微构架的implementation应该可以把速度提升到1.5~3 billion values/s。
对这个很感兴趣,楼主能详细说说吗?最快的radix sort的代码用的哪个实现?理论值怎么算出来的?在什么chip上测的?
回复

使用道具 举报

 楼主| 发表于 2011-9-25 04:01:06 | 显示全部楼层
draziwest 发表于 2011-9-23 17:04
>目前GPU上最快的radix sort大约可以做到800 million 32-bit values/s,
>我早段时间算来算去,认为针对微 ...

关于最快的执行的代码,请见moderngpu.com和http://code.google.com/p/back40computing/wiki/RadixSorting(相应的source页面)

理论值纯粹是估计的。其实也不是很理论,不过因为我计划的执行和常规的执行不太一样,所以一下子也解释不清楚。你有兴趣自己做一个radix sort implementation吗?
回复

使用道具 举报

发表于 2011-9-25 06:36:53 | 显示全部楼层
nooron 发表于 2011-9-25 04:01
关于最快的执行的代码,请见moderngpu.com和http://code.google.com/p/back40computing/wiki/RadixSortin ...

我想研究下为啥实际速度和理论速度有这么大差别50%~200%。这个差别不小啊
回复

使用道具 举报

 楼主| 发表于 2011-9-25 13:20:06 | 显示全部楼层
本帖最后由 nooron 于 2011-9-25 13:20 编辑
draziwest 发表于 2011-9-25 06:36
我想研究下为啥实际速度和理论速度有这么大差别50%~200%。这个差别不小啊

我计划的执行不用scan,因此可以用更少的pass来实现(4 passes for 32-bit integers)。不过因为依靠shared mem atomics,所以我又看了一下。。。Fermi应该很难做到我预想的速度了,因为,根据我最近看到另外一个benchmark的结果,Fermi的shared mem atomics throughput 非常非常低,GTX470的竟然是HD5870的十二分之一。

相比之下,HD5870的shared mem atomics throughput相当令人满意,所以这种不用scan的implementation应该比较适合AMD的卡。。。

不过,我还是觉得1.5G values/sec(在GTX 580上,每个value在每个pass可以用130个cycle来处理)还是可以做到的,只是我需要在shared memory上执行一种特殊的atomic mechanism。
回复

使用道具 举报

发表于 2011-12-7 18:55:02 | 显示全部楼层
为ISA造一个LLVM的后端吧。

评分

1

查看全部评分

回复

使用道具 举报

发表于 2011-12-16 00:53:48 | 显示全部楼层
不知道lz现在的进度如何?还在继续做吗?

真希望论坛上有更多人参与、帮助这个工作。
回复

使用道具 举报

发表于 2012-1-10 12:29:03 | 显示全部楼层
nooron 发表于 2011-9-25 13:20
我计划的执行不用scan,因此可以用更少的pass来实现(4 passes for 32-bit integers)。不过因为依靠share ...

这个算法我们这边有人研究过,就算法本身而言,scan部分的shared memory访问并非处于最优状态,通过heavy thread即一个线程计算多个输入输出可以有效的减少算法的shared memory访问。

有兴趣可以找找这篇论文:Stencil Computation Optimization and Auto-tuning
on State-of-the-Art Multicore Architectures

里面提到的register blocking是非常经典的的优化技术,对scan/up-sweep/down-sweep算法也是适用的。
回复

使用道具 举报

发表于 2012-2-24 00:03:15 | 显示全部楼层
支持lz的工作
回复

使用道具 举报

发表于 2012-3-21 22:06:39 | 显示全部楼层
做从ARB到具体芯片ISA的分析,不知做的人多不多?
回复

使用道具 举报

发表于 2012-7-16 10:13:47 | 显示全部楼层
编写汇编器,不懂。有兴趣,有没有入门资料?
回复

使用道具 举报

发表于 2012-9-27 12:57:37 | 显示全部楼层
求科普,只会用cuda ptx都没看懂的人飘过
回复

使用道具 举报

发表于 2012-11-6 00:50:44 | 显示全部楼层
楼主进行到何种地步了?这种汇编器难的是优化吧
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

关于我们|小黑屋|Archiver|手机版|中文第一计算机图形学社区OpenGPU

GMT+8, 2018-2-26 03:20 , Processed in 0.105090 second(s), 22 queries .

Powered by Discuz! X3.4

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表