• Advertisement
  • Popular Tags

  • Popular Now

  • Advertisement
  • Similar Content

    • 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
    • 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.
    • By mark_braga
      I have a pretty good experience with multi gpu programming in D3D12. Now looking at Vulkan, although there are a few similarities, I cannot wrap my head around a few things due to the extremely sparse documentation (typical Khronos...)
      In D3D12 -> You create a resource on GPU0 that is visible to GPU1 by setting the VisibleNodeMask to (00000011 where last two bits set means its visible to GPU0 and GPU1)
      In Vulkan - I can see there is the VkBindImageMemoryDeviceGroupInfoKHR struct which you add to the pNext chain of VkBindImageMemoryInfoKHR and then call vkBindImageMemory2KHR. You also set the device indices which I assume is the same as the VisibleNodeMask except instead of a mask it is an array of indices. Till now it's fine.
      Let's look at a typical SFR scenario:  Render left eye using GPU0 and right eye using GPU1
      You have two textures. pTextureLeft is exclusive to GPU0 and pTextureRight is created on GPU1 but is visible to GPU0 so it can be sampled from GPU0 when we want to draw it to the swapchain. This is in the D3D12 world. How do I map this in Vulkan? Do I just set the device indices for pTextureRight as { 0, 1 }
      Now comes the command buffer submission part that is even more confusing.
      There is the struct VkDeviceGroupCommandBufferBeginInfoKHR. It accepts a device mask which I understand is similar to creating a command list with a certain NodeMask in D3D12.
      So for GPU1 -> Since I am only rendering to the pTextureRight, I need to set the device mask as 2? (00000010)
      For GPU0 -> Since I only render to pTextureLeft and finally sample pTextureLeft and pTextureRight to render to the swap chain, I need to set the device mask as 1? (00000001)
      The same applies to VkDeviceGroupSubmitInfoKHR?
      Now the fun part is it does not work  . Both command buffers render to the textures correctly. I verified this by reading back the textures and storing as png. The left texture is sampled correctly in the final composite pass. But I get a black in the area where the right texture should appear. Is there something that I am missing in this? Here is a code snippet too
      void Init() { RenderTargetInfo info = {}; info.pDeviceIndices = { 0, 0 }; CreateRenderTarget(&info, &pTextureLeft); // Need to share this on both GPUs info.pDeviceIndices = { 0, 1 }; CreateRenderTarget(&info, &pTextureRight); } void DrawEye(CommandBuffer* pCmd, uint32_t eye) { // Do the draw // Begin with device mask depending on eye pCmd->Open((1 << eye)); // If eye is 0, we need to do some extra work to composite pTextureRight and pTextureLeft if (eye == 0) { DrawTexture(0, 0, width * 0.5, height, pTextureLeft); DrawTexture(width * 0.5, 0, width * 0.5, height, pTextureRight); } // Submit to the correct GPU pQueue->Submit(pCmd, (1 << eye)); } void Draw() { DrawEye(pRightCmd, 1); DrawEye(pLeftCmd, 0); }  
    • By turanszkij
      Hi,
      I finally managed to get the DX11 emulating Vulkan device working but everything is flipped vertically now because Vulkan has a different clipping space. What are the best practices out there to keep these implementation consistent? I tried using a vertically flipped viewport, and while it works on Nvidia 1050, the Vulkan debug layer is throwing error messages that this is not supported in the spec so it might not work on others. There is also the possibility to flip the clip scpace position Y coordinate before writing out with vertex shader, but that requires changing and recompiling every shader. I could also bake it into the camera projection matrices, though I want to avoid that because then I need to track down for the whole engine where I upload matrices... Any chance of an easy extension or something? If not, I will probably go with changing the vertex shaders.
    • By Alexa Savchenko
      I publishing for manufacturing our ray tracing engines and products on graphics API (C++, Vulkan API, GLSL460, SPIR-V): https://github.com/world8th/satellite-oem
      For end users I have no more products or test products. Also, have one simple gltf viewer example (only source code).
      In 2016 year had idea for replacement of screen space reflections, but in 2018 we resolved to finally re-profile project as "basis of render engine". In Q3 of 2017 year finally merged to Vulkan API. 
       
       
  • Advertisement
  • Advertisement
Sign in to follow this  

Vulkan Advises for graphics APIs to learn

This topic is 425 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey Guys,

 

I have being playing around directx since dx9 to dx12, and haven't touch any other graphics APIs yet. For all those years, I really enjoy developing dx with all its helping tools/libs: dx debuglayer, GPU-validation layer, GPUView, VSGD, and recently, the PIX. Now I have to switch to use mac os (and ios maybe?) exclusively in the near future. So I need to pick up another compatible graphics API to play with. What I really enjoy is DX12 style lower level APIs, and have heard that there are maybe only two choices for me: Vulkan (not sure mac os support it or not?) and Metal.

 

Since I haven't touched either APIs, I really wish to know what you guys think of it: is it in a mature state for beginner? (I remember when I work on my first DX12 project when DX12 just coming out, driver bugs drives me crazy....) are there any good GPU debug tools available for the API? (does Metal get renderDoc support?) are there any good profiling tools? (like GPUView for DX) are there plenty of tutorials/samples on the internet for beginners?

 

Also it will be great if anyone could talk about the general pros and cons for using Vulkan/Metal on apple devices.

 

Thanks in advance 

Share this post


Link to post
Share on other sites
Advertisement

edit - and opengl but you said you wanted low level.

 

I know Vulkan and Metal are *really* low level, but are we at the point where opengl is considered NOT low level?

Share this post


Link to post
Share on other sites

I know Vulkan and Metal are *really* low level, but are we at the point where opengl is considered NOT low level?

Then what API do you consider high-level?  Most things are handled for you in Opengl aren't they?  That makes it high level to me.  Also I wouldn't call Vulkan "*really* low level" I would call it lower level then previous API's.  It's constructs are still IHV agnostic... so it not that low level. 

Share this post


Link to post
Share on other sites

Cant you like just look at RenderDoc's project page? https://github.com/baldurk/renderdoc
Sorry for my laziness,  I thought since I already ask a lot, it may not be super annoying to add such easy-to-find question, maybe someone work for renderdoc could reveal their real 'future plan' in this thread......

but are we at the point where opengl is considered NOT low level?
well, I really wish to be exposed to explicit resource barrier (handling resource transition by myself) which IIRC is not available in openGL 

Share this post


Link to post
Share on other sites

So it seems 'cross-platform' Vulkan could only work on windows, linux/unix (for desktop/laptop)? Feel really bad to see that 'cross-platform' is narrowing down....  

 

If I got it correctly writing driver for Vulkan should be easier than writing for OpenGL( since lots responsibilities is moving from driver to developer) Why mac os have opengl support but not Vulkan? (I don't have any experience with mac before....)

Share this post


Link to post
Share on other sites

Because in OSX it isn't up to the vendors. Apple supplies the "frontend" of the API, thus for example, you only get the OpenGL versions Apple supports, nothing more, nothing less.

Its the same for Vulkan. They dont want it in their OS.

Share this post


Link to post
Share on other sites

Why mac os have opengl support but not Vulkan?

Because backwards compatibility... as in before metal (which is relatively new) the 3d api for mac's was opengl.  Then they decided to support the in house metal instead of vulkan. 

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement