It seems like wine should consider the situation of deferred operations and modify the strategy of address-allocation in this case since same address may obtained from conversion_context_alloc() .
Hello @Reger95, we're using one issue report per unofficially supported game title, so I've gone ahead and transferred this issue report to https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-1611328661.
Hello @Reger95, we're using one issue report per unofficially supported game title, so I've gone ahead and transferred this issue report to [#3773 (comment)](https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-1611328661).
Thanks.
proton 8.0x1 2023-06proton experimentalx1 2023-06proton7.0x1 2023-06proton8.0x1 2023-06
System Infomation:
CPU: AMD 5800X3D
GPU: AMD 6900 XT
OS: ubuntu 22.04
Similar issues is reported here https://github.com/ValveSoftware/Proton/issues/6782#issuecomment-1564381456.
I did some further research but stuck now.
Doom Eternal fails to launch on the AMD open-source and proprietary drivers with the Proton8.0 and Proton experimental,
and here is a msg get from game launch crash,
Assertion failed: !status, file ../src-wine/dlls/winevulkan/loader_thunks.c, line 3043.What the assertion is point to
VkResult WINAPI vkDeferredOperationJoinKHR(VkDevice device, VkDeferredOperationKHR operation).I tried to dump api from the game using vkconfig, and the last one is also
vkDeferredOperationJoinKHR.The address of vkCreateRayTracingPipelinesKHR is same as vkCreateGraphicsPipelines when I use proton8.0.

The address of every vkCreateWhateverPipelines is different when I use proton7.0. As shown in the picture below.
The reason is probably related to the deferred operation. For raytracing pipeline, it will be used deferred for some reason, and in this condition when using proton 8.0, the deferred operation will can't find the address of original raytracing pipeline because the memory address of this pipeline had been occupied by other type pipelines.
RADV works fine. But I have a look in its source code and I found that the deferred operation isn't implemented completely yet. It will return success directly when using the deferred operation and what you can see it in the source code snip.
I also found memory allocation of VkRayTracingPipelineCreateInfoKHR things is different in the source code of wine between proton7.0 and proton8.0. This info may be useful.
In proton7.0, when using convert_VkRayTracingPipelineCreateInfoKHR_array_win_to_host the memory will be allocated directly by malloc.
In proton8.0, when using convert_VkRayTracingPipelineCreateInfoKHR_array_win64_to_host the memory will be allocated by function conversion_context_alloc.
I'm stuck here and I don't know what to do next, can anyone have a deeper investigate.