P3: -gr_sync_validation reports itself enabled but never turns on synchronization validation

Open Beginner friendly
  • Is something wrong?
#7,983 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
68/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
cpp
Domain
computer-graphics

Research direction

Start in VulkanRenderer::initializeInstance, where the non-OpenXR path passes the bare createInfo to vk::createInstanceUnique. Compare it with the OpenXR branch, which passes the head of createInstanceChain. Build in Debug with Vulkan, run with -gr_sync_validation, and check fs2_open.log for SYNC-HAZARD lines. Done when the flag alone reports the same hazards that VK_KHRONOS_VALIDATION_VALIDATE_SYNC=true reports.

Written by the indexing model from the issue text.

Description

Problem

-gr_sync_validation does not turn on Vulkan synchronization validation. The log says "Vulkan: Synchronization validation enabled (-gr_sync_validation)", but no synchronization hazards are ever reported, so a clean run with the flag proves nothing. Outside OpenXR, vk::createInstanceUnique is passed the bare createInfo instead of the head of the structure chain, so the validation-features struct (and the debug messenger meant to catch messages during instance creation) never reaches the driver. The OpenXR branch passes the chain correctly.

Steps to reproduce

  1. Build current master (tested on 8afa31842) in Debug with Vulkan, MediaVPs 5.0.2, no other mods.
  2. Run SM1-01 with -vulkan -gr_sync_validation for about 20 seconds of gameplay. fs2_open.log: the "Synchronization validation enabled" line, 0 lines containing SYNC-HAZARD.
  3. Run the same thing again with the environment variable VK_KHRONOS_VALIDATION_VALIDATE_SYNC=true (which turns the same check on from the validation layer's side). fs2_open.log: 10 SYNC-HAZARD-WRITE-AFTER-WRITE lines from vkCmdClearAttachments in the same 20 seconds.

Expected vs. actual behavior

  • Expected: the flag alone reports the same hazards as step 3.
  • Actual: the flag alone reports none, while the log claims it is on.

Proposed fixes

  1. In VulkanRenderer::initializeInstance, pass createInstanceChain.get<vk::InstanceCreateInfo>() to vk::createInstanceUnique, as the OpenXR branch already does.
  2. Same change, plus a one-time check after instance creation that logs whether the layer accepted synchronization validation, so the log line reflects what actually happened.
  3. Same change, plus a note in the flag's help text that VK_KHRONOS_VALIDATION_VALIDATE_SYNC=true works as a fallback on older builds.

The hazards in step 3 are reported as observed; I have not looked into whether each is a real problem.

Dominant language
C++
Stars
488
Forks
184
Avg merge
5d 35m
Merged PRs (30d)
29

Getting set up

We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from scp-fs2open/fs2open.github.com

All issues in scp-fs2open/fs2open.github.com

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.