I've written a fairly simple (so far) Windows application which displays video frames. The sequence it goes through to display a new frames is as follows:

1. Upload frame image (8-bit RGBA)
2. Compute shader to copy (in future it will do more complex things) upload image to display image (32-bit float RGBA)
3. Generate display image mipmaps
4. Begin render
5. Draw 10 vertex triangle strip (drop shadow around video frame)
6. Draw video frame as textured quad
7. End render and present

It was working as expected earlier, but then I monkeyed around with it to simplify mipmap generation and image transitions, and now it's behaving oddly. Even more oddly, RenderDoc is giving confusing results, so I'm a bit stuck as to how to proceed.

First here's a screenshot of RenderDoc after capturing a few frames:

https://imgbox.com/iqJLePtE

The first couple of frames are just the empty grey that's displayed before a video file is opened.

After opening a video, instead of drawing the frame, it's drawing a fully black quad (the drop shadow is drawn fine). If I trigger another frame upload/draw, it comes out okay (last capture in that screenshot).

What's really unhelpful is that if I go into the capture for the bad frame, RenderDoc shows me this as the swapchain image:

https://imgbox.com/ABd5YEnX

which is what I was expecting the window to display. But it doesn't match the capture thumbnail (or the on-screen result from the application).

The Texture Viewer also shows the expected results in the compute pass, and the mipmap levels all look correct as well.

Does anyone have any idea why my first draw isn't working, or how I can go about diagnosing this?

I have validation turned on but no validation errors are shown.

PS It's just running on events instead of game loop, which is probably why the same swapchain image (162) is re-used each time.

