While true, is there a scenario where the same shader is used with different xfb infos?
Yes, it's happened on an internal d3d11 test case, it's used to test corner cases I guess. The two shaders use the different SoEntries. I've work-round it on local.
` size_t cacheSize = BytecodeLength;
if ((pDxbcModuleInfo != nullptr) && (pDxbcModuleInfo->xfb != nullptr))
{
cacheSize += sizeof(DxbcXfbInfo);
}
std::vector cachedata(cacheSize);
memcpy(&cachedata[0], pShaderBytecode, BytecodeLength);
if ((pDxbcModuleInfo != nullptr) && (pDxbcModuleInfo->xfb != nullptr))
{
memcpy(&cachedata[BytecodeLength], pDxbcModuleInfo->xfb, sizeof(DxbcXfbInfo));
}
// Compute the shader's unique key so that we can perform a lookup
DxvkShaderKey key(GetShaderStage(ProgramType), cachedata.data(), cachedata.size());`
I guess hashing the XFB state vector along with the shader code should be enough to resolve this without blowing the shader key structure out of proportion (and more importantly, without invalidating existing state caches).
Should be fixed now.
It works, thanks.
Nothing extracted yet.
There is a scenario when create two GS shaders with the same dxasm code, but with different DxbcXfbInfo. The two GS should be considered as different shader, because they will generate two different spirv or hardware shaders.
But now in D3D11ShaderModuleSet::GetShaderModule() method, when creating the second shader, it just return the cache of the first one. I think the DxbcXfbInfo should be a part of the ShaderKey.