Use separate images for read and write operations about vkbasalt

[DadSchoorse]

I am currently working on resolving this issue (see the 2 branch). My plan is:

1. return non swapchain images to the game
2. use a graphic pipeline instead of a compute pipeline
3. use the image that the game writes to as sampled image in the fragment shader
4. output to the real swapchain image and present it

I still do not know if that solves the sRGB issue though.

[DadSchoorse]

@sigexp An issue with your approach is, that no driver I know of supports sRGB storage images.

[doitsujin]

I still do not know if that solves the sRGB issue though.

It does, since both images will have sRGB conversion either enabled or enabled. I agree that this is probably the best solution, even if it doesn't allow for the same degree of optimization that you could in theory and with quite a bit of extra work achieve with a compute shader, but the sharpening only has a marginal impact on the overall frame time anyway.

that no driver I know of supports sRGB storage images.

That's why it would have to be implemented manually in a compute shader, but that would make it unnecessarily complicated.

[DadSchoorse]

That's why it would have to be implemented manually in a compute shader, but that would make it unnecessarily complicated.

What type of image would even be written to? As I am understanding it, creating a storage image would be undefined behavior and currently it is just "luck" that there is just no conversion. But could not everything from a crash to just a darker image happen?

[doitsujin]

You can create a non-sRGB view for an sRGB image, in which case no conversion occurs.

[DadSchoorse]

You can create a non-sRGB view for an sRGB image, in which case no conversion occurs.

And that is defined behavior? Cool I did not know that.

[DadSchoorse]

Ok, my approach kinda works now on NVIDIA, I just need to stop the game from changing the image layout to present on the non swapchain images to get it working on AMD.

[doitsujin]

Just do a PRESENT_SRC_KHR -> SHADER_READ_ONLY_OPTIMAL layout transition before beginning the render pass.

[DadSchoorse]

Well that would be the easy way, but I think the spec does technically not allow Image layout transitions to present on non swapchain images. But simply replacing PRESENT_SRC_KHR with SHADER_READ_ONLY_OPTIMAL in pipeline barriers and the renderPass creation should be allowed, shouldn't it? Oh and I just wanted to ask if it is okay that I ask you stuff about this project all the time.

[doitsujin]

But simply replacing PRESENT_SRC_KHR with SHADER_READ_ONLY_OPTIMAL in pipeline barriers and the renderPass creation should be allowed, shouldn't it?

Yes, it is.

Well that would be the easy way, but I think the spec does technically not allow Image layout transitions to present on non swapchain images.

This should be allowed (you can always enable validation layers though to check whether they yell at you). The spec states that the only operation allowed while the image is in PRESENT_SRC_KHR layout is presentation, but this does not disallow subsequent layout transitions, and it does not explicitly state that only swap chain images may be transitioned to this layout.

[DadSchoorse]

I have finished the rewrite, it seems to work on AMD #30 and solves the sRGB issue #18.