Root Arguments 每次绘制的时候保留快照是为了方便多线程么？ about igp-directx12-chinese

[wconly]

谈谈自己的理解。
这是原文：
“The contents of the root signature (the descriptor tables, root constants and root descriptors) that the application has bound automatically get versioned by the D3D12 driver whenever any part of the contents change between draw (graphics)/dispatch (compute) calls. So each draw/dispatch gets a unique full set of root signature state.”
《Root Signatures Overview》（mt709155）
signature root分为root argument与root parameter，也就说分实参和形参。这里针对的是实参。
其实你上面转的这句话下面还有个例子，根据这个例子也可以看出：在每次绘制过程中，都要先设置（改）绘制所用的描述符，随后再用DrawIndexedInstanced提交绘制命令（注意并不是立即，而仅是提交绘制命令！）。按逻辑来说，每次绘制一定要先设定这次绘制所用的资源，但是每次所用的数据可能并不一样，所以快照就是干这个用的，有点栈帧的意思，应该就是文中所谓的状态了。
最后，win10周年更新版推出了root signature version 1.1。允许用户告知驱动描述符为静态或动态来借此优化程序。

[LinkClinton]

首先感谢你的回答。

关于这个我觉得应该不是，不可能他去保存实参。
理由有两个：
第一个是我尝试过，具体就是绘制100个立方体，如果它能够保留实参的话，那么我们只需要每次绘制后更改常缓冲的值就好了。但是这样做的后果就是100个立方体全部在一起了。如果他会保留实参的话，那么我们这样做是没有问题的。
第二个原因是保留实参的开销太大，一个常缓冲还好，但是是纹理的话那么空间开销太大，毕竟一帧中绘制的物体稍微一多，那么空间就不是能够想像的了。并且如果他去保留的话还需要时间开销去复制数据。

因此我宁愿相信他保存的是我们用了哪些描述符，哪些描述符表，哪些常量，而不是具体的数据。但是如果是顺序执行的话，那么这样的保存从我现在的情况来看感觉毫无意义。
@wconly

[wconly]

你可否在github上提交一份你绘制100个立方体的代码？
另外，请问你使用的SDK和系统具体版本是多少？

[wconly]

另外，如果方便的话，希望你可以编译一份release版，一份debug版一并提交上来（意思就是直接把整个画立方体的工程搬上来，嘿嘿）
谢谢~

[wconly]

仔细看了看对话，发现我可能有误解或表述不明的地方。所以整理一下对这部分的认识。
首先，你也提出了，cmd要记录到cmd list，最后再把cmd list提交到cmd queue执行。
于是我们的工作就是：构造绘制所用资料，向cmd list提交绘制所需的资料（也就是为流水线设置各种状态，准备向流水线提交处理的数据），再提交draw call（让流水线按个阶段的状态处理流经的数据，并给出最终效果，当然这仅是向cmd list提交，并未被cmd queue执行）；继续构造下一个绘制资料，向cmd list提交，再次提交draw call；循环往复……
完事儿后，再将cmd list提交给cmd queue，让它去真正执行绘制命令。
我还是老想法，每一次draw call肯定会有与之对应资源。
但是，我之前的说法是有问题的。
在这一点上，你说的对。各种文章上说的也很明白：root signature定义的是要绑定到流水线上的资源类型。
还是援引上面我发的原文。
不同draw call之间记录的是The contents of the root signature。这个The contents of the root signature括号里说的很明白：the descriptor tables, root constants and root descriptors。而不是数据的快照。
究其原因《Root Signature Version 1.1》（mt709473）有详解。
root signature 1.0允许应用程序端自由修改descriptor heap中的内容与它们所指向的内存！（试想在某次draw call之前，与之相关的descriptor变了……书里那段代码应当是修改了descriptor这一条，这就是我所说的“修改”数据，但是从某种意义上来讲并没有实际“改动”数据，它只是改了指向数据的指针（内存地址），这就是多层抽象的优点了吧。所以它记录其实还是指针而已）
之前也提到过，root signature 1.1则允许用于指定：我确定，在若干次draw call中我不会改descriptor或内存，也就是static（这样它就应该不用傻了吧唧的每个draw call都来个versioned了）。root signature 1.0只能volatile，1.1默认是static。
至于多线程，书里其实基本没有提（主要是策略问题，作者貌似认为这是高级主题），官网上写的很充分。cmd list、cmd queue与bundle模型就是为为此设计的。简单来说，每个cmd list都是独立的（self-contained），并不继承任何状态，也就是不干涉其他cmd list，也不被其他cmd list干扰，各干各的，完美平行执行。
我后来也想了想，你说的其实也对，毕竟这也是保证多线程所涉及的一个因素。
不过我还是希望你能把你画100个立方体的整个程序，包括可执行文件的release和debug版以及编译信息让我看看。

