• Advertisement

Search the Community

Showing results for tags 'Vulkan'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Categories

  • Audio
    • Music and Sound FX
  • Business
    • Business and Law
    • Career Development
    • Production and Management
  • Game Design
    • Game Design and Theory
    • Writing for Games
    • UX for Games
  • Industry
    • Interviews
    • Event Coverage
  • Programming
    • Artificial Intelligence
    • General and Gameplay Programming
    • Graphics and GPU Programming
    • Engines and Middleware
    • Math and Physics
    • Networking and Multiplayer
  • Visual Arts
  • Archive

Categories

  • News

Categories

  • Audio
  • Visual Arts
  • Programming
  • Writing

Categories

  • GameDev Unboxed

Categories

  • Game Dev Loadout

Categories

  • Game Developers Conference
    • GDC 2017
    • GDC 2018
  • Power-Up Digital Games Conference
    • PDGC I: Words of Wisdom
    • PDGC II: The Devs Strike Back
    • PDGC III: Syntax Error

Forums

  • Audio
    • Music and Sound FX
  • Business
    • Games Career Development
    • Production and Management
    • Games Business and Law
  • Game Design
    • Game Design and Theory
    • Writing for Games
  • Programming
    • Artificial Intelligence
    • Engines and Middleware
    • General and Gameplay Programming
    • Graphics and GPU Programming
    • Math and Physics
    • Networking and Multiplayer
  • Visual Arts
    • 2D and 3D Art
    • Critique and Feedback
  • Topical
    • Virtual and Augmented Reality
    • News
  • Community
    • For Beginners
    • GameDev Challenges
    • GDNet+ Member Forum
    • GDNet Lounge
    • GDNet Comments, Suggestions, and Ideas
    • Coding Horrors
    • Your Announcements
    • Hobby Project Classifieds
    • Indie Showcase
    • Article Writing
  • Affiliates
    • NeHe Productions
    • AngelCode
  • Workshops
    • C# Workshop
    • CPP Workshop
    • Freehand Drawing Workshop
    • Hands-On Interactive Game Development
    • SICP Workshop
    • XNA 4.0 Workshop
  • Archive
    • Topical
    • Affiliates
    • Contests
    • Technical
  • GameDev Challenges's Topics

Calendars

  • Community Calendar
  • Games Industry Events
  • Game Jams
  • GameDev Challenges's Schedule

Blogs

There are no results to display.

There are no results to display.

Developers

Developers


Group


About Me


Website


Industry Role


Twitter


Github


Twitch


Steam

