Skip to content

foveation fixes#933

Merged
bjornbytes merged 2 commits intobjornbytes:devfrom
cosmorama-space:fix-foveation
Feb 25, 2026
Merged

foveation fixes#933
bjornbytes merged 2 commits intobjornbytes:devfrom
cosmorama-space:fix-foveation

Conversation

@nensanders
Copy link
Contributor

@nensanders nensanders commented Feb 25, 2026

Copilot Prompt:

User: I think there is a bug in configuring the foveation for vulkan.
If the foveation is off no artifacts appear.
If the foveation is on artifacts apprear.
It looks like there is a small quad texture interleaved with the main framebuffer. it seems to be the same quad but at different locations per eye. the quad seem to show artifacts of repeated or old fragments, the color of the frags seem of.
Check the lovr graphics to see potential issues how the foveation is set up.

Here's a summary of the three bugs found and fixed in gpu_vk.c:

1. Missing VK_PIPELINE_CREATE_RENDERING_FRAGMENT_DENSITY_MAP_ATTACHMENT_BIT_EXT pipeline flag (most likely cause of your artifacts)

When dynamic rendering (VK_KHR_dynamic_rendering) is active, pipelines used with fragment density maps must have VK_PIPELINE_CREATE_RENDERING_FRAGMENT_DENSITY_MAP_ATTACHMENT_BIT_EXT. Without it, the driver compiles the pipeline unaware of fragment density variation — the fragment shader runs at uniform resolution, but the framebuffer has subsampled regions from the density map. This produces exactly what you see: small quad-shaped regions with stale/wrong fragments at different locations per eye (each eye's density map offsets differ).

2. Wrong tracked layout for foveation textures (gpu_vk.c)

getNaturalLayout fell through to VK_IMAGE_LAYOUT_ATTACHMENT_OPTIMAL_KHR for GPU_TEXTURE_FOVEATION textures. The correct layout is VK_IMAGE_LAYOUT_FRAGMENT_DENSITY_MAP_OPTIMAL_EXT. While the layout tracking isn't currently used for explicit transitions of the foveation texture, this mismatch is wrong state that could cause issues with validation layers or future code.

3. fragmentDensityMapNonSubsampledImages enabled unconditionally

The feature was enabled without querying whether the physical device supports it. Now it queries the actual device support before enabling. If a device doesn't support non-subsampled images but foveation is requested, this could cause device creation failure or undefined behavior.

Tested on Meta Quest 3.
Artifacts are gone.

This is ofc a vibe coding fix attempt. Please review carefully. Used copilot claude 4.6.

Copy link
Owner

@bjornbytes bjornbytes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I only tested foveation on Quest 2 which doesn't support dynamic rendering, so I missed this pipeline flag.

@nensanders
Copy link
Contributor Author

Reverted both unnecessary changes

@bjornbytes bjornbytes merged commit fc3074f into bjornbytes:dev Feb 25, 2026
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

Successfully merging this pull request may close these issues.

2 participants