[LinkClinton]

@wconly
这里大家应该都是一个意思，我也同样误解了之前的那句话，我以为你是说的具体的数据。
从你现在说的来看，我们的理解是一致的。

root signature 1.0允许应用程序端自由修改descriptor heap中的内容与它们所指向的内存！（试想在某次draw call之前，与之相关的descriptor变了……书里那段代码应当是修改了descriptor这一条，这就是我所说的“修改”数据，但是从某种意义上来讲并没有实际“改动”数据，它只是改了指向数据的指针（内存地址），这就是多层抽象的优点了吧。所以它记录其实还是指针而已）

这一段话不是很理解，描述符准确来说和指针的性质是很类似的(他也的确记录了GPU虚拟地址,GPU_VIRTUAL_ADDRESS)。那么我们的程序也只是告诉Direct3D我们绘制前要使用的资源，那么具体来说要使用的资源都是我们自己来决定的，那么在顺序执行的情况下，完全没有必要版本化。

那么改动描述符具体来说是做什么? 是将一个描述符的GPU虚拟地址改变这样的修改？(应该是的吧)但是我觉得对这样做的目的不是很能够理解。《Root Signature Version 1.1》待会我会去看看(晚自习QAQ)。是官网的那个么？如果不是最好能够给个链接。

[LinkClinton]

@wconly

关于那100个立方体的代码其实就在Github上: Link。

里面的HelloCollider就是了，但是如果你要编译的话，配置起来倒是有点麻烦。
因为主要目的是测试碰撞盒的，所以使用了自己写的DX12框架等等东西，如果要编译的话注意看request。(配置起来应该比C++简单)

并且由于是比较久远的情况，问题其实早就解决了。其实就是原本是只使用一个常缓冲来作为记录变换矩阵的缓冲，但是这样的话，在绘制多个物体的时候，他们用到的都是同一个常缓冲，因此100立方体其实用的都是最后一次绘制的时候的变换矩阵。

[wconly]

《Root Signature Version 1.1》（mt709473）
原文：
Root Signature version 1.0 allows the contents of descriptor heaps and the memory they point at to be freely changed by applications any time that command lists / bundles referencing them are potentially in flight on the GPU. Very often, however, applications don’t actually need the flexibility to change descriptors or memory after commands that reference them have been recorded.

[wconly]

其实我需要你的那个程序是为了验证root signature 1.1与1.1兼容的情况。
我的Windows 10版本低，官方称1.1在之前的系统版本中是运行不了的。
上面那篇文章详细讲解1.1与1.0的区别，看完了我自认为关键的部分，我认为做versioned就是为了避免在draw call之前被GPU之前，修改与之有关的引用的descriptor等等。这是首要的任务，因为如果descriptor变了，那么draw call的结果肯定有问题，我认为关键在那个changed 上，这应该是为了程序的灵活度。但是发现有可优化空间，所以才又引入了1.1。

[LinkClinton]

我应该能够理解上面所说的。

