search

harrand / Topaz

C++20 Game Engine
https://harrand.github.io/Topaz/
MIT License
35 stars 3 forks source link

Feature Request: Storage Images #95

Open harrand opened 8 months ago

harrand commented 8 months ago

Describe the feature request Currently, VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER is used throughout the vulkan frontend. This is fine and the simplest thing to do, although is troublesome when we think about Storage Images.

If we want a compute shader to be able to write to an image resource, we're screwed, because the vulkan frontend doesn't create any storage images, nor does it ever create descriptors of type VK_DESCRIPTOR_TYPE_STORAGE_IMAGE.

Remember: Storage Images don't require samplers, so I don't think it means we need to change non-storage images to not be combined with samplers. I think they're fine.

Might also need tzslc syntax for specifying the image format in the shader, because for some reason that's a thing.

Justification Needed for GPU occlusion cullling based on depth pyramid. Culling (compute) shader needs to be able to imageStore max depth. https://vkguide.dev/docs/gpudriven/compute_culling/#occlusion-culling

Additional context Does opengl just support this???

harrand commented 8 months ago

This requires complicated architectural changes in the vulkan frontend.

  1. Storage Images must always be in the General image layout.,
  2. In renderer_vulkan2, renderer_descriptor_manager's constructor runs before renderer_command_processor, meaning scratch commands aren't available while descriptor manager is being initialised.
  3. Validation layers complain if you write an image descriptor that is both a storage image and isn't in the general layout.
  4. Important note: Only preinitialised and undefined are allowed to be the initial image layouts. This means we must run scratch commands before writing our first set of descriptors. Due to the inheritance order, this is impossible

To fix this, renderer_command_processor needs to happen before renderer_descriptor_manager. From the sounds of things, they are orthogonal and this is technically more correct. However, there might be various gotchas. I haven't tried properly yet. This is a scary roadblock though.

In the meantime, my local changes on this will live on the vk_storage_images branch.