r/vulkan

"Unlock the GPU as a general-purpose engine, not just a rasterizer."

This series takes you past `vkCmdDispatch` and into how compute actually executes on real hardware — occupancy, latency hiding, the Vulkan memory model, and subgroup operations that let invocations talk to each other without touching global memory.

* Vulkan 1.4 scalar layouts, shared memory (LDS), and memory consistency deep-dives

* Subgroup partitioning and non-uniform indexing — the "hidden power" most tutorials skip

* Run OpenCL kernels on top of Vulkan for a heterogeneous compute ecosystem

* Indirect dispatch, GPU-driven pipelines, and async compute orchestration

* Cooperative matrices, performance auditing, and AI-assisted compute diagnostics

* Dedicated coverage of mobile and embedded compute constraints

https://docs.vulkan.org/tutorial/latest/Advanced_Vulkan_Compute/introduction.html

Inference run everywhere. Training still means CUDA and a framework stack. I thought that was a convention, not a law of physics, so I built sym_engine: a single C++ binary (~6,000 lines + 21 Vulkan compute shaders) that pretrains, finetunes, evals, and runs inference on any Vulkan-capable GPU. No autograd — gradients are derived, forward and backward both visible in the source.

What I've actually verified, not what I hope: training on an RTX 5090, an AMD APU, and an Intel iGPU - the video shows two of them training simultaneously on one machine, CPU at 1%. Same binary, same shaders, fp32: RTX 5090 - 10.4M model, ~44,000 tok/s. Intel iGPU (64 EU) - 1.2M model, ~50,000 tok/s; 10.4M model, ~1,800 tok/s. The spread is the hardware's bandwidth, not the software — when the model fits the silicon's budget, an iGPU trains at desktop-GPU pace. Physics can't fit what won't fit. Largest trained so far: 318M params 32 GB VRAM

The target is edge devices - that was the goal from day one. To prove it, I gamified the engine into an Android app demoed in the link also: (CPU path on-device; the Adreno Vulkan path is in progress) a virtual pet whose brain is its own 120K-parameter model, training and inferring in real time on the phone as you play. Its save file is literally the weights. That's the point of the architecture: models that learn where they run - on-device, offline, no cloud, no API.

What it's not: a llama.cpp competitor. That runs other people's models fast; this grows your own small models on whatever silicon you have. No KV cache by design - training and inference share one code path. Known limits: single GPU per instance, Python needed once for tokenizer prep.

AGPL-3.0, sole copyright, not accepting contributions but forks welcome. Repo: https://github.com/chrismelanov85/SYM\_ENGINE

I have questions on start of exections of cmds

We all know that cmd2 can start executing only after cmd1 .

If cmd2 is recorded latter than cmd1

If there are 2 different subpasses in a renderpass

Can cmds in subpass 1 start before cmds in subpass 0 within that render pass?

Or they also have the implicit ordering?

I recently started a little side quest of learning the ins and outs of modern C++ and I was wondering if the new features work with Vulcan and would it make any Vulkan program run faster?

Also feel free to share some C++ and Vulkan optimisations you discovered or provide a link to some example programs.

I'm working on a fully GPU-driven Vulkan renderer using mesh shaders and vkCmdDrawMeshTasksIndirectCountEXT.

I wanted to collect some frame statistics with a VK_QUERY_TYPE_PIPELINE_STATISTICS query pool. The classic statistics (fragment, clipping, etc.) work fine and have basically no measurable overhead.

However, as soon as I enable:

VK_QUERY_PIPELINE_STATISTIC_TASK_SHADER_INVOCATIONS_BIT_EXT
VK_QUERY_PIPELINE_STATISTIC_MESH_SHADER_INVOCATIONS_BIT_EXT

GPU performance tanks.

Without these counters my frame is around 1–1.5 ms. With them enabled, more complex scenes jump to ~80 ms.

It seems to scale with the amount of work done by the task/mesh shaders more visible objects means more task/mesh shader invocations, and the performance degradation becomes much worse.

My main question is: is this expected? Do these invocation counters force the driver onto some slower path or disable optimizations to guarantee accurate statistics?

I'm mostly interested in whether this is a known limitation of the extension or an NVIDIA driver behavior.

I could easily implement my own counters using atomics/subgroup operations in the shaders, so I have a workaround. I just assumed the built-in pipeline statistics would be the cleaner solution.

System:

• RTX 4060
• Windows 11
• NVIDIA Driver 610.62
• Vulkan SDK 1.4.350.1

 

Has anyone else seen this?

I shelved a Reverse-Z branch in my engine (stuck on OpenGL 4.1 for macOS, no glClipControl), and the roadblock sent me down the rabbit hole of actually understanding why it works instead of just how to implement it.

I ended up writing about what I learned with interactive graphs and all:
https://www.shlom.dev/articles/reverse-z-perfect-hack/

Happy to hear where I got things wrong or imprecise.

Hopefully this helps someone else :)

I’m an older programmer who has loved real-time graphics and programming for decades. I’m not a superhero dev, and I’ve never worked solely as a graphics programmer, though I’d love to. My professional work tends to sit nearby: engine work, tooling, automation, build systems, dev ops, and general C++/game-tech-adjacent work.

But the goal has always been the same: keep learning and keep moving closer to real-time graphics.

Learning this stuff feels like the slow slog toward becoming a master wizard. There is always another layer: Vulkan, shaders, lighting, PBR, shadows, deferred rendering, ray tracing, GI, post-processing, GPU performance. There are always smarter and more educated people. That’s intimidating, but also part of the appeal.

I’m building a small C++ rendering portfolio project focused on Vulkan, renderer architecture, shaders, lighting, shadows, and eventually path tracing. I use ChatGPT as part of that process, but deliberately only through the browser. I don’t give AI direct access to my repo, editor, terminal, build system, or files. I manually copy small snippets, errors, questions, and design notes back and forth because I want to stay the Sapien in the middle.

https://preview.redd.it/dpprhhh9nqah1.jpg?width=1375&format=pjpg&auto=webp&s=dcca6997c9e4202c52903d631a3d387ef22270d3

For me, the point is not to outsource the work. It’s to accelerate learning while still owning the result. Often AI-suggested code gets reworked through discussion until it fits my project, matches my style, and most importantly: I understand it well enough to explain, debug, modify, and rewrite.

Reactions online seem very polarized. People either love AI or hate it. I think there’s a useful middle ground: have an AI usage policy, be transparent about it, and back it up with design notes, small commits, screenshots, RenderDoc notes, and explanations of what you actually validated yourself.

I’d love to see more people think about their own AI usage policy when sharing online work.

Does a transparent AI policy make you trust a graphics/programming portfolio more, or less?

p.s. AI was consulted on the creation of this post.

https://preview.redd.it/2jmrdefviwah1.png?width=696&format=png&auto=webp&s=0780c05962c9a13ecb9ddca1ca7cee7bb158e0d2

Any tips on how to read and interpret the output from the umr utility to monitor the user mode registers?

I am trying to determine the bottleneck in my compute shader.

I had a question, what all commands do pipeline bariers affect.
so if we have a command buffer

cmd1 cmd2 bar1 cmd3 cmd4 bar2 cmd5 cmd6

so can bar1 apply its synchronization scopes to cmd5 and cmd6??
and can bar2 apply its synchronizationscopes to cmd1 and cmd2??

I know that if the barrier is in a subpass of a renderpass then its scope of synchronization will not extend beyond the bounds of that subpass.

also why do we even need renderpasses when we have pipeline barriers?
are renderpasses more optimized in cache control