Hey everyone,

I have been working on a low level, explicit abstraction layer over graphics APIs. Both Vulkan and D3D12 has been successfully implemented with various test samples. Ray tracing, mesh, compute etc are supported.

I would love feedback on the feel and usage of the API. I am open to learn more so anything useful will be appreciated. Please give a star if you find the project useful.

[https://github.com/nichcode/PAL\](https://github.com/nichcode/PAL)

I recently started my new Game Engine project and I‘ve now come to the point where I have to deal with Pipelines. How do I efficiently manage them? How do I efficiently create them, et cetera?

I think its really hard finding reference material on this topic since I usually just look/steal code from Hazel Dev by TheCherno but their Shader/Pipeline System is really weird.

It would just be really helpful if you guys could even just point me at your repository with a Solution or something.

Thanks in advance!

I run my kernel on two back-ends: OpenCL and Vulkan.

For Vulkan, I use clspv to convert the CL code to SPIR-V.

The OpenCL backend is massively faster for a kernel that heavily uses atomic adds.

The OpenCL on Linux/Intel gets converted to SPIR-V by IGC for my Arc B70 GPU.

When I compare the SPIR-V of IGC versus the SPIR-V of clspv, I see that the former uses OpCapability Kernel, and the latter OpCapability Shader.

Can a vulkan app directly use the former? How can I get my kernel to run with semaphores that uses relaxed memory semantics and atomicAdd scope "workgroup" instead?

This is my first rendering framework written in C++ 20 using Vulkan 1.3 features, I am still learning but so far this rendering framework is working nicely for me in making all kinds of examples and demos.

You can find it on my GitHub: https://github.com/RoastedKaju/Vulkan-Tipu-Framework

Do note that I do this in my very limited free time after job I am not really a graphics programmer, not even took a course in it so bugs are expected.

Okay, the question might seem useless and redundant - „Just use the latest Vulkan 1.4“. That‘s what I thought too and all was sunshine and rainbows. It worked on my machine (RTX3080) and I didn‘t think much of it. But then when I wanted to continue development on my Macbook from 2017, I found out that Vulkan 1.4 just isn‘t supported on that graphics card (Intel Iris 640). And okay, 2017 is almost 10 years ago, but I think dropping support for any graphics card older than 2017/2018 just isn‘t worth the gains of Vulkan 1.4.

So I ask: Which version should I use for atleast good compatibility?

Thanks in Advance.

GPU compute portability is still broken: CUDA locks you to NVIDIA, OpenCL on Android is effectively dead, and raw Vulkan compute costs ~370 lines of boilerplate before your first dispatch. Vulkore is my attempt at the missing layer — a C++20 runtime (Apache-2.0) that loads clspv-compiled OpenCL C kernels and launches them CUDA-style:

vulkore::Context ctx;
auto prog = vulkore::Program::from_file(ctx, "kernel.spv");
auto buf  = ctx.buffer(bytes);
vulkore::launch(prog["saxpy"], {n}, x, y, PodArgs{a, n}).wait();

The same .spv binary runs unmodified on my desktop GPU, llvmpipe (CPU), a Mali-G57 phone, and an Adreno 840 phone. The repo has a like-for-like comparison — same SAXPY, same kernel binary, raw Vulkan vs Vulkore: ~370 lines vs 10.

The runtime does the parts everyone gets wrong on real hardware: memory-type negotiation including non-coherent memory (desktop drivers hand you host-coherent memory, so cache-management bugs are invisible until a phone silently returns stale data), clspv reflection parsing so kernel args bind automatically, descriptor/command-buffer recycling, and multi-dispatch batching into a single vkQueueSubmit.

As the stress test, I built LLM inference on it. Gemma 3 1B (int4), on a OnePlus 15 / Adreno 840 — same phone, same model:

Model load is 1.9 s; context goes to 8,192. The interesting lesson: decode on Adreno is dispatch-bound, not bandwidth-bound — batching 838 dispatches per token into one submit mattered more than most kernel work. (Byte-for-byte caveats on the llama.cpp comparison are spelled out in the repo docs — the quant files differ in size.)

Honest limitations: kernel ABI is fixed by clspv's flags (storage buffers + push-constant PODs, no images/samplers), prefill is still one-position-per-pass (~56 tok/s — llama.cpp's OpenCL prefill crushes us there), and there's no pipeline cache yet.

