GLSL
clspv
Our great sponsors
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
GLSL
-
Is there a good resource for mapping GLSL extensions to Vulkan extensions/features
You're looking for this repo
-
GLSL shaders resources
You have access to physical (u64) global memory pointers through buffer_reference in GLSL, note you should be using buffer_reference2
-
New Blog: Introducing Ray Tracing Position Fetch Extension
On April 27, 2023 the Vulkan® Ray Tracing TSG released the VK_KHR_ray_tracing_position_fetch extension, which exposes the ability to fetch vertex positions from an acceleration structure hit when tracing rays. The SPIR-V SPV_KHR_ray_tracing_position_fetch and GLSL GL_EXT_ray_tracing_position_fetch extensions have also been released to provide SPIR-V and GLSL support for this functionality.
- Where can I find and what is with there being practically no documentation for GL_EXT_spirv_intrinsics and spirv_by_reference?
-
Thoughts?
You can also have general extensions that are only supported on some hardware, for instance NVIDIA supports all of these extensions on OpenGL that add support for Vulkan's thread subgroup operations while AMD only supports these extensions and a few others that add support for similar features to the extension that NVIDIA supports, but with way more restrictions.
-
You Can Use Vulkan Without Pipelines Today - Khronos Blog
GL_NV_ray_tracing is a vendor extension, but it does exist.
-
Porting from DXR/HLSL to Vulkan Ray Tracing Extension/GLSL
According to this document, one should be able to extract those values through
-
Learning Modern 3D Graphics Programming
The reports of my death are greatly exaggerated
https://github.com/KhronosGroup/GLSL/blob/master/extensions/...
-
Is there any way to index an array of bindless textures based on gl_InstanceID?
I don't think there's away. For Vulkan, there's GL_EXT_nonuniform_qualifier which allows you to index with gl_InstanceIndex but AFAIK it's not available for OpenGL.
-
Drawing multiple separate textures in one draw call
AMD hardware works a little differently, and for that you have to write a waterfall loop with subgroup instructions to get the correct behavior (since GL_EXT_nonuniform_qualifier doesn't exist in OpenGL GLSL). The loop might look like this (you would use it the same way as NonUniformEXT in Vulkan GLSL).
clspv
-
Vcc – The Vulkan Clang Compiler
See https://github.com/google/clspv for an OpenCL implementation on Vulkan Compute. There are plenty of quirks involved because the two standards use different varieties of SPIR-V ("kernels" vs. "shaders") and provide different guarantees (Vulkan Compute doesn't care much about numerical accuracy). The Mesa folks are also looking into this as part of their RustiCL (a modern OpenCL implementation) and Zink (implementing OpenGL and perhaps OpenCL itself on Vulkan) projects.
-
AMD's CDNA 3 Compute Architecture
Vulkan Compute backends for numerical compute (as typified by both OpenCL and SYCL) are challenging, you can look at Google's cspv https://github.com/google/clspv project for the nitty gritty details. The lowest-effort path is actually via some combination of Rocm (for hardware that AMD bothers to support themselves) and the Mesa project's Rusticl backend (for everything else).
-
WSL with CUDA Support
D3D12 has more compute features than Vulkan has. It works out for DXVK because games often don’t use those, but it’ll cause much more issues with CLon12.
By the way, if you are ready to have a _limited_ implementation without a full feature set because of Vulkan API limitations, clvk is a thing. The list of limitations of that approach is at https://github.com/google/clspv/blob/master/docs/OpenCLCOnVu...
tldr: Vulkan and OpenCL SPIR-V dialects are different, and the former has significant limitations affecting this use case
- Resources for Vulkan GPGPU searched
-
Low overhead C++ interface for Apple's Metal API
For OpenCL on DX12, the test suite doesn't pass yet. Every Khronos OpenCL 1.2 CTS test passes on at least one hardware driver, but there's none that pass them all. That is why CLon12 isn't submitted to Khronos's compliant products list yet.
The pointer semantics that Vulkan has aren't very amenable to implementing a compliant OpenCL implementation on top of. There are also some other limitatons: https://github.com/google/clspv/blob/master/docs/OpenCLCOnVu....
-
[Hardware Unboxed] - Apple M1 Pro Review - Is It Really Faster than Intel/AMD?
Vulkan is much more limited, notably because of Vulkan's SPIR-V dialect limitations. That makes a compliant OpenCL 1.2 impl on top of Vulkan impossible. (see: https://github.com/google/clspv/blob/master/docs/OpenCLCOnVulkan.md)
-
Cross Platform GPU-Capable Framework?
OpenCL really is your best bet for a cross-platform GPU-capable framework. OpenCL 3.0 cleared out a lot of the cruft from OpenCL 2.x so it's seeing a lot more adoption. The most cross-platform solution is still OpenCL 1.2, largely for MacOS, but OpenCL 3.0 is becoming more and more common for Windows and Linux and multiple devices. Even on platforms without native OpenCL support there are compatibility layers that implement OpenCL on top of DirectX (OpenCLOn12) or Vulkan (clvk and clspv).
What are some alternatives?
Rust-CUDA - Ecosystem of libraries and tools for writing and executing fast GPU code fully in Rust.
OpenCLOn12 - The OpenCL-on-D3D12 mapping layer
vuh - Vulkan compute for people
kompute - General purpose GPU compute framework built on Vulkan to support 1000s of cross vendor graphics cards (AMD, Qualcomm, NVIDIA & friends). Blazing fast, mobile-enabled, asynchronous and optimized for advanced GPU data processing usecases. Backed by the Linux Foundation.
ocl - OpenCL for Rust
alpaka - Abstraction Library for Parallel Kernel Acceleration :llama:
VkFFT - Vulkan/CUDA/HIP/OpenCL/Level Zero/Metal Fast Fourier Transform library
MoltenVK - MoltenVK is a Vulkan Portability implementation. It layers a subset of the high-performance, industry-standard Vulkan graphics and compute API over Apple's Metal graphics framework, enabling Vulkan applications to run on macOS, iOS and tvOS.
SPIRV-VM - Virtual machine for executing SPIR-V
build_all - GO HERE FIRST: nvpro-samples overview
clvk - Implementation of OpenCL 3.0 on Vulkan