Clarify the use of descriptor set indices in the PAL metadata #497
Conversation
There is a second set of definitions in llpcUtil.h, which could cause conflicts going forward.
The PAL metadata contains a userdata mapping which tells PAL the data to load into each loaded userdata SGPR. There are two kinds of values: 1. Indices into the userdata table maintained by the client driver via Pal::ICmdBuffer::CmdSetUserData 2. Special "system" values as listed in Util::Abi::UserDataMapping Pointers to descriptor sets fall into the first category. The client driver tells the compiler which location in the userdata table will contain the pointer to each descriptor set (via the ResourceMappingNode part of the pipeline build info). When compiling a partial pipeline, the layout of the userdata table may not be known yet. The compiler can already decide which SGPR will hold the pointer to the descriptor set (the "key" part of the metadata), but it does not yet know the final "value" part of the metadata. To solve this problem, introduce a new kind of value, the VkDescriptorSetIndex, which is emitted as part of the PAL metadata during the initial compiler. It is resolved, when linking the different parts of a pipeline together. The emitDescriptorSetIndexInMetadata option instructs the compiler to generate these VkDescriptorSetIndex mapping. Resolving any such mappings during linking happens unconditionally while merging the metadata. This commit integrates the "updating" of the "meta note" into the merging of the metadata, as this is conceptually one operation. Some method names are updated to better reflect the asymmetry in what they do. The updateDescInElf option is renamed to emitDescriptorSetIndexInMetadata to better reflect the purpose of the option.
nhaehnle
changed the title
|
Some notes:
... and now that I posted this, I think I understand why the separate later update was required. I'm going to fix that up. |
Test summary for commit 3c62770Driver commits used in build
ShaderDB test
CTS tests (built with branch Vulkan-CTS-1.2.0.2-fetch-sources-fix)
Rhel 7.6, Vega10Ubuntu 18.04, Navi10 |
| @@ -1270,14 +1270,6 @@ Result Compiler::BuildPipelineInternal( | |||
| graphicsShaderCacheChecker.UpdateAndMerge(result, pPipelineElf); | |||
| } | |||
|
|
|||
| if ((result == Result::Success) && | |||
| pFragmentShaderInfo && | |||
There was a problem hiding this comment.
nit: pFragmentShaderInfo isn't used any more, so you can remove it together.
|
I think you need a rebase to remove the previous commit that you have abandoned. |
You're right. I first want to improve my understanding of other aspects of this feature, then I will deal with this pull request. |
|
retest this please |
|
I think this needs a bit of a rethink, in line with what Yong is looking at. For his requirements (essentially shader compilation), there will be no user data layout available, so PatchEntryPointMutate needs to deal in descriptor set numbers rather than user data offsets. For maintainability and improved test coverage, I think we should always do that, even when doing pipeline compilation. I am looking at this now. |
|
Yeah, makes sense. It'd then be good to cleanup how way those are represented in the PAL userdata mapping metadata. Meanwhile, I should really close this PR to avoid confusion... |
The PAL metadata contains a userdata mapping which tells PAL the data to
load into each loaded userdata SGPR. There are two kinds of values:
Pointers to descriptor sets fall into the first category. The client driver
tells the compiler which location in the userdata table will contain the
pointer to each descriptor set (via the ResourceMappingNode part of the
pipeline build info).
When compiling a partial pipeline, the layout of the userdata table may not
be known yet. The compiler can already decide which SGPR will hold the
pointer to the descriptor set (the "key" part of the metadata), but
does not yet know the final "value" part of the metadata.
To solve this problem, introduce a new kind of value, the
VkDescriptorSetIndex, which is emitted as part of the PAL metadata during
the initial compiler. It is resolved, when linking the different parts of a
pipeline together.
The emitDescriptorSetIndexInMetadata option instructs the compiler to
generate these VkDescriptorSetIndex mapping.
Resolving any such mappings during linking happens unconditionally while
merging the metadata.
This commit integrates the "updating" of the "meta note" into the merging
of the metadata, as this is conceptually one operation. Some method names
are updated to better reflect the asymmetry in what they do.
The updateDescInElf option is renamed to emitDescriptorSetIndexInMetadata
to better reflect the purpose of the option.