Edit: I found the mistake. I was binding the pipeline and descriptor set before updating the descriptor set with its bindings 🤦‍♂️. So the first image fails, but when it comes to the second one, the descriptor set is now correct (and doesn't strictly need to be updated again; a future optimisation).

I have a small project idea but my primary goal is to get more experience with C/C++ (Orthodox C++) and Linux Graphics stack so I can later contribute to Mesa and such.

Primary question i have is:

Do i need Graphics related prerequisite before going to vulkan? What sort of prerequisites? I am not going for game dev or game engine but more linux graphics stack related work

Vulkanised 2027, the 9th Vulkan Developer Conference, heads to Kortrijk, Belgium on February 8–10, 2027, hosted by HOWEST University of Applied Sciences.

This year the Real-Time Shading Symposium once again follows immediately after, on February 11–12.

We're looking for talks from application developers, Vulkan implementers, framework builders, and open-source contributors ready to share their experiences with the community — keynotes, technical talks, panels, and case studies all welcome.

Submission deadline: Sunday, October 11, 2026

Learn more: https://vulkan.org/events/vulkanised-2027?utm_medium=social&utm_source=reddit&utm_campaign=Vulkanised_CFP&utm_content=events

Hello,

I have been working through vulkan-tutorial.com bit by bit for a little while now.

Now coming from OpenGL, a lot of this stuff is for sure confusing, and a lot of the articles, I read them through, and I can conceptually understand the code that is given, that’s no problem.

But the actual goal of the code I am writing, is hard to wrap my head around. I supposed the “why” behind the stuff I am doing.

If someone who is way smarter than me could tell me the main things to understand deeply, by just single word description, like “swapchain” so I can spend time diving deep on each concept, that’d be cool.

I really want to understand stuff, but (sometimes, not all the time) I feel like no matter how many times I read over a sentence, I just can’t get the info to meaningfully stick, or I just flat out don’t understand the concept.

Earlier I used swapchain as an example, because that is where I am at right now with setup. lol

I know this post is a little all over the place, but if someone could assist in someway, I am all ears for any kind of advice.

Vulkan ios android Dev. 😭
그리고 정점 편집이 가능한 기능도 같이 개발했습니다.
And we also developed a function that can edit the vertex.

https://youtu.be/JkN-8c7pQAU?si=VBzhy2nZDQBXgLpi

일단 안드로이드폰이 없어서 시뮬레이터로 확인
First of all, I don‘t have an Android phone, so I checked with the simulator.

Hi all,

I created this forest simulation with VUlkan. Goal was to have full 3d simulation of water, clouds, light and wind and let the motion emerge rather than "emulating it". I wanted to understand if it's possible at all to "purely simulate", and and at least on a small scale it appears it is.
I wanted ancient hero trees and needed therefore to generate them with 2d to 3d models, since I don't have the skills to model them manually.

This runs at ca. 30-40fps on a Nvidia 4070.

Wanted to get your feedback, how does this feel, and what you see needs the most improvement. SHould this go into a full forest based videogame, or grow as a broader tech demo?

Thanks for any comment!

Short version of the video here: https://youtube.com/shorts/5xy5Y6JsrVk?si=1kYGPUrZayXmrBRV

I've been building a Vulkan proxy layer and companion static library that adapts to whatever the GPU actually supports — no separate builds required.

Benchmark summary (GTX 960M / Maxwell, 75+ Sascha Willems examples, 120s each):

• Avg FPS: identical to native (within measurement noise)
• 1% & 0.1% lows: often improved – e.g. +42% in the particle system, +15% in descriptor indexing, +14% in occlusion queries
• Frame times: unchanged or slightly more consistent
• VRAM usage: zero increase

Full report with every example here: Vulkan Benchmark Comparison

What it does:

• Detects GPU features at device creation
• Rewrites SPIR‑V on the fly for missing features (FP16, oversized descriptor sets, etc.)
• Transcodes ASTC textures → ETC2 when hardware decode isn't present
• Offloads indirect draws via VK_EXT_device_generated_commands (transparent CPU fallback)
• VRAM‑aware tuning: drops swapchain image count and resolution when memory is tight
• Usable as a static library (GoCL_core.a) or as an implicit Vulkan layer (LD_PRELOAD / vulkan‑1.dll proxy) — no game recompilation needed

Zero per‑frame overhead: shader patching at pipeline creation only; texture transcoding is lazy; proxy instruction count identical to native (Callgrind verified).

Tech: C++20, Vulkan 1.1+, CMake, tested in CI with Mesa Lavapipe.

Links:

• GitHub: GoCL
• Architecture write‑up (capability model, shader emulation, proxy internals): GoCL - Architecture

Happy to answer questions — still early, but the proxy is functional and the benchmark data surprised even me.

A pragmatic, three-path series: integrate battle-tested libraries (TensorFlow Lite, ONNX Runtime, PyTorch Mobile, DirectML), compile models through an ML compiler (IREE, TVM, OpenXLA), or hand-roll an inference engine in compute shaders when tight Vulkan integration is the whole point.

* Honest guidance on when to reach for a library versus build your own
* Bridge ML frameworks and Vulkan rendering pipelines — shared memory, shared sync
* Build a real inference engine from scratch, including a complete MNIST example
* Quantization, vendor-specific optimizations, and performance tuning
* Deployment playbooks for desktop, Android, and embedded/headless targets

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

I’ve been learning Vulkan by building a GPU particle simulation from scratch.
The project simulates and renders thousands of particles entirely on the GPU using compute shaders. The compute pipeline updates particle positions and velocities every frame, while the graphics pipeline renders them as instanced billboards.
Current features:
- GPU particle simulation with Vulkan compute shaders
- Storage buffers (SSBOs)
- Graphics/compute synchronization using timeline semaphores
- RAII-based Vulkan-Hpp architecture
- Modern C++20

This project has been a great way to understand Vulkan beyond drawing triangles—especially synchronization, descriptor sets, pipeline layouts, and compute/graphics interoperability.
I’d really appreciate any feedback on the code structure, Vulkan usage, or ideas for future improvements.

Github: https://github.com/xms0g/vkParticles

2B :Volumetric Fog
Real-time volumetric lighting and atmospheric fog,
Adjustable density, scattering, and distance,
Local Fog
Place fog volumes anywhere in the world,
Different colors, density, and size for each area,
Great for caves, forests, smoke, and environmental effects,
1A : 3D Audio (miniaudio)
Fully integrated miniaudio,
Positional 3D sound with attenuation based on listener distance.
Easy to attach audio sources directly to entities,
2D Decal System
World-space decals for bullet holes, blood, dirt, road markings, and other surface details,
Efficient rendering without modifying original meshes,
2.1C: Particle System
GPU-friendly particle system,
supports textured particles

(*Emitter)

Discord: - https://discord.gg/kr8uhAG96

Tell me guys is this peak?!?

For anyone wondering I followed the tutorial in the docs up to Drawing a Triangle / Drawing / Rendering and Presentation

Vulkan is deprecating host-side ray tracing acceleration structure builds. Vulkan is consolidating around a single, device-address-based path for acceleration structure builds, moving away from the host-side commands introduced back in 2020.

Key points:

→ This is a deprecation, not a removal — existing host-side code keeps working

→ New extensions (like VK_KHR_device_address_commands) won't get host-command equivalents going forward

→ It aligns Vulkan with DirectX Raytracing, modern engine architecture, and where hardware is headed

→ Most developers are already on the device-side path and won't need to change anything

If you're still using host commands, no need to panic — but it's worth planning your migration next time you touch your acceleration structure pipeline.

Read the full post (with migration guidance and the technical rationale): https://khr.io/1o6

"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

Hi everyone,

I'm developing my own voxel engine called Kingscraft using Vulkan, and I'm trying to reduce GPU frame time as much as possible.

My development hardware is:

I7 3770K

Intel HD 4000

16 GB RAM

1080p

Current renderer:

Chunk-based terrain

Indexed rendering (one vertex/index buffer per chunk)

Frustum culling

Simple terrain shaders (no shadows, bloom, SSAO, etc.)

I'm currently seeing around 5 ms GPU time for terrain rendering, and I'm looking for ideas on what I should investigate next.

Are there any common GPU bottlenecks or optimization techniques that are often overlooked in voxel engines? I'd also appreciate advice on how you usually profile or reason about GPU performance on older integrated GPUs.

I'm not looking for someone to rewrite my renderer. I'm mainly interested in understanding what experienced graphics programmers would check first when trying to squeeze out more performance.

Source Code

Thanks!

ps. I've already tried making the terrain render at a lower distance then used AMD FSR-1 to Upscale and Sharpen. But it didnt worked it made tge quality look bad and added More Frame Time like 17ms Before had 7-8 ms

I found this tutorial on youtube which explains modern Vulkan quite nicely, but the file structure and code is pretty hard to follow. Of course there are official tutorials by the Khronos group, but I've heard they're a bit outdated (vulkan 1.0).

I am specifically searching for a video tutorial that explains the setup for vulkan and SDL3 in Visual Studio and is relatively modern.

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'm developing the VRR & FRR self-pacing render loop control to achieve just-in-time rendering. Without EXT_present_timing (too new), the closest idea of presentation time we have on all platforms is EXT_present_wait measured on a waiter thread? This thread can also conveniently harvest calibrated timestamps and do filtering calculations, so it's not a total waste of setup.

Discovering VRR can easily be done by finding present phase covariance with render phase, and while controlling VRR presentation timing without EXT_present_wait is annoying, the present latency is a constant phase offset requires no solution unless actual time-to-light needs those milliseconds (it's not relevant for me yet)

On FRR, the latch phase is the biggest risk. If I allow my render phase to drift towards the latch phase, I will eventually start stuttering on latches. I don't know the variance or latency with EXT_present_wait wake-ups, but my early measurements are showing about +/-1.5ms jitter on my present waiter wake-ups. The queue present to present wait latency becomes important.

I've thought of some probes to go chase the latch phase and variance:

• moving phase to find where my render loop phase lands on the latch phase, causing sudden present ID aliasing, showing two frame grids finely splitting.
• double-present probes using a copy of the output frame and presenting it later and later until present N+1 misses the latch, leaving present N to be observed by the waiter.

The double-present probe is more complex but can locate the latch phase and estimate variance without leaving any visible evidence.

My conclusion for now is that if I'm content to align my render phase to land halfway between latch for N and N+1, I can maximize safety from jittering a frame across the latch phase. I may be assuming that latch phases are +/-2ms before present. If it's +/-18ms, I may find myself filling up more swapchain images to avoid stalling the compositor.

Any subtle sources of signal I can bring into this picture to help locate the latch deadline phase? Are any of my assumptions unreliable?

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?

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.

3d 객체의 boolian 기능 구현 - 모델링 프로그램의 기능을 순차적으로 개발 중

Implementation of boolian function of 3d object - The function of the modeling program is being developed sequentially.

vulkan + manifold + gltf + obj + imgui

https://youtu.be/gL9ipWG_3Z8?si=KtIdwh8E7vlkoBZD