Skip to content
Universal DX SDK的第二阶段也完成了。新加了一个批处理文件,用于从系统的.dll生成.lib或者.a。 这个脚本支持vc7-vc14,以及mingw。只要装了这些中的任意一个,执行脚本的时候,它就会从System32或SysWOW64中挑选需要的dll,从中生成vc所有用的导入库lib,或者mingw所用的导入库.a,放到Lib下。如此一来,非动态载入的情况也可以使用Universal DX SDK。 目前我的实验是,在KlayGE里用Universal DX SDK,在VS2013下开发D3D12的东西,包括桌面应用和WinRT应用。目前为止一切正常,程序可以编译链接运行。
前两天刚宣布了一个新的开源项目,Universal DX SDK,现在以完成了第一阶段。 在现在的master分支里,头文件已经被更新到Win10 SDK 10.0.10240.0,并作出一些修改: 注掉了winapifamily.h相关的代码,以适用于VS2010及以前的vc,和MinGW/Clang。 在MinGW下编译不会出现warning。 这么一来,如果用LoadLibrary进行动态载入,只需要头文件的话,在各种编译器下都能使用Universal DX SDK,支持D3D 9-12、DXGI 1.1-1.4、DInput、DSound、D2D 1.1-1.3、DWrite 1.1-1.3、XAudio等,并支持古老的XNAMath、D3DX 9-11等。基本可以满足各种对DX的需求。 经过KlayGE的实验,用了Universal DX SDK之后,大部分根据SDK版本进行的#ifdef都可 ...
从Windows 8开始,DirectX SDK就被合并到Windows SDK里了。June 2010成了最后一次独立发布的DX SDK。大部分情况下,这么做挺方便,VS装好之后就能用了,不再需要单独装DX SDK、设置路径等。但有的时候,这样也会带来些麻烦。 用Windows SDK的不便之处 Visual Studio的用户基本上都使用VS自带的Windows SDK,很少有单独装的。这带来的问题就是,如果VS不升级,SDK就不升级,两者变成一对一的关系了。所以如果你想用VS2012开发D3D11.2,或者VS2013开发D3D12的东西,就没法弄。 另一方面,在Windows上也可以用MinGW和Clang来编译。但它们所带的DX SDK比较古老,而且不全。用June 2010的话,因为sal的关系,编译中会有很多错误。即便绕开了 ...
经过前面的练习,实现query已经没什么难的了。 Query heap 在D3D12里,query也是放在heap中。但和其他heap不同的是,query heap与其说是heap,不如说是array。它并不需要设置给设备,而是相当于一次可以提交多个query。Query heap的数量不限,所以为了简单实现,可以给每个query建立一个query heap。 D3D12_QUERY_HEAP_DESC query_heap_desc; query_heap_desc.Type = D3D12_QUERY_HEAP_TYPE_OCCLUSION; query_heap_desc.Count = 1; query_heap_desc.NodeMask = 0; ID3D12QueryHeap* query_heap; TIF(device->CreateQueryHeap(&query_heap_desc, IID_ID3D12QueryHeap, reinterpret_cast<void**>(&query_heap))); ...
据我上一次写D3D11 feature一晃已经4年了。相信这么多年来大部分开发者不再像当年那样无知了。现在Win10和D3D12已经发布,图形驱动模型也有不少发展。现在在Win10里的图形栈经过了较大规模的重构。虽然在上层很难察觉,但底层已经很不一样。 老的兼容方式 当年D3D9刚出来的时候,大部分显卡和驱动还是D3D8的。当时的兼容方式是,让D3D9的runtime跑在D3D8的驱动上。D3D9和D3D10之间出现了个短暂的断层,互相不兼容。不久之后D3D10.1又可以通过feature level的方式在老显卡上跑。这个东西叫做10level9,意思是10的runtime在9的硬件上。后来出了11,也一直是用这样的方式。 总的来说,老的兼容方式就是,硬件厂商提供一个或多个驱动,runti ...
上一篇把完成了一个最基本的D3D12程序,画一个三角形。同时我也说了,没有回头路。本篇将开始从11on12转向纯D3D12。 上一篇我们的假设假设是最基本的系统,关掉所有post process、UI、文字,就渲染一个三角形。这样的系统至少需要一个vertex buffer、一个rtv、一个vs、一个ps、一次clear、一次draw call。进一步的发展需要一个稍微复杂的系统,有文字和UI。也就是还需要一个index buffer、一个cbv、一个srv、一个sampler。Index buffer和vertex buffer的构建没区别,所以就是cbv、srv和sampler的事情。 在此之前,需要先介绍两个D3D12的概念,heap和root signature。因为CBV/SRV/UAV/Sampler都需要依赖于这两个。 Heap Heap是D3D12新 ...
从八月初开始正式做D3D12插件以来,经过5个星期、每天平均一小时的开发,终于达成了第一阶段的目标:在渲染层接口不变的情况下,用纯D3D12渲染所有例子。 其实还不是所有特性都实现了。在例子中,遇到这种情况会退回到另一条code path。原先这些code path是为了在较弱的硬件上也能达到同样的效果,同样也可以用于开发新插件的中间产品。还没实现的特性有: Stream output(退回到render to texture) Compute shader(退回到用pixel shader实现) UAVs No overwrite(退回到discard) Query(总是返回0) Indirect draw Depth stencil和压缩纹理的mipmap生成(退回到在CPU上生成) 下一个阶段会进一步实现这些特性,做 ...
上一篇把资源转成了用12的设备建立,下一步有点犯难了。 让我们做一个假设。要让一个最基本的系统能渲染起来,换句话说,关掉所有post process、UI、文字,就渲染一个三角形。至少需要一个vertex buffer、一个rtv、一个vs、一个ps、一次clear、一次draw call。Vertex buffer的问题已经解决;vs和ps本身和11的一样;clear和11的几乎一样,只要改成调用graphics command list上的函数即可;draw call也是。好了,那么问题就集中在 如何使用rtv; 如何组装起来渲染 但无论如何,这都是不归路。我们只能向前走,再也没法像前面那样,用11on12来让两者交互使用。 RTV D3D12里的RTV是放在一个heap里的,使用的时候把heap里的一个hand ...
上一篇我们讲了如何建立D3D12的设备,并在其之上建立出11on12的设备。接下去就要开始一步一步转移到纯D3D12下了。 第一个应该转的是相对独立的资源,包括buffer和texture。建立D3D12的资源,之后用前文说的CreateWrappedResource转成D3D11的资源,继续交给D3D11on12渲染就可以了。这样仍然可以往前走一小步,保证引擎还能工作。 Buffer Buffer包括vertex buffer、index buffer和constant buffer。 D3D12_HEAP_PROPERTIES heap_prop; heap_prop.Type = D3D12_HEAP_TYPE_UPLOAD; heap_prop.CPUPageProperty = D3D12_CPU_PAGE_PROPERTY_UNKNOWN; heap_prop.MemoryPoolPreference = D3D12_MEMORY_POOL_UNKNOWN; heap_prop.CreationNode ...
昨天晚上,sourceforge的宕机时间刚恢复,我就打算把新的develop和master分支推上去。笔记本上的本地git库是一个改动中的,和github等上的历史结构有些不同了。结果我不小心用了强制push,于是现在github、bitbucket、sourceforge、codeplex上的git库全都被更改了。 7月8号以来pull或者fetch过develop或者master分支的用户,会受到影响。需要用Reset develop/master to this的功能reset到“KlayGE: Rendering: Fix the black screen in WinRT. (ticket #295)”这个commit,SHA-1是1217bcff860130d6d187925cdf342fb0ea11ab96。如果在原有分支上有个修改的,需要同时cherry pick到新的分支上来。 对这个push事故,我深表歉意。给大家制造麻 ...