Jump to content
  • Advertisement

Search the Community

Showing results for tags 'Vulkan'.

The search index is currently processing. Current results may not be complete.


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

  • Audio
  • Visual Arts
  • Programming
  • Writing

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
  • Community
    • 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
  • Topical
    • Virtual and Augmented Reality
    • News
  • 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
  • For Beginners's Forum

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.

Product Groups

  • GDNet+
  • Advertisements
  • GameDev Gear

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me


Website


Role


Twitter


Github


Twitch


Steam

Found 127 results

  1. Hi everyone, I think my question boils down to "How do i feed shaders?" I was wondering what are the good strategies to store mesh transformation data [World matrices] to then be used in the shader for transforming vertices (performance being the priority ). And i'm talking about a game scenario where there are quite a lot of both moving entities, and static ones, that aren't repeated enough to be worth instanced drawing. So far i've only tried these naive methods : DX11 : - Store transforms of ALL entities in a constant buffer ( and give the entity an index to the buffer for later modification ) - Or store ONE transform in a constant buffer, and change it to the entity's transform before each drawcall. Vulkan : - Use Push Constants to send entity's transform to the shader before each drawcall, and maybe use a separate Device_local uniform buffer for static entities? Same question applies to lights. Any suggestions?
  2. 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 ?
  3. 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.
  4. 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.
  5. BearishSun

    New C++14 GameDev Framework Released

    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.
  6. BearishSun

    New C++14 GameDev Framework Released

    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
  7. 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.
  8. 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?
  9. 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?
  10. 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?
  11. 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.
  12. 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.
  13. 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
  14. 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); }
  15. 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.
  16. 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?
  17. 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.
  18. khawk

    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
  19. khawk

    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
  20. 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?
  21. 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
  22. 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.”
  23. 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?
  24. 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?
  25. I need to index into a texture array using indices which are not dynamically uniform. This works fine on NVIDIA chips but you can see the artifacts on AMD due to the wavefront problem. This means, a lot of pixel invocations get the wrong index value. I know you fix this by using NonUniformResourceIndex in hlsl. Is there an equivalent for Vulkan glsl? This is the shader code for reference. As you can see, index is an arbitrary value for each pixel and is not dynamically uniform. I fix this for hlsl by using NonUniformResourceIndex(index) layout(set = 0, binding = 0) uniform sampler textureSampler; layout(set = 0, binding = 1) uniform texture2D albedoMaps[256]; layout(location = 0) out vec4 oColor; void main() { uint index = calculate_arbitrary_texture_index(); vec2 texCoord = calculate_texcoord(); vec4 albedo = texture(sampler2D(albedoMaps[index], textureSampler), texCoord); oColor = albedo; } Thank you
  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!