Skip to content
这几年Intel和AMD都推出了集成GPU的消费级CPU,并强调它们的内存是共享的架构,也就是UMA(Unified Memory Architeture)。最近AMD和NVIDIA的独立显卡也加入战团,开始逐步支持UMA。最新的D3D12直接内置了UMA的支持,开发者可以让自己的程序充分利用上UMA所带来的优势。那么UMA能带来什么好处?它的限制在哪里? 各种平台的状况 自从PC上第一块GPU,NVIDIA Geforce 256问世以来,GPU一直都是自带一块显存的。当年的AGP总线是非对称的设计,数据传到GPU要远快于从GPU读回。CPU和GPU的访存是完全分开的。后来的PCIE总线让两端传输的速度相等了,并提供了一些相互访问的能力。在驱动里,system memory的区域可以映射成可以被GPU访问的,反过来 ...
在游戏引擎里,每一帧都可能有UI和文字的渲染。这些东西的特点是,琐碎,随机,但每一部分的数据量很小。比如UI由很多矩形块组成,每个只有4个顶点。这样的数据对GPU来说是很头疼的。所以引擎往往需要在Buffer上做一些工作来改善渲染的性能。 由于在目前常见的架构上,CPU和GPU不能同时读写一块内存,CPU在写入数据的时候GPU只能读取另一个地方来渲染。所以一定需要某个机制,来避免这样的冲突。 常见方法1:Discard 最古老的一个做法就是,自己维护一块内存,每一次需要画东西的时候先放在那块内存中。每一帧用一次discard的方式对GPU buffer做一次map,把数据拷贝进去。这么做很简单,所有复杂的同步都交给驱动去完成。 在内部,di ...
自从去年GDC释出了一些消息以来,D3D12 SDK终于在上个月底随着VS2015RC公开了。除了API的更新,D3D12还包含了一个称为11on12的库,让移植前所未有的快捷。目前KlayGE的D3D12插件正在开发中,本系列文章将会把一些方法和经验总结出来。简单起见,后续的代码省略了错误检查等细节。同时,阅读本系列的前提是对D3D11有基本的了解。 D3D移植的过去 纵观D3D的历史,几乎每个版本都是从新开发,和旧版本没有接口上的继承关系。也就是说,和一般COM组件的概念不同,不能从新版本的接口QueryInterface出老版本的接口。结果就是,每次需要移植到新的D3D版本,都会需要拷贝代码、修改代码,甚至重写。在整个渲染部分都换到新API之前,系统完全无法工 ...
Singleton是一个非常常用的设计模式。几乎所有稍大的程序都会用到它。所以构建一个线程安全,并且高效的singleton很重要。既然要讨论这个主题,我们就先来定义一下我们的需求: Lazy initialization。只有在第一次使用的时候才需要初始化出一个singleton对象。这使得程序不需要考虑过多顺序耦合的情况。同时也避免了启动时初始化太多不知道什么时候才会用到的东西。 线程安全。多个线程有可能同时调用singleton。如果只需要单线程,那实在没什么需要讨论的。 高效。因为singleton会被反复调用,如果效率低的话浪费太大了。 通用。适合现有的各种平台,以及未来可能出现的平台。 有了这些需求,我们就可以开始讨论如何构造这么一 ...
上个月底,KlayGE已经基本完成了迁移git的任务。这个过程不是一个简单的镜像,而是在导入git的过程中,删除大文件、依赖库等,并可以通过cmake下载、解压和打补丁。对开发者来说,流程上没有什么变化,都是自动完成的。 对于第三方库,之前的做法是从原网站下载发行版代码包,从klayge.org下载补丁,用python patch打上补丁之后使用。对于有些下载速度特别慢的包,比如wpftoolkit,我也放到了klayge.org。同时,KlayGE所要的资源文件也都在klayge.org。这么以来,最近klayge.org的流量激增,本来速度就一般,现在响应更慢了。 第二个缺点是浪费。比如boost,下载包56M,解压后400M,删掉不用的文件,剩下36M我们需要的。这样对带宽和构 ...
KlayGE在2012年就启用了C++11的部分功能。但目前为止所有用到的C++11特性都要求有一个对应的C++98替代品。要么自己实现,要么用Boost的。 随着时间的推移,各个编译器对C++11的支持越来越好。KlayGE支持的所有平台上,都已经有可用的C++11编译器。实际上如果用的编译器是g++或者clang,-std=c++11都是打开的。所以其实只有Windows上的vc9/10还不能很好地支持C++11。 因为vc9已经无法编译boost,留着没啥意义。对于g++ 4.3之前的版本,或者clang 3.0之前的版本,也没什么人用,也没必要留着。这样在KlayGE支持的编译器中,不支持C++11的就剩下vc10。但至少这样就能直接使用vc10所支持的C++11特性。 所以我的计划是,在目前的开发版本 ...
经过越来越多的测试,在Windows上DXBC2GLSL已经可以取代Cg成为主要的shader编译工具了。由于DXBC2GLSL需要用d3dcompiler把HLSL编译成DXBC,在非Windows上,原先就只能仍然使用Cg来做HLSL到GLSL的转换。 后Cg时代 且不说Cg那差的要死的GLSL支持度,不久前NVIDIA宣布停止Cg的开发和维护,继续用Cg肯定不是个办法。那么在非Windows上编译HLSL就有几个选择: 开发一个自己的跨平台HLSL编译器。 用wine的HLSL编译器。 用wine载入d3dcompiler。 UE4用了第一个选择,但它需要花费的时间精力实在太大了,对于KlayGE来说不合算。第二个选择按说是最佳方法。Wine致力于实现可以在Linux上执行Windows原生程序的抽象层,其中包含了d3dcompil ...
从今天开始,KlayGE的源代码已经可以通过git来访问了。以后的更新也会都通过git进行,旧的hg访问会逐步删除。整个迁移的过程还算比较顺利的。最终经过精简的git库有90M左右,比原先需要下载576.8M的hg库小得多了,虽然精简过的hg库才16M。 新的地址 新的git地址可以在这里找到。国内访问github的速度应该会高于sourceforge或者bitbucket。 转移过程中遇到的问题 上一篇文章里记录了精简hg的方法。精简过的hg可以用TortoiseHg内置的hg-git转成git库。和从hg导入git的方法和坑的实验不一样的是,现在的hg-git可以直接在命令行下推到一个bare库,不需要经过bash。所以这个过程可以直接用一个bat搞定。 尚未解决的问题 目前把新的库推到了g ...
前不久提过关于迁移到git的想法,是时候做一个详细的计划了。为此,我专门在github上启动了一个KlayGE2Git的项目,用于存放迁移过程中需要的脚本。希望对其他也有类似计划的朋友能有所帮助。 需要完成的事情 最终选择的迁移方案是方案4:单一repository,下载外部库发行版。所以在迁移的过程中,需要考虑如何减少repository大小,以及考虑迁移之后工作流需要的改变。 删除当前工作目录的大文件 第一步应该是删除当前工作目录的大文件,主要是二进制资源文件。并且需要在cmake里面加上自动下载的脚本,以便在配置工程的时候可以从klayge.org上获取需要的文件。否则后面开发的时候会有问题。这一步已经完成,目前的hg上已经没有资源文件。 ...
上一篇提到了BC7的结构,以及压缩的巨大计算量。本篇将阐述FasTC算法,一种可以快速压缩BC7的方法。 慢的根源 之前讲过,传统BC7压缩之所以慢,是因为需要穷举所有的可能性,从中挑出最好的一种。在这种情况下,最快的实现靠的是GPU的巨大并行度,虽然能解决问题,但效率仍然很低,并依赖于D3D11的CS。 审视BC7的压缩步骤,可以看出首先有64个partition,8个mode,有的mode有2种颜色编码和3种旋转。很显然,占决定性作用的是64个partition。如果能有个算法不需要穷举就能决定一个partition,就能迅速把计算量减少几十倍。 Partition的确定 那么有没有可能直接确定出partition呢?09年刚完成BC6H/BC7 DirectCompute Encoder Tool的时候 ...