Add Advanced Vulkan Compute tutorial #334
Conversation
…L, and conclusion Add comprehensive documentation covering Vulkan Memory Model (availability/visibility/domain operations), shared memory (LDS) with bank conflict details, memory consistency with GroupMemoryBarrierWithGroupSync, OpenCL C to SPIR-V pipeline (clspv), kernel portability guidelines, clvk layering, and tutorial conclusion. Include navigation entries for all new compute architecture sections.
Add missing blank lines after list introduction paragraphs to ensure proper Markdown rendering of bullet points in "Developing for advanced compute" and "Community and Resources" sections.
| The SYCL ecosystem is diverse, but for Vulkan developers, two main implementations stand out: | ||
|
|
||
| 1. **AdaptiveCpp**: A flexible, multi-backend implementation that can target Vulkan, CUDA, ROCm, and Level Zero. It is the primary focus for cross-vendor Vulkan compatibility. | ||
| 2. **Intel oneAPI DPC{pp}**: While primarily focused on Intel hardware, it can target other backends (like CUDA and ROCm) through "plugin" architectures, though its Vulkan support is often handled through interoperability rather than a native backend. |
There was a problem hiding this comment.
As far as i'm aware neither DPC++ or AdaptiveCpp support Vulkan today, can you reference where you're getting this information from? For ACPP in particular this is still WIP AdaptiveCpp/AdaptiveCpp#2009
bashbaug
left a comment
bashbaug
left a comment
There was a problem hiding this comment.
This is a nice tutorial but I think the way the "OpenCL on Vulkan" and "SYCL on Vulkan" topics are presented is a little confusing. If an OpenCL on Vulkan implementation has done its job, it would look and behave like any other OpenCL implementation. Note that we considered at one point whether OpenCL would need a "Vulkan profile" or similar for a layered implementation, but this does not seem to be required, and conformant implementations of OpenCL over Vulkan are shipping.
Would it make more sense to focus more on the advanced Vulkan compute features that these layered implementations are using, instead? The current chapter about unified shared memory is a good example. Are there other similar features that could be described in this tutorial?
|
Hi Ben, Thanks for the review. I can certainly remove the OpenCL and SYCL chapters and add more advanced features. We do have a VulkanML tutorial that covers some of the more advanced compute things that might go there instead (you can find that one in the gitlab MR for Vulkan-Tutorial. I was hoping to provide a method of exposing developers learning Vulkan to OpenCL and SYCL, This seemed like the right topic area to provide such intersection point. However, I don't feel like it would hurt Vulkan's compute tutorial as a concept to remove OpenCL and SYCL entirely. Alternatively, I could add more details about both and make it a longer tutorial. Do you have guidance for what you think would make sense? |
I re-read this. I see what you're asking I think. Yes. Lemme iterate a bit and I'll come up with more things to add in for the similar feature set. |
3 participants
sections on memory models OpenCL interoperation and SYCL interoperation.
Add comprehensive documentation covering Vulkan Memory Model (availability/visibility/domain operations), shared memory (LDS) with bank conflict details, memory consistency with GroupMemoryBarrierWithGroupSync, OpenCL C to SPIR-V pipeline (clspv), kernel portability guidelines, clvk layering, and tutorial conclusion. Include navigation entries for all new compute architecture sections.