你所说的问题是指在我们还在构建CommandList的时候，我们将原本一个在前面的绘制(我们称这个指令为Draw1)中用过的描述符的内容修改了，那么在最后执行指令的时候，就导致Draw1使用的资源并不是我们期待的那个，而是我们修改的那个。对吧？

我不理解的就是感觉完全可以避免这样的情况(属于可优化空间的部分么？)。
我们分情况讨论：
第一种是root descriptor，那么我们完全没必要去修改一个descriptor，完全可以重新创建一个descriptor。
第二种是descriptor table，这里其实应该是我觉得最需要纠结的，按照文章说的，我们可以改变堆中的描述符所指向的GPU虚拟地址(很好奇怎么做的，没有看到相关的API能够改变)，那么为什么不直接用一个新堆，反而需要让驱动来管理这个。
第三种就是root constant，这个应该不需要讨论吧。

总的来说想法就是始终保持一个描述符对应一个资源，这样做的话会有什么缺点么？

刚刚看了root signature 1.1的介绍，他的确是说因为基本上不需要改变所以在1.1中支持了静态。
however, applications don’t actually need the flexibility to change descriptors or memory after commands that reference them have been recorded.
感觉内心惆怅。

其实我需要你的那个程序是为了验证root signature 1.1与1.1兼容的情况。一脸懵逼，没看懂，如果你只是需要那个程序的exe的话我可以发给你。

对此感谢你的回答。

Ps: 其实刚开始我主要YY版本化的目的其实是在纠结有没有可能同时执行两个绘制指令，毕竟有时候一个绘制指令可能无法完全利用GPU的性能。不过后来想了想感觉很难做到管理，就考虑多线程的想法了。

[wconly]

话题关了？
不是还没有讨论完吗？
我不能每天上网……

[LinkClinton]

看你那么久没回(以为你也觉得没必要再讨论了)以及只是关于Root Arguments的疑问确实得到了解决。
所以就关了....

其实我需要你的那个程序是为了验证root signature 1.1与1.1兼容的情况。一脸懵逼，没看懂，如果你只是需要那个程序的exe的话我可以发给你。

不能天天上网好惨!!!

[wconly]

还是谈谈自己的理解
首先，GPU执行的是cmd list，看原文，command lists / bundles referencing them，关键点就在这个referencing上，既然是referencing，那么内容就是可修改的，也就是cmd list是可修改的（废话……其实这个意思是，这边GPU在referencing cmd list，而CPU那边就可以同时change它，你也提到了。本来DX11有两种绘制方法，一种是immediate rendering，另一种是deferred rendering，顾名思义，第一种直接绘制，命令丢到queue里，立马GPU就执行了。而DX12为了效率原因只保留了第二种）。
root signature 1.1其实也给出了解释，只不过这个解释咱们可能还没用到……啊……没用到……
In other words, an application may wish to perform execution on the GPU timeline that updates some data in between time periods where it is set via a root parameter, knowing that when it is set it will be static.
其实这里说的是some data，我想也就是只能是那些矩阵什么的了吧……
但是他们一拍脑袋，发现效率降低，而且这么干的人实在也不多（就是你说的那样……），就在1.1里强行static了……
下面我们再挪步，《Using a Root Signature》（dn903950），里面有这么一段话：
The application can change part of the root signature bindings at a time (the rest remain unchanged). For example, if the only thing that needs to change between draws is one of the constants at slot [2], that is all the application needs to rebind. As discussed previously, the driver/hardware versions all root signature bind state as it is modified automatically. If a root signature is changed on a command list, all previous root signature bindings become stale and all newly expected bindings must be set before Draw/Dispatch; otherwise, the behavior is undefined. If the root signature is redundantly set to the same one currently set, existing root signature bindings do not become stale.
嗯，不错，原来是这么个freely changed法啊，md！（其实书里也有类似的话，我就不找了）
注意，这里又变成between draws了，fuck！也就是我之前说的“绘制之前”，而不是改GPU中正在执行的。所以现在我开始想，这说的到底是不是压根就是两回事儿……
还有这里《Root Signature Limits》（dn899209）
For all hardware, if any root argument changes, the driver must maintain a version of all the root arguments (unlike other storage such as descriptor heaps and buffer resources, which are not versioned by the driver)
有没有觉得有点淡腾……居然还有还多人夸ms的文档写的好。应该让他们来给咱们讲一讲……