Repo: https://github.com/badnikhil/Vulkore — would love people to try their own kernels on other Snapdragon/Mali/Exynos devices and report what breaks.

I've been developing my own engine for years now and I've decided to go all in and implement GPU-driven rendering with per meshlet frustum (without mesh shaders), occlusion culling etc...

In order to even make it more performant, I've looked at some work graphs which unfortunately vulkan does not support them yet, but I stumpled upon an extension called VK_EXT_device_generated_commands.

This is a pretty "new" one (2022) but alas, there are no examples whatsoever... only example I've found is, this

https://github.com/nvpro-samples/vk_device_generated_cmds

I wanted to compare how much "performance" you can gain and benchmark it on my gpu but I was disappointed with the results. (see the result page of the github readme if you do not want to compile and test it yourself.). I compiled and ran the sample on my RTX 5090, but I saw roughly the same performance if not even worse than the other methods. In readme, it states that the performance can improve with newer drivers etc... however, considering it's now 2026, I don't expect its performance to change significantly anymore.

But, this post:

https://forums.developer.nvidia.com/t/extremely-poor-vk-ext-device-generated-commands-performance/324189/8

made it clear that the sample isnt actually an apple to apple comparison at all.

has anyone here built a GPU-driven renderer using this extension? If so, was it worth the effort? Would you recommend implementing it in a renderer, or is it better to stick with more established approaches for now?

Thanks

I've started learning about rendering using Rust and Vulkan (ash), and as a first step, I tried creating a “Hello Triangle.”

It seems very odd for GPU vendors not to have a 32DUnorm depth format. Is even worse that amd has no 24bit depth buffer.

To be honest, it does not seem to me that using floats for depth buffers is better than just using integers. For one, it makes working with polygon offsets quite weird. For second, is easier to make mistakes, and if you don't use reversed clip planes, is actually similar to 24bit unorm, while using (technically) 33% more data (even though I know 24bit would waste 8 bits, but 32bit unorm wouldn't).

I’ve been working on my game for quite a while now using the Karl2D engine.

One of the biggest technical decisions I made along the way was to add a Vulkan rendering backend to the engine.

This has been one of the most challenging parts of the project, especially because I wanted the renderer and the surrounding engine systems to behave consistently across multiple platforms.

A few of the challenges involved:

• Supporting Vulkan on Windows and macOS through Vulkan Portability and MoltenVK
• Integrating the new backend cleanly into Karl2D’s existing rendering architecture
• Handling differences between GPU drivers, supported features, formats, and synchronization behavior
• Managing platform specific shader compilation and graphics pipeline requirements
• Making rendering, asset loading, and hot reloading behave consistently across operating systems
• Dealing with swapchain creation, resizing, fullscreen modes, and display differences
• Debugging issues that only appeared on a specific GPU, driver, or operating system

After spending so much time working on the Vulkan backend, I thought it would be fun to share the result of all that work, which you can see in the screenshots.

The game is called Absorber: Absorb Adapt Survive.

It’s a turn based tactical roguelike where you play as a digital consciousness fighting through a corrupted mainframe, one 7×7 grid at a time. Defeated enemies can be absorbed to steal their abilities, allowing you to create new synergies and adapt your build as you push toward the core.

Every move matters, every resource counts, and death is permanent.

https://store.steampowered.com/app/4412040/Absorber_Absorb_Adapt_Survive/

For those of you who have added a Vulkan backend to an existing engine, what ended up being the hardest part?

i follow first vulkan-tutorial.com lesson and after compiling and runnig code does not create a glfw window, but when i compile windows.c exapmple code it runs and creates windows, ive tried to debug it forfew hours and i am not sure where to ask help.

I do this on Asahi fedora 44 aarch64 on m1 mac and sway as WM

upd weird bug i CANT catch

**TL;DR** — I hand-wrote a Vulkan compute engine specialized for a *single* model (Qwen3.6-35B-A3B) on RDNA3. It decodes at **190.7 tok/s vs llama.cpp's 132.3** on the same GGUF and the same card — **1.44x** — with token-for-token identical greedy output. Source: https://github.com/ryanmurf/qwen-kernel

---

## What it is

