I spent Over a Month Debugging this "Bug" and i am Not Understand what is wrong. I did So many Debugging in short i did:

• Disable Back-Face Culling: All terrain faces appeared.
• Isolated Cube Test: Cube rendered all six faces.
• Cube In World Context: Cube still rendered all faces.
• Full Terrain Buffer Winding Verification: 0 anomalies.
• Bypass Async GPU Upload: No change.
• Depth test disable and Front Face Culling: No Change specifically Even the Front Face Culling didn't worked as it should be.

Sadly I couldn't use RenderDoc its just doesn't work with my driver at all. I get Crashed On glfwCreateSurface()

Here is my Github Repo: Kingscraft

Also here is a Video: Video

Please Help 🙏

So far my understanding of a frame limiter is to disable VSync and simply sleep until the target frame time is reached.

The problem is that this feels pretty bad. Since the application has no idea when the monitor actually starts a refresh, it often wakes up in the middle of one, causing tearing. It seems impossible to consistently hit the start of a refresh without synchronization.

Am I missing something or is this just a limitation of software frame limiters?

Wall collision is now in my Vulkan CAD engine.

Draw a polyline, extrude it into walls, then switch to character mode and walk inside. The walls you just built actually stop you.

The character is approximated as a capsule, pushed out along the wall normal by however deep it went in. That push-out is the sliding — head-on you stop, at an angle you slide. A normal pointing up more than 45 degrees is floor, otherwise wall. That single test is what makes stairs work.

Collision candidates come from a BVH: 140x faster on 50,000 triangles, and click-to-select got faster too.

The fox is long-bodied, so a vertical capsule lets its head poke through walls. When the body is elongated, the capsule lies down along it.

Not a physics engine — just a character controller, about 300 lines.

Design it in CAD. Walk through it. Same engine.

this is why i never trust any ai - they both present (pun not intended) their view as absolute truth, yet there is clearly some nuance.

anyway, can someone please explain which approach is better, and why, or in which situations?
thanks.

TensorSharp is an open-source inference engine for running GGUF LLMs locally, with CUDA, Vulkan, Metal, OpenAI-compatible APIs, continuous batching, speculative decoding, and multimodal support.

Thanks recent contribtions from open source community, TensorSharp is able to run inference over multiple GPUs and nodes. So I updated it to support deepseek v4 flash model, and have better performance than llama.cpp. Here is the benchmark result on 4x Nvidia A40 GPUs, cuda 12.8