[wconly]

嗯，当时写的匆忙，有事儿催我要办（吃饭……），没怎么查就发出去了。我看我也懵……
不知你的系统是不是Windows 10, version 1607之后版本的，如果是的话，你编出来的root signature默认是1.1的，我的Win10版本是这个版之前的，而root signature 1.1有一句话你可能没注意：
Note that 1.1 root signatures will not work on OS’s that don’t support root signature 1.1.
我想验证下用root signature 1.1的程序在我的机器上是不是真会出毛病……
看到ms有示例的注释：
NOTE: the updated d3dx12.h references the new D3D12 export for versioned root signature serialization which requires D3D12 projects to delay load d3d12.dll if they want to run on earlier versions of Windows 10 (e.g. 10240 or 10586)
所以又纠结是不是必须用1.1的那套serialization函数才会出问题，但是它文档说默认就是static，所以想试一试……

[wconly]

你不会只是高中生吧？！

[LinkClinton]

In other words, an application may wish to perform execution on the GPU timeline that updates some data in between time periods where it is set via a root parameter, knowing that when it is set it will be static.

说的time periods感觉指的不是很明确...就如你说的那样:也就是我之前说的“绘制之前”，而不是改GPU中正在执行的。所以现在我开始想，这说的到底是不是压根就是两回事儿……。但我觉得可能指的并不是GPU正在执行中的，而可能是指每一帧的间隔。

The application can change part of the root signature bindings at a time (the rest remain unchanged). For example, if the only thing that needs to change between draws is one of the constants at slot [2], that is all the application needs to rebind. As discussed previously, the driver/hardware versions all root signature bind state as it is modified automatically. If a root signature is changed on a command list, all previous root signature bindings become stale and all newly expected bindings must be set before Draw/Dispatch; otherwise, the behavior is undefined. If the root signature is redundantly set to the same one currently set, existing root signature bindings do not become stale.

那么所谓的freely changed其实就是改变的是slot对应的描述符？
例如原本slot[1]是设置的是cbv1，那么将slot[1]改变成cbv2就是freely changed？

root signature bind state应该是指的root arguments？或者还有一些其他的状态？

For all hardware, if any root argument changes, the driver must maintain a version of all the root arguments (unlike other storage such as descriptor heaps and buffer resources, which are not versioned by the driver)

这里他就终于说了不是描述符堆或者缓冲资源了，这样的话就直说啊，写的那么隐晦QAQ。

总的来说看来在1.0中加入的版本化是ms脑抽的结果，然后他们在1.1就进行了修正....无语....

[LinkClinton]

我应该能够确保自己的编译出来的是1.0版本的。

NOTE: the updated d3dx12.h references the new D3D12 export for versioned root signature serialization which requires D3D12 projects to delay load d3d12.dll if they want to run on earlier versions of Windows 10 (e.g. 10240 or 10586)

由于这里我使用的SharpDX(C#对DX的调用)，并没有使用d3dx12.h。
以及我在创建root signature的时候是指定了1.0版本的。

代码

如果是1.1版本的话，应该是CreateRootSignature1而不是CreateRootSignature。
因此应该没法帮你测试下了(难怪文明6的DX12模式要求1607以上版本的WIN10....)。

e....我的确才高中....

[wconly]

如果是高三的话，我墙裂建议你先把这些东西放一放（毕竟我有经验）……
等到大学的时候，如果可能是计算机系的话（其实有兴趣的话，不是也无所谓），你会有大把时间搞这个，而且那时候会发现这东西要搞懂并不很难（这话并没有任何歧视的意思，到时候你自然就懂了）……

[LinkClinton]

墙裂………

感谢提醒！！