Jump to content
  • Advertisement
GuyWithBeard

Typeless formats in Vulkan

Recommended Posts

In D3D, if you want to render depth information to a texture and later use that texture as input to a shader you might create a texture with the format DXGI_FORMAT_R24G8_TYPELESS. You would then create two views to the texture, eg. one view with format DXGI_FORMAT_D24_UNORM_S8_UINT for rendering the depth and one SRV with format DXGI_FORMAT_R24_UNORM_X8_TYPELESS for sampling from the texture. How would one go about doing this in Vulkan since VkFormat does not seem to contain any typeless formats?

Share this post


Link to post
Share on other sites
Advertisement

I am surprised no-one seems to know this. Let me rephrase the question a bit.

In Vulkan, if you want to render to a texture and then later use it as a shader input, what format should you use in the texture itself, and which formats should you use in the descriptors/views? For the sake of argument, let's say the texture is R8G8B8A8.

Share this post


Link to post
Share on other sites

Oh, that's interesting. Still, it does not really answer my question.

One reason you might want a typeless format for a texture in DirectX is that you are planning to create two different views to the texture, each with their own formats, essentially "casting" the texture data into the type of the view you are currently using.

For example, if I have a depth buffer with the type VK_FORMAT_D24_UNORM_S8_UINT and I write the depth to it using a view of the same type, can I create a another view for SRV use with the format VK_FORMAT_B8G8R8A8_UNORM to that same texture, and then simply only use the RGB components? Or do I have to pass the original view to the shader?

I am only asking because AFAIK DX requires me to create two views with fully specified formats and the texture with a compatible typeless format and I would benefit from being able to do the same on Vulkan (except for the typeless part as that is not a thing on Vulkan).

Edited by GuyWithBeard
fixed a typo

Share this post


Link to post
Share on other sites

I apologize, you answered my question perfectly. I guess I just asked the wrong question.

To give you a bit of background, I have a common API that wraps, among others, DX12 and Vulkan and I am wondering how to render to a texture and later use it as an SRV in a way that works for both APIs.

Share this post


Link to post
Share on other sites
3 hours ago, GuyWithBeard said:

For example, if I have a depth buffer with the type VK_FORMAT_D24_UNORM_S8_UINT and I write the depth to it using a view of the same type, can I create a another view for SRV use with the format VK_FORMAT_B8G8R8A8_UNORM to that same texture, and the simply only use the RGB components? Or do I have to pass the original view to the shader?

 

You can't do that in D3D, because D24S8 and RGBA8 are from two different format "families" (e.g. DXGI_FORMAT_R24G8_TYPELESS / DXGI_FORMAT_R24_UNORM_X8_TYPELESS / DXGI_FORMAT_D24_UNORM_S8_UINT / etc are all the same "family").

In D3D, you use R24/X8 to tell an SRV that you'd like to read the depth channel in your shader, or X24/G8 to tell an SRV that you'd like to read the stencil channel in your shader, and D24/S8 when making a DSV just because that's what D3D makes you do.

I'm still learning Vulkan, but I think you achieve the same thing (telling the SRV which channel it will read from) via specifying VK_IMAGE_ASPECT_DEPTH_BIT or VK_IMAGE_ASPECT_STENCIL_BIT.

AFAIK, in vulkan/D3D12, it is certainly possible to alias a texture using a completely different format -- e.g. from D24S8 to RGBA8... However, it will be implementation defined whether this will work as you expect or not. It's highly likely that the GPU will use different memory addressing modes, compression modes, etc, etc, so the formats won't be bit-for-bit compatible like you would expect at first glance.

Share this post


Link to post
Share on other sites
2 minutes ago, Hodgman said:

You can't do that in D3D, because D24S8 and RGBA8 are from two different format "families"

I know, I just desperately tried to find some Vulkan formats that would equal the ones I originally used.

I guess I am just gonna have to try and see how it goes. As a fallback I can make it work like I am used to in DX11/12 and provide some custom logic to map the same view as an SRV on the Vulkan side.