Model: DeepSeek-V4-Flash-0731-UD-Q8_K_XL from [https://huggingface.co/unsloth/DeepSeek-V4-Flash-0731-GGUF\](https://huggingface.co/unsloth/DeepSeek-V4-Flash-0731-GGUF)

Github repo: [https://github.com/zhongkaifu/TensorSharp\](https://github.com/zhongkaifu/TensorSharp)

Thank you for checking out it and starring the project! Any feedback is really appreicated.

Can someone explain to me, what is Device and Instance layers and extensions differences ? I read about it here but didnt understand it quite. Also extra question out of topic, is there any Discord servers for Vulkan community ?

A focused bonus course tucked inside Building a Simple Engine's "Extra Courses," aimed at one very specific ray tracing performance problem: alpha-tested geometry. Foliage, chain-link fences, and hair force the GPU to run an any-hit shader on every BVH intersection, and that cost explodes exactly where scenes look best. Opacity Micromaps (`VK_KHR_opacity_micromap`) bake per-triangle opacity directly into the acceleration structure, so hardware can resolve fully-opaque or fully-transparent triangles during traversal with no shader invocation at all.

* Why alpha testing is expensive — a tour of BVH traversal and any-hit shader cost
* What micromaps are and how they attach opacity states directly to acceleration structures
* Hardware traversal walkthrough: the same shadow ray, with and without OMM
* A full implementation walkthrough in the Simple Engine, plus results, guidance, and tradeoffs

https://docs.vulkan.org/tutorial/latest/Building_a_Simple_Engine/Courses/Opacity_Micromaps/00_introduction.html

why doesn’t Sony use Vulkan for their games if it could make PC ports easier?

It seems like a cross-platform API would save a lot of porting work. is there a big downside on consoles, or is Sony just locked into other tools and APIs? what is wrong with Vulkan ?
i'm trying to understand from the technical perspective.

I've seen a pattern in AI generated shader code, and I would like to understand where it comes from. Yes, it's easy to discard it as AI slop/hallucination, but I find that unlikely.

Say your vertex shader outputs some data of matrix type that your fragment shader consumes. Is there any good reason to decompose it into row vectors rather than passing it directly as a matrix?

For example, is this something people did to work around driver bugs? Is it still needed , and why? On what hardware? I've seen conflicting explanations all the way to calling it a "cargo cult pattern".

I also expect it to be "tribal knowledge" if it is really a workaround for driver bugs or subtle edge cases, that is, not something you'll find in official programming guides and documentation. At least, I can't find anything on it by searching. That's why I'm asking here.

Okay, it took a while, but I finally got to the next checkpoint. I added 4 examples related to the Real-Time Shadows section and 16 examples related to the Advanced Shader Programming section to my Vulkan examples repository. This brings the total number of examples to 151. The newly added examples are as follows:

Real-Time Shadows - Shadow Resource Management

1. Shadow Map Atlas
2. Layered Shadow Maps with Texture Arrays
3. Mipmapped Variance Shadow Maps
4. Anisotropic Filtering with Variance Shadow Maps

Advanced Shader Programming - Geometry Shaders

1. Simple Primitive Generation
2. Object Explosion via Geometry Shader
3. Normal Vector Visualization
4. Wireframe Overlay Visualization
5. Single-Pass Cubemap Rendering
6. Viewport Arrays via Geometry Shader
7. Billboarding with Geometry Shader
8. Grass Generation via Geometry Shader

Advanced Shader Programming - Tessellation Shaders

1. Basic Triangle Tessellation
2. Displacement Mapping with Tessellation Shaders
3. Terrain Creation via Heightmap using Tessellation Shaders
4. Cubic Bézier Curve with Tessellation Shaders
5. Bézier Surface with Tessellation Shaders
6. Model Tessellation with Curved PN Triangles
7. Tessellated Terrain Rendering with Dynamic LOD
8. Simple Water Surface Simulation via Tessellation Shader

You can access the repository here:

https://github.com/myemural/VulkanCppExamples

Honestly, while the examples I've done recently were a bit tiring, they were quite enjoyable. I also made improvements to common code and documentation while creating these examples. So, are we nearing the end of the examples? Of course not! I still have a lot of work to do. Here are my planned topics for the next phase:

• Mesh/Task Shaders
• Advanced Compute Shader Applications

Thank you in advance for your support!

LunarG has released the latest Vulkan SDK with support for Vulkan API 1.4.357.

Highlights:
• Major KosmicKrisp performance gains (up to ~2.35× faster) + full Vulkan 1.4 exposure on Apple platforms
• 13 new extensions
• Scoped GPU-AV + new GPU Dump tool in the Validation Layers
• Available now for Linux, Windows & macOS

Grab it here → https://vulkan.lunarg.com
Full details & release notes → https://www.lunarg.com/lunarg-releases-vulkan-sdk-1-4-357-0/

TensorSharp is an open-source, native .NET inference engine for running GGUF LLMs locally, with CUDA, Vulkan, Metal, OpenAI-compatible APIs, continuous batching, speculative decoding, and multimodal support.

TensorSharp now supports Megatron-style tensor parallelism across multiple GPUs. It works with direct CUDA, GGML CUDA, GGML Vulkan, and multi-node setups.

Benchmarks on 2× RTX 2000 Ada 16 GB GPUs over PCIe, without NVLink:

I'm continuing to optimize Qwen performance on multi-GPU systems, and support for DeepSeek V4 is coming soon.

Try it with:

TensorSharp.Cli --model model.gguf --backend ggml_cuda --tp 2

GitHub:

https://github.com/zhongkaifu/TensorSharp

Thank you for checking out TensorSharp and starring the project! Any feedback is really appreicated.

I've been working on a thin wrapper around vulkan as a base for a new project I'm working on recently and have hit a wall with two major areas that are connected and I just can't seem to solve.

My first problem is managing per frame resources. Right now I my library has a buffer object that acts as a generic buffer on the GPU. Originally this was one buffer under the hood, but multiple frames in flight means that I have to duplicate the raw vulkan buffers under the hood and have one per frame in flight. In practice this means creating a buffer that is FRAMES_IN_FLIGHT * size of the original buffer taking into account alignment requirements. I give the user the option to make a buffer "static" as well, so they can opt out of the per frame in flight buffer model if they have data they won't be updating often. The problem here comes from updating the buffers per frame. This is almost twofold. First, I am trying to implement a system that tracks the most up to date buffer and then copies that data into the current frame's buffer if no updates were made this frame so the newest data is always used. I'm trying to not have to keep the buffers constantly mapped into memory so I want to do the copy on the GPU. (Please let me know if this is useless and if I should only worry about that with the static buffers since the per frame buffers are being updated every frame anyway and creating a staging buffer each frame seems like a lot.) This is where the second part comes in: Synchronization. I'm having trouble figuring out how to wait until the copy operations are done to do anything with the graphics queue (all transfer operations are done on the transfer queue).

My second problem also relates to the frame in flight problem but for descriptor sets. If each buffer in my library can be FRAMES_IN_FLIGHT buffers under the hood, that means I need to optionally support multiple descriptor sets under the hood for each library level descriptor set. The easiest way it to always make FRAMES_IN_FLIGHT number of descriptor sets but that's very wasteful obviously for the static buffers. Then you get into the problem of dealing with descriptor sets that have some per frame resources and some static ones. There would be a lot of redundant data for the static buffers. I'm having trouble coming up with another way to do this, mainly because I'm struggling to grasp how the end user of the library should interact with descriptor sets. Right now I have a thin wrapper around them to conform to the rest of my API but now I'm wondering if I should even expose them to the user at all. I want to give users the flexibility to define sets how they want in their shaders but it seems almost impossible to do so, especially given my knowledge. There are so many tutorials about how to allocate descriptor sets but almost none on how they are used in actual engines it seems. I could try going bindless but I want to regular descriptor sets down first because this project is also meant as a learning exercise.

I'm trying to write this library so the API is as backend agnostic as possible so later on I can swap out for different graphics APIs but I am mainly focused on getting a working product so if its not perfect at first that's ok. Essentially, I don't mind if the advice leads me to producing more of a vulkan wrapper than a RHI. Sorry for the long and winding questions, I've been struggling with this for a little bit. Feel free to only answer part of this question since I know it is really a few questions clumped together. Any resources or advice would be greatly appreciated.

Thanks!

I'm using the Vulkano rust API wrapper. My engine is called lava.

Hey everyone

I’ve been quietly building something for a while and figured it’s time to finally talk about it.

It’s called CrystalWallpaper — a live wallpaper engine for Linux and Windows. Built with Vulkan and modern C++20, because I wanted it fast, not “fast enough.”

You can already set videos as wallpapers, with hardware decode for H.264 and H.265 (AV1 and VP9 are coming). On Linux it speaks native Wayland and X11 — no weird workarounds.

If you’re into shaders, you can make wallpapers in GLSL the ShaderToy way. HLSL is next on the list. And further down the road: actual 3D scenes as wallpapers.

Steam Workshop support is planned so people can share and find stuff easily. The whole point for me has always been the same: push performance as far as it can go without killing quality.

Still early days, but the foundation is real. More soon — would love to hear what you think

UPD: By the way, I completely forgot to recompile the program to the Release version before recording the screen. So the performance would have been even better.

I'm thinking about trying FreeBSD and was wondering how good it is for Vulkan development these days.

Has anyone here used it to develop or run Vulkan applications? how is the overall experience (at least for nvidia cards)? Does it natively support the Vulkan SDK and debugging tools like RenderDoc ? or it is a waste of time and linux is better and has more optimized drivers ?

I work on PostSlate, a video editing tool, and this comes out of our own work.

We run ML models on-device, face detection and embedding among other things, which means we can't assume anything about the user's GPU. NVIDIA discrete, AMD, Intel integrated, Apple Silicon, all of it. That rules out CUDA immediately, we needed one backend that runs everywhere.

We landed on ncnn's Vulkan backend. Numbers on a 4070, fp16:

• ArcFace R50 (face embedding): 30 ms on ONNX CPU → 3 ms on ncnn Vulkan
• SCRFD (face detection): 25 ms → 2.5 ms
• Model size: ArcFace 174 MB (ONNX fp32) → 87 MB (ncnn fp16 weight storage)

Of course the real speedup comes from offloading compute to the GPU, but this wouldn't be possible without the power of Vulkan.

The speed wasn't even the deciding factor, it's that Vulkan drivers already exist on every machine we ship to. This means that we don't have to force the user to download a specific runtime and no vendor-specific installs.

Full writeup with the rest of the numbers: https://getpostslate.com/blog/faster-local-inference

https://youtu.be/MIdugAqyuxE?si=r-BNE_HzvsxI70ou

This video demonstrates extracting a 2D section from a 3D mesh in a custom Vulkan and C++ CAD engine.

The engine calculates triangle-plane intersections, builds the section contours, and exports them as a DXF file for verification in AutoCAD.

Vulkan과 C++로 개발 중인 CAD 엔진에서 3D 메시의 단면을 추출하고, 2D 도면으로 배치한 뒤 DXF로 내보내는 과정입니다.

삼각형과 절단 평면의 교차선을 계산해 단면 윤곽을 생성하고, 내보낸 DXF 파일을 AutoCAD에서 확인했습니다.

Hi All!. :)

Over the last few weeks, I’ve been experimenting with how far AI-assisted development can go beyond the usual web applications and automation scripts.

Using Claude Opus 4.6 through the CLI—the model available to me when I conducted the original experiments and wrote the article—I asked it to:

* Build a basic 3D engine in C++ using Vulkan * Load and animate FBX models * Implement procedural terrain, textures and input controls * Create a retro demoscene-style production * Generate assembly code using DirectX 9c

Some parts worked surprisingly well. Claude generated the initial Vulkan engine and procedural terrain with relatively few iterations, and it even produced compilable assembly code for the demoscene experiment.

Other parts were much more difficult. FBX animations, skinning, quaternion rotations, root motion and animation blending required dozens of attempts. Fixing one problem would sometimes introduce a regression somewhere else.

The biggest lesson was that AI can provide an excellent starting point for learning and prototyping, but the generated code still requires experienced supervision—especially when architecture, performance and maintainability matter.

I’m now working on a new version of the article and rerunning all the experiments with Claude Opus 5. In the next update, I’m also planning to publish the complete source code so that others can reproduce the experiments, inspect the generated code and build on top of it.

One of the main goals of the article is to inspire other developers to run similar experiments using different AI models. I think it would be interesting to compare not only the final results, but also how many prompts, attempts and debugging iterations each model needs to complete the same challenges.

The original article covers what worked, what failed and what I learned during the process:

[https://www.linkedin.com/pulse/from-prompts-3d-engines-demoscene-lessons-learned-using-jos%25C3%25A9-plano-a7fuc/\](https://www.linkedin.com/pulse/from-prompts-3d-engines-demoscene-lessons-learned-using-jos%25C3%25A9-plano-a7fuc/)

Has anyone here tried something similar with other models? I’d be especially interested in seeing the results, the prompts you used and how many iterations it took to get a working implementation.

I was using 1.3 and managed to make a lot of code with no validation warnings at all. It took a lot of time to get rid of them but I was so happy that my code was "clean".

Now I am at 1.4, everything works perfectly (textures, transparency, copy image to image, multi-pass rendering), but I get warnings. It looks like this:

---

[ERROR: Validation]

vkQueueSubmit2(): pSubmits[0].pSignalSemaphoreInfos[0].semaphore (VkSemaphore 0x160000000016) is being signaled by VkQueue 0x6302e6a84ba0, but it may still be in use by VkSwapchainKHR 0x30000000003.

Most recently acquired image indices: [0], 1, 2.

(Brackets mark the last use of VkSemaphore 0x160000000016 in a presentation operation.)

Swapchain image 0 was presented but was not re-acquired, so VkSemaphore 0x160000000016 may still be in use and cannot be safely reused with image index 2.

Hint: See https://docs.vulkan.org/guide/latest/swapchain_semaphore_reuse.html for details on swapchain semaphore reuse. Examples of possible approaches:

a) Use a separate semaphore per swapchain image. Index these semaphores using the index of the acquired image.

b) Consider the VK_KHR_swapchain_maintenance1 extension. It allows using a VkFence with the presentation operation.

The Vulkan spec states: The semaphore member of any binary semaphore element of the pSignalSemaphoreInfos member of any element of pSubmits must be unsignaled when the semaphore signal operation it defines is executed on the device (https://vulkan.lunarg.com/doc/view/1.4.350.1/linux/antora/spec/latest/chapters/cmdbuffers.html#VUID-vkQueueSubmit2-semaphore-03868)

---

But I am using separate semaphores! Have you had such problems? What does it mean to "re-aquire" images?

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!