Found 117 results

  1. 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.
  2. 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
  3. 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); }
  4. 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.
  5. vkQueuePresentKHR is busy waiting - ie. wasting all the CPU cycles while waiting for vsync. Expected, sane, behavior would of course be akin to Sleep(0) till it can finish. Windows 7, GeForce GTX 660. Is this a common problem? Is there anything i can do to make it behave properly?
  6. I am working on reusing as many command buffers as I can by pre-recording them at load time. This gives a significant boost on CPU although now I cannot get the GPU timestamps since there is no way to read back. I Map the readback buffer before and Unmap it after reading is done. Does this mean I need a persistently mapped readback buffer? void Init() { beginCmd(cmd); cmdBeginQuery(cmd); // Do a bunch of stuff cmdEndQuery(cmd); endCmd(cmd); } void Draw() { CommandBuffer* cmd = commands[frameIdx]; submit(cmd); } The begin and end query do exactly what the names say.
  7. Vulkan 1.1 Spec Released

    The Khronos™ Group, an open consortium of leading hardware and software companies creating advanced acceleration standards, announces the release of the Vulkan® 1.1 and SPIR-V™ 1.3 specifications. Version 1.1 expands Vulkan’s core functionality with developer-requested features, such as subgroup operations, while integrating a wide range of proven extensions from Vulkan 1.0. Khronos will also release full Vulkan 1.1 conformance tests into open source and AMD, Arm, Imagination, Intel Corporation, NVIDIA and Qualcomm have implemented conformant Vulkan 1.1 drivers. Find more information on the Vulkan 1.1 specification and associated tests and tools at Khronos’s Vulkan Resource Page. “With enhanced developer tools, rigorous conformance testing and the public Vulkan Ecosystem Forum, Khronos is delivering on its goal to develop a complete and vibrant Vulkan ecosystem,” said Tom Olson, distinguished engineer at Arm, and Vulkan Working Group chair. “Vulkan 1.1 is a response to prioritized industry requests and shows our commitment to delivering a functional roadmap driven by developer needs.” Vulkan 1.1 will drive increased industry momentum for this new-generation, cross-platform standard for explicit control over GPU acceleration. Vulkan now ships natively on almost all GPU-enabled platforms, including Windows 7, 8.X, 10, Android 7.0+ and Linux, plus Khronos recently announced open source tools to enable Vulkan 1.0 applications to be ported to macOS and iOS. Vulkan has widespread support in leading games engines including Unreal, Unity, Source 2 from Valve, id Tech, CroTeam’s Serious Engine, CryEngine, and Xenko. Vulkan is being used in over 30 cutting-edge games on diverse desktop and mobile platforms, including Doom, Quake, Roblox, The Talos Principle, Dota 2, and is the exclusive API used in AAA titles such as Wolfenstein II and Doom VFR. New functionality in Vulkan 1.1 includes Subgroup Operations that enable highly-efficient sharing and manipulation of data between multiple tasks running in parallel on a GPU. Vulkan 1.1 also enables applications to perform rendering and display operations using resources that they cannot access or copy - for secure playback and display of protected multimedia content. In addition, a wide range of Vulkan 1.0 extensions have been integrated, bringing significant proven functionality into core Vulkan 1.1, including: simultaneous rendering of multiple image views, use of multiple GPUs in a single system, and cross-process API interoperability for advanced rendering and compositing operations often used in demanding applications such as Virtual Reality. These core functionalities also include advanced compute with 16-bit memory access, and support for HLSL memory layouts, and display, processing and compositing of video streams, through direct sampling of YCbCr color formatted textures produced by many video codecs. Integral to the release of Vulkan 1.1 is the new SPIR-V 1.3 specification that expands the capabilities of the Vulkan shader intermediate representation to support subgroup operations and enable enhanced compiler optimizations. The SPIR-V tools ecosystem continues to gain significant momentum with front-end compilers for both GLSL and HLSL, and to expand low-level tooling support from the open source SPIRV-Tools project. “We are excited to see the progress developers have made with the SPIR-V standardized IR. Developers are using the shader language of their choice and a variety of open source compilers to ship their games and applications. The Vulkan tools and ecosystem is evolving rapidly.” said David Neto, Shader compiler team lead at Google. Open source Vulkan development tools continue to evolve alongside the specification. For example, the LunarG Vulkan SDK and tools layers have been upgraded to support Vulkan 1.1, including the Vulkan Layer Factory (VLF) to enable rapid layer development, the Device Simulation Layer to simulate target device capabilities, without requiring actual physical hardware and the new Assistant Layer to guide developers to best practices and to highlight potential application problems. In addition, the RenderDoc frame capture and introspection debugging tool has added full native Vulkan support on Android with help from Khronos members, and improved support for displaying SPIR-V disassembly using SPIRV-Tools and high-level languages through the SPIRV-Cross cross compiler. RenderDoc has also been upgraded to expose native disassembly and profiling information for vendors who support it, and to support the external memory features that now form a core part of Vulkan 1.1. To encourage the collaborative evolution of the Vulkan ecosystem, Khronos has created the public Vulkan Ecosystem Forum to share issues and opportunities, and to coordinate cooperative solutions. The aim of the Forum is to respond to developer feedback and foster cross-functional discussions and engagement between users, tools developers and API designers. Join the conversation at Vulkan Ecosystem on GitHub. Industry Support for Vulkan 1.1 “AMD is very excited about the release of the Vulkan 1.1 specifications. This new iteration of the industry standard builds on its strong foundations and expands its reach by making the API more accessible to developers. New Vulkan 1.1 features such as subgroup access in compute shaders enable console-like optimizations that will empower developers to exert more control on the GPU than ever before,” said Andrej Zdravkovic, corporate vice president of software, AMD. “Vulkan also enriches its connectivity with other APIs by supporting interop operations, and finally enables first-class support for multi-GPU and VR systems. AMD believes that this major upgrade to the API will delight the existing Vulkan community and continue to broaden the user base.” “The new additions in Vulkan 1.1 are a game changer for Vulkan,” said Andrew Richards, CEO of Codeplay Software. “In particular the new subgroup functionality will make a huge difference to our low power, high performance deep learning work.” “Continental is delighted to see how Vulkan continues to move graphics technology forward,” said Dr. Ulrich Kabatek, principal expert graphic systems & 3D visualization at Continental. “We appreciate the improvements it offers for more integrated automotive systems and latency critical applications like augmented automotive clusters.” “As a major contributor to the Vulkan API, Imagination is pleased to see the next evolution of the API in Vulkan 1.1. The new specification offers new ways to exploit GPU parallelism and support for protected content - enabling advanced video processing in Vulkan for things like VR Cinema,” said Graham Deacon, vice president of PowerVR Marketing at Imagination. “We are amongst the first vendors to have a conformant Vulkan implementation, with all of our existing Vulkan-capable GPU IP able to support the new 1.1 standard. The new subgroup and protected content features are fully available in many of our newer cores.” “Intel is committed to open source driver advances for high performance graphics. Vulkan 1.1 is certified on the latest four generations of Intel® Core™ processors, further developing support for virtual and mixed reality,” said Imad Sousou, corporate vice president and general manager of the Open Source Technology Center at Intel Corporation. “Vulkan is vital to NVIDIA’s business as it enables developers to get the best from our GPUs across a wide range of platforms,” said Dwight Diercks, senior vice president of software engineering, NVIDIA. “Our Vulkan 1.1 drivers, with full subgroup functionality, are available for Windows, Linux, and Android on the day of the specification launch. We will continue to take a leadership role within Khronos to ensure Vulkan evolves to meet the needs of developers and the wider industry.” “Vulkan is enabling high fidelity games to make the most out of the capability in mobile, with great titles like Honor of Kings from Tencent running across many Galaxy devices” said Taeyong Kim, VP of Graphics at Samsung Electronics. “Vulkan 1.1 builds on this, adding functionality for VR gaming and 360 video that will enable immersive content on mobile products and VR headsets.” “In our non-gaming business, Vulkan 1.1 is a key factor for our success,” said Norbert Nopper, founder of UX3D, “The possibility to utilize simultaneous rendering and multiple GPUs by default does help us to further optimize our engine.” "VeriSilicon has adopted the latest industry standard low-level GPU API Vulkan 1.1 and is committed to support Vulkan 1.1 across our OpenGL ES 3.1/3.2 class GPUs," said Wei-Jin Dai, executive vice president of VeriSilicon and general manager of VeriSilicon's IP Division. "We are glad to see the new functionalities of Vulkan 1.1 API, the multi-GPU support, the premium content protection, and the advanced compute functionality, etc. to unleash the tremendous potential for a new generation of Vulkan applications. We are particularly excited about the opportunities the Vulkan 1.1 brings to the automotive customers to have fine-grained control over graphics quality of service and highly desired security levels and features.” "Vulkan 1.1 and SPIR-V 1.3 are another step in providing better support for compute, as it adds subgroups, 16-bit numbers and a restricted form of pointers", said Vincent Hindriksen, managing director of StreamHPC. "Adding this to the strong industry support for Vulkan and the recently launched portability project, this allows more types of compute-kernels to be run on more platforms.” More Information More information on Vulkan is available at https://www.khronos.org/vulkan/ All Khronos open source projects are available here: https://github.com/KhronosGroup
  8. Vulkan 1.1 Spec Released

    The Khronos™ Group, an open consortium of leading hardware and software companies creating advanced acceleration standards, announces the release of the Vulkan® 1.1 and SPIR-V™ 1.3 specifications. Version 1.1 expands Vulkan’s core functionality with developer-requested features, such as subgroup operations, while integrating a wide range of proven extensions from Vulkan 1.0. Khronos will also release full Vulkan 1.1 conformance tests into open source and AMD, Arm, Imagination, Intel Corporation, NVIDIA and Qualcomm have implemented conformant Vulkan 1.1 drivers. Find more information on the Vulkan 1.1 specification and associated tests and tools at Khronos’s Vulkan Resource Page. “With enhanced developer tools, rigorous conformance testing and the public Vulkan Ecosystem Forum, Khronos is delivering on its goal to develop a complete and vibrant Vulkan ecosystem,” said Tom Olson, distinguished engineer at Arm, and Vulkan Working Group chair. “Vulkan 1.1 is a response to prioritized industry requests and shows our commitment to delivering a functional roadmap driven by developer needs.” Vulkan 1.1 will drive increased industry momentum for this new-generation, cross-platform standard for explicit control over GPU acceleration. Vulkan now ships natively on almost all GPU-enabled platforms, including Windows 7, 8.X, 10, Android 7.0+ and Linux, plus Khronos recently announced open source tools to enable Vulkan 1.0 applications to be ported to macOS and iOS. Vulkan has widespread support in leading games engines including Unreal, Unity, Source 2 from Valve, id Tech, CroTeam’s Serious Engine, CryEngine, and Xenko. Vulkan is being used in over 30 cutting-edge games on diverse desktop and mobile platforms, including Doom, Quake, Roblox, The Talos Principle, Dota 2, and is the exclusive API used in AAA titles such as Wolfenstein II and Doom VFR. New functionality in Vulkan 1.1 includes Subgroup Operations that enable highly-efficient sharing and manipulation of data between multiple tasks running in parallel on a GPU. Vulkan 1.1 also enables applications to perform rendering and display operations using resources that they cannot access or copy - for secure playback and display of protected multimedia content. In addition, a wide range of Vulkan 1.0 extensions have been integrated, bringing significant proven functionality into core Vulkan 1.1, including: simultaneous rendering of multiple image views, use of multiple GPUs in a single system, and cross-process API interoperability for advanced rendering and compositing operations often used in demanding applications such as Virtual Reality. These core functionalities also include advanced compute with 16-bit memory access, and support for HLSL memory layouts, and display, processing and compositing of video streams, through direct sampling of YCbCr color formatted textures produced by many video codecs. Integral to the release of Vulkan 1.1 is the new SPIR-V 1.3 specification that expands the capabilities of the Vulkan shader intermediate representation to support subgroup operations and enable enhanced compiler optimizations. The SPIR-V tools ecosystem continues to gain significant momentum with front-end compilers for both GLSL and HLSL, and to expand low-level tooling support from the open source SPIRV-Tools project. “We are excited to see the progress developers have made with the SPIR-V standardized IR. Developers are using the shader language of their choice and a variety of open source compilers to ship their games and applications. The Vulkan tools and ecosystem is evolving rapidly.” said David Neto, Shader compiler team lead at Google. Open source Vulkan development tools continue to evolve alongside the specification. For example, the LunarG Vulkan SDK and tools layers have been upgraded to support Vulkan 1.1, including the Vulkan Layer Factory (VLF) to enable rapid layer development, the Device Simulation Layer to simulate target device capabilities, without requiring actual physical hardware and the new Assistant Layer to guide developers to best practices and to highlight potential application problems. In addition, the RenderDoc frame capture and introspection debugging tool has added full native Vulkan support on Android with help from Khronos members, and improved support for displaying SPIR-V disassembly using SPIRV-Tools and high-level languages through the SPIRV-Cross cross compiler. RenderDoc has also been upgraded to expose native disassembly and profiling information for vendors who support it, and to support the external memory features that now form a core part of Vulkan 1.1. To encourage the collaborative evolution of the Vulkan ecosystem, Khronos has created the public Vulkan Ecosystem Forum to share issues and opportunities, and to coordinate cooperative solutions. The aim of the Forum is to respond to developer feedback and foster cross-functional discussions and engagement between users, tools developers and API designers. Join the conversation at Vulkan Ecosystem on GitHub. Industry Support for Vulkan 1.1 “AMD is very excited about the release of the Vulkan 1.1 specifications. This new iteration of the industry standard builds on its strong foundations and expands its reach by making the API more accessible to developers. New Vulkan 1.1 features such as subgroup access in compute shaders enable console-like optimizations that will empower developers to exert more control on the GPU than ever before,” said Andrej Zdravkovic, corporate vice president of software, AMD. “Vulkan also enriches its connectivity with other APIs by supporting interop operations, and finally enables first-class support for multi-GPU and VR systems. AMD believes that this major upgrade to the API will delight the existing Vulkan community and continue to broaden the user base.” “The new additions in Vulkan 1.1 are a game changer for Vulkan,” said Andrew Richards, CEO of Codeplay Software. “In particular the new subgroup functionality will make a huge difference to our low power, high performance deep learning work.” “Continental is delighted to see how Vulkan continues to move graphics technology forward,” said Dr. Ulrich Kabatek, principal expert graphic systems & 3D visualization at Continental. “We appreciate the improvements it offers for more integrated automotive systems and latency critical applications like augmented automotive clusters.” “As a major contributor to the Vulkan API, Imagination is pleased to see the next evolution of the API in Vulkan 1.1. The new specification offers new ways to exploit GPU parallelism and support for protected content - enabling advanced video processing in Vulkan for things like VR Cinema,” said Graham Deacon, vice president of PowerVR Marketing at Imagination. “We are amongst the first vendors to have a conformant Vulkan implementation, with all of our existing Vulkan-capable GPU IP able to support the new 1.1 standard. The new subgroup and protected content features are fully available in many of our newer cores.” “Intel is committed to open source driver advances for high performance graphics. Vulkan 1.1 is certified on the latest four generations of Intel® Core™ processors, further developing support for virtual and mixed reality,” said Imad Sousou, corporate vice president and general manager of the Open Source Technology Center at Intel Corporation. “Vulkan is vital to NVIDIA’s business as it enables developers to get the best from our GPUs across a wide range of platforms,” said Dwight Diercks, senior vice president of software engineering, NVIDIA. “Our Vulkan 1.1 drivers, with full subgroup functionality, are available for Windows, Linux, and Android on the day of the specification launch. We will continue to take a leadership role within Khronos to ensure Vulkan evolves to meet the needs of developers and the wider industry.” “Vulkan is enabling high fidelity games to make the most out of the capability in mobile, with great titles like Honor of Kings from Tencent running across many Galaxy devices” said Taeyong Kim, VP of Graphics at Samsung Electronics. “Vulkan 1.1 builds on this, adding functionality for VR gaming and 360 video that will enable immersive content on mobile products and VR headsets.” “In our non-gaming business, Vulkan 1.1 is a key factor for our success,” said Norbert Nopper, founder of UX3D, “The possibility to utilize simultaneous rendering and multiple GPUs by default does help us to further optimize our engine.” "VeriSilicon has adopted the latest industry standard low-level GPU API Vulkan 1.1 and is committed to support Vulkan 1.1 across our OpenGL ES 3.1/3.2 class GPUs," said Wei-Jin Dai, executive vice president of VeriSilicon and general manager of VeriSilicon's IP Division. "We are glad to see the new functionalities of Vulkan 1.1 API, the multi-GPU support, the premium content protection, and the advanced compute functionality, etc. to unleash the tremendous potential for a new generation of Vulkan applications. We are particularly excited about the opportunities the Vulkan 1.1 brings to the automotive customers to have fine-grained control over graphics quality of service and highly desired security levels and features.” "Vulkan 1.1 and SPIR-V 1.3 are another step in providing better support for compute, as it adds subgroups, 16-bit numbers and a restricted form of pointers", said Vincent Hindriksen, managing director of StreamHPC. "Adding this to the strong industry support for Vulkan and the recently launched portability project, this allows more types of compute-kernels to be run on more platforms.” More Information More information on Vulkan is available at https://www.khronos.org/vulkan/ All Khronos open source projects are available here: https://github.com/KhronosGroup View full story
  9. 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.
  10. The Khronos™ Group, an open consortium of leading hardware and software companies creating advanced acceleration standards, announces that the Vulkan® Working Group’s Portability Initiative has been working with Khronos members Valve, LunarG, and The Brenwill Workshop to enable Vulkan applications to be ported to Apple platforms. The Vulkan Portability resource page links to a collection of free and open source set of tools, SDKs, and runtime libraries to enable Vulkan development on macOS and deployment on macOS and iOS platforms. Valve is extending Dota 2 using the Vulkan tools on macOS to achieve significantly higher performance than native OpenGL® drivers. Vulkan support for Dota 2 on macOS will be released in the coming months as a free update. “We have been running substantial production loads through the Vulkan tools on Mac, including Dota 2 which is now running faster than the native OpenGL version,” said Pierre-Loup Griffais at Valve. “These efforts are aimed toward reducing development and porting costs for any developer supporting multiple platforms.” The Khronos Vulkan Portability Initiative continues to refine and define a universally portable subset of Vulkan 1.0 that can be run at native performance levels over Metal and DirectX 12 drivers. Released into open source today is the MoltenVK library from The Brenwill Workshop, which translates calls within the Vulkan portable subset to underlying Metal calls on macOS and iOS. MoltenVK uses the open source SPIRV-Cross cross-compiler to translate Vulkan shaders into underlying native code formats. MoltenVK is being made freely available for all developers, with no fees or royalties needed to ship commercial applications. “With MoltenVK, we've worked hard to bring a consistent Vulkan-based API to macOS and iOS while maintaining the performance improvements required by modern game developers," said Bill Hollings, President of The Brenwill Workshop. Also available today is the open source LunarG Vulkan SDK for macOS on LunarXchange, which enables developers to build, run, and debug their Vulkan applications on the Apple Mac platform. The LunarG SDK for macOS provides loader and validation layers, which allows programmers to check their code for correct API usage. LunarG will continue to evolve the macOS SDK to add additional tools and features. “Running Vulkan applications on Apple platforms has been the number one request from developers and today’s release of the MoltenVK runtime and LunarG macOS SDK brings that capability to life,” said Neil Trevett, VP NVIDIA and Khronos Group President. “Developers are invited to download the open source Vulkan Portability tools today and provide feedback via Vulkan Ecosystem GitHub Issue. The Vulkan Portability Initiative will continue to strengthen the infrastructure and tooling around bringing Vulkan capabilities to multiple Metal and DX12 platforms - our long-term goal is to enable portable Vulkan code to be executed on any platform that developers care about.”
  11. The Khronos™ Group, an open consortium of leading hardware and software companies creating advanced acceleration standards, announces that the Vulkan® Working Group’s Portability Initiative has been working with Khronos members Valve, LunarG, and The Brenwill Workshop to enable Vulkan applications to be ported to Apple platforms. The Vulkan Portability resource page links to a collection of free and open source set of tools, SDKs, and runtime libraries to enable Vulkan development on macOS and deployment on macOS and iOS platforms. Valve is extending Dota 2 using the Vulkan tools on macOS to achieve significantly higher performance than native OpenGL® drivers. Vulkan support for Dota 2 on macOS will be released in the coming months as a free update. “We have been running substantial production loads through the Vulkan tools on Mac, including Dota 2 which is now running faster than the native OpenGL version,” said Pierre-Loup Griffais at Valve. “These efforts are aimed toward reducing development and porting costs for any developer supporting multiple platforms.” The Khronos Vulkan Portability Initiative continues to refine and define a universally portable subset of Vulkan 1.0 that can be run at native performance levels over Metal and DirectX 12 drivers. Released into open source today is the MoltenVK library from The Brenwill Workshop, which translates calls within the Vulkan portable subset to underlying Metal calls on macOS and iOS. MoltenVK uses the open source SPIRV-Cross cross-compiler to translate Vulkan shaders into underlying native code formats. MoltenVK is being made freely available for all developers, with no fees or royalties needed to ship commercial applications. “With MoltenVK, we've worked hard to bring a consistent Vulkan-based API to macOS and iOS while maintaining the performance improvements required by modern game developers," said Bill Hollings, President of The Brenwill Workshop. Also available today is the open source LunarG Vulkan SDK for macOS on LunarXchange, which enables developers to build, run, and debug their Vulkan applications on the Apple Mac platform. The LunarG SDK for macOS provides loader and validation layers, which allows programmers to check their code for correct API usage. LunarG will continue to evolve the macOS SDK to add additional tools and features. “Running Vulkan applications on Apple platforms has been the number one request from developers and today’s release of the MoltenVK runtime and LunarG macOS SDK brings that capability to life,” said Neil Trevett, VP NVIDIA and Khronos Group President. “Developers are invited to download the open source Vulkan Portability tools today and provide feedback via Vulkan Ecosystem GitHub Issue. The Vulkan Portability Initiative will continue to strengthen the infrastructure and tooling around bringing Vulkan capabilities to multiple Metal and DX12 platforms - our long-term goal is to enable portable Vulkan code to be executed on any platform that developers care about.” View full story
  12. https://www.phoronix.com/scan.php?page=article&item=vulkan-on-mac&num=1 Isn't there a similar Khronos project for DX12 to Vulkan that would cover Xbox?
  13. Hi, right now building my engine in visual studio involves a shader compiling step to build hlsl 5.0 shaders. I have a separate project which only includes shader sources and the compiler is the visual studio integrated fxc compiler. I like this method because on any PC that has visual studio installed, I can just download the solution from GitHub and everything just builds without additional dependencies and using the latest version of the compiler. I also like it because the shaders are included in the solution explorer and easy to browse, and double-click to open (opening files can be really a pain in the ass in visual studio run in admin mode). Also it's nice that VS displays the build output/errors in the output window. But now I have the HLSL 6 compiler and want to build hlsl 6 shaders as well (and as I understand I can also compile vulkan compatible shaders with it later). Any idea how to do this nicely? I want only a single project containing shader sources, like it is now, but build them for different targets. I guess adding different building projects would be the way to go that reference the shader source project? But how would they differentiate from shader type of the sources (eg. pixel shader, compute shader,etc.)? Now the shader building project contains for each shader the shader type, how can other building projects reference that? Anyone with some experience in this?
  14. I am working on a compute shader in Vulkan which does some image processing and has 1024 * 5=5120 loop iterations (5 outer and 1024 inner) If I do this, I get a device lost error after the succeeding call to queueSubmit after the image processing queueSubmit // Image processing dispatch submit(); waitForFence(); // All calls to submit after this will give the device lost error If I lower the number of loops from 1024 to 256 => 5 * 256 = 1280 loop iterations, it works fine. The shader does some pretty heavy arithmetic operations but the number of resources bound is 3 (one SRV, one UAV, and one sampler). The thread group size is x=16 ,y=16,z=1 So my question - Is there a hardware limit to the number of loop executions/number of instructions per shader?
  15. I wanted to see how others are currently handling descriptor heap updates and management. I've read a few articles and there tends to be three major strategies : 1 ) You split up descriptor heaps per shader stage ( i.e one for vertex shader , pixel , hull, etc) 2) You have one descriptor heap for an entire pipeline 3) You split up descriptor heaps for update each update frequency (i.e EResourceSet_PerInstance , EResourceSet_PerPass , EResourceSet_PerMaterial, etc) The benefits of the first two approaches is that it makes it easier to port current code, and descriptor / resource descriptor management and updating tends to be easier to manage, but it seems to be not as efficient. The benefits of the third approach seems to be that it's the most efficient because you only manage and update objects when they change.
  16. Hello guys, My math is failing and can't get my orthographic projection matrix to work in Vulkan 1.0 (my implementation works great in D3D11 and D3D12). Specifically, there's nothing being drawn on the screen when using an ortho matrix but my perspective projection matrix work fantastic! I use glm with defines GLM_FORCE_LEFT_HANDED and GLM_FORCE_DEPTH_ZERO_TO_ONE (to handle 0 to 1 depth). This is how i define my matrices: m_projection_matrix = glm::perspective(glm::radians(fov), aspect_ratio, 0.1f, 100.0f); m_ortho_matrix = glm::ortho(0.0f, (float)width, (float)height, 0.0f, 0.1f, 100.0f); // I also tried 0.0f and 1.0f for depth near and far, the same I set and work for D3D but in Vulkan it doesn't work either. Then I premultiply both matrices with a "fix matrix" to invert the Y axis: glm::mat4 matrix_fix = {1.0f, 0.0f, 0.0f, 0.0f, 0.0f, -1.0f, 0.0f, 0.0f, 0.0f, 0.0f, 1.0f, 0.0f, 0.0f, 0.0f, 0.0f, 1.0f}; m_projection_matrix = m_projection_matrix * matrix_fix; m_ortho_matrix = m_ortho_matrix * matrix_fix; This fix matrix works good in tandem with GLM_FORCE_DEPTH_ZERO_TO_ONE. Model/World matrix is the identity matrix: glm::mat4 m_world_matrix(1.0f); Then finally this is how i set my view matrix: // Yes, I use Euler angles (don't bring the gimbal lock topic here, lol). They work great with my cameras in D3D too! m_view_matrix = glm::yawPitchRoll(glm::radians(m_rotation.y), glm::radians(m_rotation.x), glm::radians(m_rotation.z)); m_view_matrix = glm::translate(m_view_matrix, -m_position); That's all guys, in my shaders I correctly multiply all 3 matrices with the position vector and as I said, the perspective matrix works really good but my ortho matrix displays no geometry. EDIT: My vertex data is also on the right track, I use the same geometry in D3D and it works great: 256.0f units means 256 points/dots/pixels wide. What could I possibly be doing wrong or missing? Big thanks guys any help would be greatly appreciated. Keep on coding, cheers.
  17. My team and I are developing a game engine! We would like as much help as possible. The project is currently hobby only, but pay will be appropriately rolled out to those who work on the engine. people we are looking for are: Network Programmer Artist For User Interface Physics Programmer Graphics Programmer Prerequisites wanted, but not needed, are: Intermediate C++ knowledge 1 Yr in Game development Industry Thank you for your intrest in the project. You can contact me at my email: thesargkyle@gmail.com or my discord: TheSargKyle#8978
  18. (Posted this in graphics forum too, which was perhaps the wrong forum for it) Hey, I was wondering if on mobile development (Android mainly but iOS as well if you know of it), if there is a GPUView equivalent for whole system debugging so we can figure out if the CPU/GPU are being pipelined efficiently, if there are bubbles, etc. Also slightly tangent question, but do mobile GPU's have a DMA engine exposed as a dedicated Transfer Queue for Vulkan? Thanks!
  19. Hey, I was wondering if on mobile development (Android mainly but iOS as well if you know of it), if there is a GPUView equivalent for whole system debugging so we can figure out if the CPU/GPU are being pipelined efficiently, if there are bubbles, etc. Also slightly tangent question, but do mobile GPU's have a DMA engine exposed as a dedicated Transfer Queue for Vulkan?
  20. I am working on a project which needs to share render targets between Vulkan and DirectX12. I have enabled the external memory extension and now allocate the memory for the render targets by adding the VkExportMemoryInfoKHR to the pNext chain of VkMemoryAllocateInfo. Similarly I have added the VkExternalMemoryImageCreateInfo to the pNext chain of VkImageCreateInfo. After calling the get win32 handle function, I get some handle pointer which is not null (I assume it is valid). VkExternalMemoryImageCreateInfoKHR externalImageInfo = {}; if (gExternalMemoryExtensionKHR) { externalImageInfo.sType = VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_IMAGE_CREATE_INFO_KHR; externalImageInfo.pNext = NULL; externalImageInfo.handleTypes = VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR | VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR | VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT_KHR | VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_BIT_KHR | VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_KMT_BIT_KHR | VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D12_HEAP_BIT_KHR | VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D12_RESOURCE_BIT_KH imageCreateInfo.pNext = &externalImageInfo; } vkCreateImage(...); VkExportMemoryAllocateInfoKHR exportInfo = { VK_STRUCTURE_TYPE_EXPORT_MEMORY_ALLOCATE_INFO_KHR }; exportInfo.handleTypes = VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR | VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR | VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT_KHR | VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_BIT_KHR | VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_KMT_BIT_KHR | VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D12_HEAP_BIT_KHR | VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D12_RESOURCE_BIT_KHR; memoryAllocateInfo.pNext = &exportInfo; vkAllocateMemory(...); VkMemoryGetWin32HandleInfoKHR info = { VK_STRUCTURE_TYPE_MEMORY_GET_WIN32_HANDLE_INFO_KHR, NULL }; info.memory = pTexture->GetMemory(); info.handleType = VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D12_RESOURCE_BIT_KHR; VkResult res = vkGetMemoryWin32HandleKHR(vulkanDevice, &info, &pTexture->pSharedHandle); ASSERT(VK_SUCCESS == res); Now when I try to call OpenSharedHandle from a D3D12 device, it crashes inside nvwgf2umx.dll with the integer division by zero error. I am now lost and have no idea what the other handle types do. For example: How do we get the D3D12 resource from the VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR handle? I also found some documentation on this link but it doesn't help much. https://javadoc.lwjgl.org/org/lwjgl/vulkan/NVExternalMemoryWin32.html This is all assuming the extension works as expected since it has made it to the KHR
  21. I am trying to get vulkan on android working and have run into a big issue. I don't see any validation layers available. I have tried linking their libraries into mine but still no layers. I have tried compiling it into a library of my own but the headers for it are all over the place. Unfortunately , google's examples and tutorials are out of date and don't work for me. Any idea what I have to do to get those layers to work?
  22. It seems like nobody really knows what is the correct behavior after window minimizes in Vulkan. I have looked at most of the examples (Sascha Willems, GPUOpen,...) and all of them crash after the window minimize event with the error VK_ERROR_OUT_OF_DATE either with an assertion during acquire image or after calling present. This is because we have to recreate the swap chain. I tried this but then Vulkan expects you to provide a swap chain with extents { 0, 0, 0, 0 }, but now if you try to set the viewport or create new image views with extents { 0, 0, 0, 0 }, Vulkan expects you to provide non-zero values. So now I am confused. Should we just do nothing after a window minimize event? No rendering, update, ...?
  23. Hi all, First time poster here, although I've been reading posts here for quite a while. This place has been invaluable for learning graphics programming -- thanks for a great resource! Right now, I'm working on a graphics abstraction layer for .NET which supports D3D11, Vulkan, and OpenGL at the moment. I have implemented most of my planned features already, and things are working well. Some remaining features that I am planning are Compute Shaders, and some flavor of read-write shader resources. At the moment, my shaders can just get simple read-only access to a uniform (or constant) buffer, a texture, or a sampler. Unfortunately, I'm having a tough time grasping the distinctions between all of the different kinds of read-write resources that are available. In D3D alone, there seem to be 5 or 6 different kinds of resources with similar but different characteristics. On top of that, I get the impression that some of them are more or less "obsoleted" by the newer kinds, and don't have much of a place in modern code. There seem to be a few pivots: The data source/destination (buffer or texture) Read-write or read-only Structured or unstructured (?) Ordered vs unordered (?) These are just my observations based on a lot of MSDN and OpenGL doc reading. For my library, I'm not interested in exposing every possibility to the user -- just trying to find a good "middle-ground" that can be represented cleanly across API's which is good enough for common scenarios. Can anyone give a sort of "overview" of the different options, and perhaps compare/contrast the concepts between Direct3D, OpenGL, and Vulkan? I'd also be very interested in hearing how other folks have abstracted these concepts in their libraries.
  24. Hi, In Vulkan you have render passes where you specify which attachments to render to and which to read from, and subpasses within the render pass which can depend on each other. If one subpass needs to finish before another can begin you specify that with a subpass dependency. In my engine I don't currently use subpasses as the concept of the "render pass" translates roughly to setting a render target and clearing it followed by a number of draw calls in DirectX, while there isn't really any good way to model subpasses in DX. Because of this, in Vulkan, my frame mostly consists of a number of render passes each with one subpass. My question is, do I have to specify dependencies between the render passes or is that needed only if you have multiple subpasses? In the Vulkan Programming Guide, chapter 13 it says: "In the example renderpass we set up in Chapter 7, we used a single subpass with no dependencies and a single set of outputs.”, which suggests that you only need dependencies between subpasses, not between render passes. However, the (excellent) tutorials at vulkan-tutorial.com have you creating a subpass dependency to "external subpasses" in the chapter on "Rendering and presentation", under "Subpass dependencies": https://vulkan-tutorial.com/Drawing_a_triangle/Drawing/Rendering_and_presentation even if they are using only one render pass with a single subpass. So, in short; If I have render pass A, with a single subpass, rendering to an attachment and render pass B, also with a single subpass, rendering to that same attachment, do I have to specify subpass dependencies between the two subpasses of the render passes, in order to make render pass A finish before B can begin, or are they handled implicitly by the fact that they belong to different render passes? Thanks!
  25. I am looking at the SaschaWillems subpass example for getting some insight into subpass depdendencies but its hard to understand whats going on without any comments. Also there is not a lot of documentation on subpass dependencies overall. Looking at the code, I can see that user specifies the src subpass, dst subpass and src state, dst state. But there is no mention of which resource the dependency is on. Is a subpass dependency like a pipeline barrier. If yes, how does it issue the barrier? Is the pipeline barrier issued on all attachments in the subpass with the input src and dst access flags? Any explanation will really clear a lot of doubts on subpass dependencies. Thank you
  • Advertisement