Thanks for your insights, and please let me know if you figure it out as part of your own Vulkan work :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
  • Advertisement
  • Popular Tags

  • Similar Content

    • By LukeCassa005
      I'm writing a small 3D Vulkan game engine using C++. I'm working in a team, and the other members really don't know almost anything about C++. About three years ago i found this new programming language called D wich seems very interesting, as it's very similar to C++. My idea was to implement core systems like rendering, math, serialization and so on using C++ and then wrapping all with a D framework, easier to use and less complicated. Is it worth it or I should stick only to C++ ? Does it have less performance compared to a pure c++ application ?
    • By tanzanite7
      Cannot get rid of z-fighting (severity varies between: no errors at all - ~40% fail).
      * up-to-date validation layer has nothing to say.
      * pipelines are nearly identical (differences: color attachments, descriptor sets for textures, depth write, depth compare op - LESS for prepass and EQUAL later).
      * did not notice anything funny when comparing the draw commands via NSight either - except, see end of this post.
      * "invariant gl_Position" for all participating vertex shaders makes no difference ('invariant' does not show up in decompile, but is present in SPIR-V).
      * gl_Position calculations are identical for all (also using identical source data: push constants + vertex attribs)
      However, when decompiling SPIR-V back to GLSL via NSight i noticed something rather strange:
      Depth prepass has "gl_Position.z = 2.0 * gl_Position.z - gl_Position.w;" added to it. What is this!? "gl_Position.y = -gl_Position.y;", which is always added to everything, i can understand - vulcans NDC is vertically flipped by default in comparison to OpenGL. That is fine. What is the muckery with z there for? And why is it only selectively added?
      Looking at my perspective projection code (the usual matrix multiplication, just simplified):
      vec4 projection(vec3 v) { return vec4(v.xy * par.proj.xy, v.z * par.proj.z + par.proj.w, -v.z); }
      All it ends up doing is doubling w-part of 'proj' in z (proj = vec4(1.0, 1.33.., -1.0, 0.2)). How does anything show at all given that i draw with compare op EQUAL. Decompile bug?
      I am out of ideas.
    • By ZachBethel
      I have a rather specific question. I'm trying to learn about linked multi GPU in Vulkan 1.1; the only real source I can find (other than the spec itself) is the following video:
       
       
      Anyway, each node in the linked configuration gets its own internal heap pointer. You can swizzle the node mask to your liking to make one node pull from another's memory. However, the only way to perform the "swizzling" is to rebind a new VkImage / VkBuffer instance to the same VkDeviceMemory handle (but with a different node configuration). This is effectively aliasing the memory between two instances with identical properties.
      I'm curious whether this configuration requires special barriers. How do image barriers work in this case? Does a layout transition on one alias automatically affect the other. I'm coming from DX12 land where placed resources require custom aliasing barriers, and each placed resource has its own independent state. It seems like Vulkan functions a bit differently. 
      Thanks.
    • By BearishSun
      bs::framework is a newly released, free and open-source C++ game development framework. It aims to provide a modern C++14 API & codebase, focus on high-end technologies comparable to commercial engine offerings and a highly optimized core capable of running demanding projects. Additionally it aims to offer a clean, simple architecture with lightweight implementations that allow the framework to be easily enhanced with new features and therefore be ready for future growth.
      Some of the currently available features include a physically based renderer based on Vulkan, DirectX and OpenGL, unified shading language, systems for animation, audio, GUI, physics, scripting, heavily multi-threaded core, full API documentation + user manuals, support for Windows, Linux and macOS and more.
      The next few updates are focusing on adding support for scripting languages like C#, Python and Lua, further enhancing the rendering fidelity and adding sub-systems for particle and terrain rendering.
      A complete editor based on the framework is also in development, currently available in pre-alpha stage.
      You can find out more information on www.bsframework.io.

      View full story
    • By BearishSun
      bs::framework is a newly released, free and open-source C++ game development framework. It aims to provide a modern C++14 API & codebase, focus on high-end technologies comparable to commercial engine offerings and a highly optimized core capable of running demanding projects. Additionally it aims to offer a clean, simple architecture with lightweight implementations that allow the framework to be easily enhanced with new features and therefore be ready for future growth.
      Some of the currently available features include a physically based renderer based on Vulkan, DirectX and OpenGL, unified shading language, systems for animation, audio, GUI, physics, scripting, heavily multi-threaded core, full API documentation + user manuals, support for Windows, Linux and macOS and more.
      The next few updates are focusing on adding support for scripting languages like C#, Python and Lua, further enhancing the rendering fidelity and adding sub-systems for particle and terrain rendering.
      A complete editor based on the framework is also in development, currently available in pre-alpha stage.
      You can find out more information on www.bsframework.io.
    • By tanzanite7
      Trying to figure out why input attachment reads as black with NSight VS plugin - and failing.
      This is what i can see at the invocation point of the shader:
      * attachment is filled with correct data (just a clear to bright red in previous renderpass) and used by the fragment shader:
      // SPIR-V decompiled to GLSL #version 450 layout(binding = 0) uniform sampler2D accum; // originally: layout(input_attachment_index=0, set=0, binding=0) uniform subpassInput accum; layout(location = 0) out vec4 fbFinal; void main(){ fbFinal = vec4(texelFetch(accum, ivec2(gl_FragCoord.xy), 0).xyz + vec3(0.0, 0.0, 1.0), 1.0); // originally: fbFinal = vec4(subpassLoad(accum).rgb + vec3(0.0, 0.0, 1.0), 1.0); } * the resulting image is bright blue - instead of the expected bright purple (red+blue)
      How can this happen?
      'fbFinal' format is B8G8R8A8_UNORM and 'accum' format is R16G16B16A16_UNORM - ie. nothing weird.
    • By turanszkij
      Hi, running Vulkan with the latest SDK, validation layers enabled I just got the following warning:
      That is really strange, because in DX11 we can have 15 constant buffers per shader stage. And my device (Nvidia GTX 1050 is DX11 compatible of course) Did anyone else run into the same issue? How is it usually handled? I would prefer not enforcing less amount of CBs for the Vulkan device and be as closely compliant to DX11 as possible. Any idea what could be the reason behind this limitation?
    • By DiligentDev
      Hello everyone!
      For my engine, I want to be able to automatically generate pipeline layouts based on shader resources. That works perfectly well in D3D12 as shader resources are not required to specify descriptor tables, so I use reflection system and map different shader registers to tables as I need. In Vulkan, however, looks like descriptor sets must be specified in both SPIRV bytecode and when creating pipeline layout (why is that?). So it looks like I will have to mess around with the bytecode to tweak bindings and descriptor sets. I looked at SPIRV-cross but it seems like it can't emit SPIRV (funny enough). I also use glslang to compile GLSL to SPIRV and for some reason, binding decoration is only present for these resources that I explicitly defined.
      Does anybody know if there is a tool to change bindings in SPIRV bytecode?
       
    • By turanszkij
      Hi, I am having problems with all of my compute shaders in Vulkan. They are not writing to resources, even though there are no problems in the debug layer, every descriptor seem correctly bound in the graphics debugger, and the shaders definitely take time to execute. I understand that this is probably a bug in my implementation which is a bit complex, trying to emulate a DX11 style rendering API, but maybe I'm missing something trivial in my logic here? Currently I am doing these:
      Set descriptors, such as VK_DESCRIPTOR_TYPE_STORAGE_BUFFER for a read-write structured buffer (which is non formatted buffer) Bind descriptor table / validate correctness by debug layer Dispatch on graphics/compute queue, the same one that is feeding graphics rendering commands.  Insert memory barrier with both stagemasks as VK_PIPELINE_STAGE_ALL_COMMANDS_BIT and srcAccessMask VK_ACCESS_SHADER_WRITE_BIT to dstAccessMask VK_ACCESS_SHADER_READ_BIT Also insert buffer memory barrier just for the storage buffer I wanted to write Both my application behaves like the buffers are empty, and Nsight debugger also shows empty buffers (ssems like everything initialized to 0). Also, I tried the most trivial shader, writing value of 1 to the first element of uint buffer. Am I missing something trivial here? What could be an other way to debug this further?
       
    • By khawk
      LunarG has released new Vulkan SDKs for Windows, Linux, and macOS based on the 1.1.73 header. The new SDK includes:
      New extensions: VK_ANDROID_external_memory_android_hardware_buffer VK_EXT_descriptor_indexing VK_AMD_shader_core_properties VK_NV_shader_subgroup_partitioned Many bug fixes, increased validation coverage and accuracy improvements, and feature additions Developers can download the SDK from LunarXchange at https://vulkan.lunarg.com/sdk/home.

      View full story
  • Advertisement
  • Popular Now

  • Forum Statistics

    • Total Topics
      631378
    • Total Posts
      2999665
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!