Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[meta] Application testing #125

Open
29 of 75 tasks
kvark opened this issue Aug 4, 2018 · 3 comments
Open
29 of 75 tasks

[meta] Application testing #125

kvark opened this issue Aug 4, 2018 · 3 comments

Comments

@kvark
Copy link
Member

kvark commented Aug 4, 2018

@alexey-lysiuk
Copy link

Could you please give some details about 'minor tweak to WSI' for GZDoom mentioned on 0.7 release notes?
I guess the minimum set of changes is this one.

The thing is I've got VK_ERROR_SURFACE_LOST_KHR from vkQueuePresentKHR() almost every time on launch or after starting a new game. Sometimes, like in 20 to 30% of attempts, everything works fine.
Just of curiosity, did you experience something similar?
Probably, I can even debug Portability, although I'm not familiar with Rust at all. Are you using CLion with Rust plug-in?

I would like to use Portability with GZDoom for testing and benchmarking purposes.
Two Vulkan implementations are better than one anyway.

By the way, the source port is called GZDoom, not gzDoom.

@kvark
Copy link
Member Author

kvark commented Jul 29, 2019

@alexey-lysiuk hi! I wanted to file an issue but your github project doesn't enable issues. Would be best to have this discussion in a more specific place than our meta-issue...

Looks like you figured this out:

MoltenVK allows passing a layer, although Vulkan specs prohibit this

Basically, it's an undocumented behavior of MoltenVK implementation of the "VK_MVK_macos_surface" extension. We understand the reason why it's there, but we don't want to implement undocumented behaviors. Instead, we developed a portability-agnostic extension that would work for both us and MoltenVK and is documented properly: EXT_metal_surface. gfx-portability supports this extension since v0.6 release. MoltenVK should have it in the latest release, they implemented support about a month ago, see KhronosGroup/MoltenVK#653

The thing is I've got VK_ERROR_SURFACE_LOST_KHR from vkQueuePresentKHR() almost every time on launch or after starting a new game. Sometimes, like in 20 to 30% of attempts, everything works fine.

I haven't seen it, although:

  • I can see how this could be the case - our presentation mechanics has flaws, and they can manifest differently on different OS versions. For some background, it's complicated because we record command buffers live whenever ONE_TIME_SUBMIT is specified, so we can't naively use CAMetalLayer way of acquiring drawables... We are looking into ways to make it more robust, see Presentation Surface API gfx#2882 .
  • I haven't tested the game too much, just played for a few minutes.
  • It's not a crash, it's a valid error code the vulkan implementation may return to the app, so GZDoom should be handling this and recreating the swapchain (if it doesn't do so).

Probably, I can even debug Portability, although I'm not familiar with Rust at all. Are you using CLion with Rust plug-in?

People have different setups. I just use Sublime Text 3 with Rust Enhanced plugin.

I would like to use Portability with GZDoom for testing and benchmarking purposes.
Two Vulkan implementations are better than one anyway.

This is great, thank you! We keep our hopes up when talking about benchmarks :)
We just need to find a better place to communicate: this meta-issue is high level for our topic. There is a gitter room, for example. Alternatively, you can just create issues in this project (as opposed to continuing here).

@grovesNL
Copy link
Collaborator

grovesNL commented Jan 5, 2021

Looks like DuckStation attempted to run with portability on macOS https://github.com/stenzek/duckstation/issues/555#issuecomment-648252921

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants
@kvark @alexey-lysiuk @grovesNL and others