protonscr

Doom Eternal crash when launch game using Proton8.0 and experimental - Proton7.0 works fine

protonclosed
ValveSoftware/Proton#6886 · opened 2023-06-28 by Reger95 · updated 2023-06-28 · 3 comments · github
1 matching comments, n / p to jump
RReger95 2023-06-28 github

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.
image

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.

// source code snip of RADV
// From /mesa/src/vulkan/runtime/vk_deferred_operation.c
VKAPI_ATTR uint32_t VKAPI_CALL
vk_common_GetDeferredOperationMaxConcurrencyKHR(UNUSED VkDevice device,
                                                UNUSED VkDeferredOperationKHR operation)
{
   return 1;
}
VKAPI_ATTR VkResult VKAPI_CALL
vk_common_GetDeferredOperationResultKHR(UNUSED VkDevice device,
                                        UNUSED VkDeferredOperationKHR operation)
{
   return VK_SUCCESS;
}
VKAPI_ATTR VkResult VKAPI_CALL
vk_common_DeferredOperationJoinKHR(UNUSED VkDevice device,
                                   UNUSED VkDeferredOperationKHR operation)
{
   return VK_SUCCESS;
}

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.

Proton7.0
From /Proton/wine/dlls/winevulkan/vulkan_thunks.c
static inline VkRayTracingPipelineCreateInfoKHR_host *convert_VkRayTracingPipelineCreateInfoKHR_array_win_to_host(const VkRayTracingPipelineCreateInfoKHR *in, uint32_t count)
{
    VkRayTracingPipelineCreateInfoKHR_host *out;
    unsigned int i;
    if (!in || !count) return NULL;
    out = malloc(count * sizeof(*out));
    for (i = 0; i < count; i++)
    {
        out[i].sType = in[i].sType;
        ......
        out[i].basePipelineIndex = in[i].basePipelineIndex;
    }
    return out;
}

In proton8.0, when using convert_VkRayTracingPipelineCreateInfoKHR_array_win64_to_host the memory will be allocated by function conversion_context_alloc.

Proton8.0
From /Proton/wine/dlls/winevulkan/vulkan_thunks.c
static inline const VkRayTracingPipelineCreateInfoKHR *convert_VkRayTracingPipelineCreateInfoKHR_array_win64_to_host(struct conversion_context *ctx, const VkRayTracingPipelineCreateInfoKHR *in, uint32_t count)
{
    VkRayTracingPipelineCreateInfoKHR *out;
    unsigned int i;
    if (!in || !count) return NULL;
    out = conversion_context_alloc(ctx, count * sizeof(*out));
    for (i = 0; i < count; i++)
    {
        convert_VkRayTracingPipelineCreateInfoKHR_win64_to_host(ctx, &in[i], &out[i]);
    }
    return out;
}

I'm stuck here and I don't know what to do next, can anyone have a deeper investigate.

Llukelmy 2023-06-28 github

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() .

Kkisak-valve maintainer 2023-06-28 github

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.

RReger95 2023-06-28 github

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 versions

Upstream links