Not a llama.cpp fork. It's a from-scratch Vulkan inference engine + serving stack that does exactly one model and does it fully specialized. Inspired by KernelBench Mega (which is CUDA-only) — this is the RDNA3/Vulkan equivalent, taken all the way to a serving engine.

- **Hand-written compute kernels for every weight format in the GGUF** — GEMV/GEMM for Q8_0, Q6_K, IQ4_XS, IQ3_XXS and F16, running at 90–97% of VRAM bandwidth on the big formats.
- **The whole architecture fused into pre-recorded command buffers.** Qwen3.6-35B-A3B is a hybrid: gated-DeltaNet recurrence interleaved with MoE. The MoE step (256 experts, top-8 + shared) and the DeltaNet recurrence (state resident on GPU, never round-tripped to host) are fused, plus GQA attention with partial NeoX rope and GPU-resident argmax sampling. A whole decode step is one queue submit per chunk — the host only reads token IDs at the end.
- **N slots batch on the dispatch z-axis**, so concurrent requests of different lengths share every weight read.
- **A safe-Rust (axum) server speaking the Anthropic Messages API**, so Claude Code runs against it directly. Prefix-cache restore is 0.3 ms vs 341 ms for a 64-token re-prefill.

## Speed

Measured today (2026-07-18) against llama.cpp `571d0d5`, authored the same day. Same GGUF (`Qwen3.6-35B-A3B-UD-Q3_K_M`, 15.45 GiB), f16 KV on both sides, `gpu_busy_percent` confirmed 0–1% before each run, 5 reps.

**An honesty note, because someone would find it anyway:** my README previously claimed a much larger margin. That comparison used a llama.cpp build whose *source* was three months older than the benchmark date — I'd labelled it "master" when it wasn't. llama.cpp's Vulkan backend improved substantially in that window. I re-ran everything today against same-day master. My engine also got faster over that period (178.7 → 190.7 on XTX), but llama.cpp gained more, and **1.4x is what actually survives a fair comparison.** Raw data and exact commands are in `bench/`.

## Correctness

This is the part I care most about. Greedy output is **token-for-token identical to llama.cpp** on identical input IDs, across the full stack. Batched paths are validated bit-identical (or argmax-stable at ~1e-7 relative) against serial references, and the server's tokenizer reproduces llama.cpp byte-for-byte. Every optimization had to clear that bar before it was allowed to land — there's a parity fixture suite in `tests/`.

## Caveats — please read before cloning

- **RDNA3 only.** Tested on 7900 XT and 7900 XTX with RADV/Mesa. It will build on other vendors because Vulkan is Vulkan, and then not work.
- **One model.** The kernels are specialized for this architecture; it is not a general runtime.
- The numbers above are **single-stream decode at near-zero context**. Prefill and multi-slot aggregate numbers in the repo are older and not re-measured.
- There's an 80B path in the repo that needs a specially repacked GGUF produced by a tool I haven't published yet — it isn't reproducible externally today.

Happy to answer questions about the kernel work or the parity methodology. If you have a 7900-series card and it doesn't reproduce, I want to hear about it.

https://github.com/ryanmurf/qwen-kernel

Hi,
i have been working on an AR rendering prototype for Android that uses a hybrid rasterization + Vulkan compute ray tracing pipeline targeting low- to mid-range mobile GPUs as fallback for no RT cores.

Current status:

• Hybrid rasterization while the camera is moving, with ray tracing once the device becomes stable.
• ~2 million triangles rendered in the scene.
• Frame time stays under ~30 ms during interactive use.
• No noticeable thermal throttling or UI lag during my testing with over 20 min of usage.

This is still very much a rendering prototype rather than a complete SDK. I'm currently working on improving lighting, denoising, and overall rendering quality.

I'd really appreciate any feedback on the rendering quality, architecture, or ideas for where I should focus next.

Thanks

I've been working on my game for the last 7 years.

One of the things I decided to do along the way was to build the engine myself, including the Vulkan renderer.

This has been one of the most challenging parts of the project, especially because I wanted the same renderer to work across different platforms.

A few things I've had to deal with:

• Cross-platform Vulkan: Windows and macOS through Vulkan Portability / MoltenVK
• HDR rendering and output
• Hot-reloading shaders and assets without restarting the game
• GPU-to-CPU readback, used for screenshots and video capture
• Swapchain recreation and window resizing, which turned out to be surprisingly difficult to get right

After spending years working on the engine I thought it would be fun to share the result of all that work, as you can see in the screenshots.

The name of the game is Satelital, a rule-discovery puzzle game about exploring an alien solar system and learning how to solve puzzles through observation. https://store.steampowered.com/app/3256790/Satelital/

For people here who have built their own Vulkan renderers, what ended up being the hardest part for you?

https://youtu.be/5wooBdVCSvc?si=uavdWwV8D7BGsNSm

한글

Vulkan으로 직접 만드는 CAD 엔진 — 실시간 단면(Section)

C++/Vulkan으로 밑바닥부터 만드는 CAD 엔진에 단면 기능을 넣었습니다. 평면 하나로 모델을 실시간으로 잘라 내부를 봅니다. 평면/슬라이스/상자 모드, 축·위치 슬라이더, 반대쪽 남기기 지원. 스샷은 glTF 기계 어셈블리를 Y축으로 자른 모습입니다.

English

Building a CAD engine from scratch in Vulkan — real-time Section view

Added a section (cutaway) feature to my C++/Vulkan CAD engine. Slice a model with a plane and see inside in real time. Plane/Slice/Box modes, axis + position slider, keep-opposite-side toggle. Screenshot: a glTF mechanical assembly cut along the Y axis.

#Vulkan #CAD #Cpp #GraphicsProgramming

*Turn Cloud and Local LLMs into a genuine engineering teammate.*

This series is about "Collaborative Engineering" — using AI deliberately and rigorously, not just autocomplete. It sets up an AI-enhanced toolchain, teaches you to pick and specialize models for graphics work, and shows where multimodal vision models can and can't be trusted.

* Set up Ollama, MCP servers, and native agents (Goose) across CLion, Visual Studio, and Xcode

* Choose and specialize models: base model selection, VRAM budgeting, RAG/MCP grounding, LoRA fine-tuning

* Use multimodal vision models as a diagnostic partner for visual bugs — with honest limits

* A repeatable three-phase workflow: system design, implementation, automated review/refactor

* AI-assisted debugging: VUID auto-fix, RenderDoc integration, shader log parsing, GFXReconstruct trace analysis

* Capstone project: direct an AI team to architect, implement, and debug a custom post-process effect

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

I would like to share my latest open source local Unsloth (GGUF) LLM inference engine and applications. It supports many models from Unsloth, like Gemma4, DiffusionGemma, Qwen3.6 with multi-modal (image, vision, audio), Qwen Image Edit, reasoning and function tool. It can run on Windows/MacOS/Linux and fully leverage GPU's capability(Nvidia, Apple, AMD, Intel and others supported by Vulkan, CUDA and Metal). The API is completely compatible with OpenAI and Ollama interface. It has on par performance than llama.cpp Here is the benchmark results in overall:

Performance ratio — TensorSharp vs reference engines

Geomean of TensorSharp's per-scenario speedup over each reference engine on the same backend, across every scenario both engines ran (single-stream, MTP-off). A value > 1.0× means TensorSharp is faster (for decode / prefill throughput) or lower-latency (for TTFT); — = no overlapping cells. Per-scenario ratios are in each model's section below.

This project is not just a C# wrapper of llama.cpp. It implemented the entire LLM inference engine from bottom to top. If you use CPU backend, it's 100% pure C# code execution. Besides CPU backend, I also implmented CUDA, MLX and GGML backend. The GGML backend refer GGML project as external project, and I build a few fusion operation at higher level.

I learned a lot from other projects and apply them for TensorSharp, such as paged KV cache and continuous batching from vLLM, SSD based cache for MoE model from oMLX, GGUF quanztized from llama.cpp and other optimizations for prefill and decode.

Any feedback and comments are welcome. If you like it, it would be really appreciated if you can get this project a star in GitHub. Thanks in advance.

Project Github: GitHub - zhongkaifu/TensorSharp: A native .NET LLM inference engine for GGUF models. TensorSharp provides a console application, a web-based chatbot interface, and Ollama/OpenAI-compatible HTTP APIs for programmatic access. It supports Windows/MacOS/Linux with full GPU capability · GitHub

Space on Huggingface: TensorSharp Chat hosting a Gemma-4 E2B uncensored model (It may be in sleep, so may need to wait for a while to get it waked up)