AnKi’s GPU memory management system was introduced alongside Vulkan nine years ago, but the transition to GPU-driven rendering and the introduction of a render-graph fundamentally changed the way GPU memory is handled. In this blog post we will look at how the system evolved over the years and as a bonus compare memory statistics across GPUs from different vendors. As always: Whatever you read here does not represent my current or future employers.
Continue reading “GPU memory management in AnKi”Minimalist ray-tracing leveraging only acceleration structures
AnKi has had ray-tracing support for quite some time. Beyond managing acceleration structures, the engine uses VK_KHR_ray_tracing_pipeline/DXR 1.0 for shadows (soon deprecated), indirect diffuse, and indirect specular. Upon initialization, the engine reads pre-compiled shader binary blobs and creates ray-tracing pipelines containing a number of ray-generation shaders, one or more miss shaders, and several hit shaders. Currently, two RT libraries are built: one for RT shadows and one for indirect RT. When the engine loads materials, the materials select the appropriate hit shaders, which are then forwarded to the shader binding table during rendering. This approach works well, as materials have the flexibility to choose different RT shaders, just as they choose different combinations of vertex and pixel shaders.
Continue reading “Minimalist ray-tracing leveraging only acceleration structures”GPU driven rendering in AnKi
This time I decided to would try something different and do a video presentation instead of a blog post. There were a lot of things to cover and a video presentation seemed better.
Anyway, here is the video:
And here the link the the presentation: https://docs.google.com/presentation/d/1tsGjwZmP2mZBNyURNN4-XYsgJxfsG6omaC3w5ZQXzr4/edit#slide=id.g2155b36a3d3_0_0
Workarounds for issues with mesh shaders + Vulkan + HLSL
TL;DR: If using per-primitive in/out in mesh shaders in Vulkan and in HLSL/DXC you need to manually decorate variables and struct members using SPIR-V intrinsics. See how at the bottom.
This is going to be a quick post to raise awareness to a difficult to track bug with mesh shaders in Vulkan when using HLSL. Hopefully this will save some time to the next poor soul that bumps into this.
Continue reading “Workarounds for issues with mesh shaders + Vulkan + HLSL”Parsing and rewriting SPIR-V
SPIR-V is a binary language that describes the GPU shader code for the Vulkan and OpenCL APIs. For most graphics programmers SPIR-V is a completely opaque binary blob that they don’t have to touch or know much about. Someone can use their preferred compiler to translate GLSL or HLSL to SPIR-V, can use SPIRV-Tools to optimize or assemble/disassemble, can use SPIRV-Cross or SPIRV-Reflect to perform shader reflection and finally they can use SPIRV-Cross to cross compile SPIR-V to some high level language. There is enough tooling out there to not have to worry about the internals. SPIR-V is very well defined and quite simple to understand and manipulating it without the use of 3rd part tools is not something to feel intimidated by and this is the point I’m trying to make with this post.
Continue reading “Parsing and rewriting SPIR-V”GPU driven rendering in AnKi: A high level overview
For the last few months AnKi underwent a heavy re-write in order to enable GPU driven rendering. This post will quickly go through the changes and the design without diving too deep into details. There will be another post (or maybe video) with all the implementation details.
Continue reading “GPU driven rendering in AnKi: A high level overview”Random thoughts after moving from GLSL to HLSL
AnKi always had its shaders written in GLSL because it started as an OpenGL engine. Recently I decided to start rewriting them from GLSL to HLSL with one of the main motivations being that GLSL, as a language, has stopped evolving and it’s missing modern features. Sure, there are new extensions added to GLSL all the time but those extensions expose new Vulkan functionality, they don’t add new syntax to the language. So let’s dive into some random thoughts around HLSL that are tailored to Vulkan and SPIR-V.
Continue reading “Random thoughts after moving from GLSL to HLSL”Porting AnKi to Android… again after ~8 years
I think it was 8 or 9 years ago when AnKi was first ported to Android for a demo competition and I remember the process being quite painful. Building native projects for Android was a hack, the micro differences between OpenGL ES and desktop OpenGL required compromises, GLSL related issues were a constant pain (compilation issues, bugs, shader reflection differences between implementations etc). These and more issues were the reason I left the Android port to rot and eventually remove from the codebase.
All that changed 10 months ago when I decided to re-port AnKi to Android. But if it was so painful why try again? The main reason is that the ecosystem had improved over the years. Android tooling for native code development (basically C/C++) got better but the biggest motivator was Vulkan. I was optimistic that there will be less issues with Vulkan this time around. At the end of the day was it less painful? The short answer is “yes” but if you want the long answer continue reading.
Continue reading “Porting AnKi to Android… again after ~8 years”