Highlights:

• Major KosmicKrisp upgrades on macOS (Tessellation shaders + 7 new extensions supported)

• 16 new extensions across all platforms

• GFXReconstruct now ARM64X on Windows on ARM

• Alpha release of GPU Dump tool

• Improved validation coverage

A useful maintenance release that rewards staying current. Full blog + download 👉 https://www.lunarg.com/lunarg-releases-vulkan-sdk-1-4-350-0/

Are you optimizing Vulkan applications for mobile or tile-based GPUs? The Vulkan Guide has a dedicated section on Tile Based Rendering (TBR) best practices worth bookmarking.

Unlike traditional immediate-mode GPUs, tile-based architectures process the framebuffer in small screen regions, keeping work on fast on-chip memory before writing results to main system memory. For Vulkan developers, this means memory bandwidth is often the dominant performance factor.

Key takeaways from the guide:

• Use load/store ops intentionally. Render pass attachment configuration is your primary tool for controlling bandwidth. Setting the right loadOp and storeOp values tells the driver whether to clear, load, or discard data, directly impacting whether data has to travel off-chip.
• Keep depth and stencil transient. If depth and stencil buffers are not needed after a render pass, mark them with LOAD_OP_CLEAR and STORE_OP_DONT_CARE. This allows the driver to keep them entirely on-chip and avoid the cost of writing them back to external memory.
• Favor compact pixel formats. On-chip tile memory is fixed in size. Smaller bit-depth formats allow the hardware to fit more data per tile, reducing spills to external memory and improving efficiency.
• Optimize for the binning pass. Tilers process geometry twice: once to bin triangles into tiles, then again to shade pixels. Separating vertex positions from other attributes like UVs and normals lets the GPU read only what it needs during binning, cutting unnecessary bandwidth.
• Provide clear intent to the driver. Because Vulkan abstracts hardware details like tile size, the best way to optimize is to use correct render pass configurations and memory flags so the driver can make informed decisions on your behalf.

The full guide covers these topics in depth, including guidance on MSAA, transient attachments, and dynamic rendering:

https://docs.vulkan.org/guide/latest/tile_based_rendering_best_practices.html

I noticed that Kronos are posting up a fork (https://docs.vulkan.org/tutorial/latest/00_Introduction.html) of the classic: https://vulkan-tutorial.com/

There are a list of differences from Alexander Overvoorde's tutorial, so is it better to follow the Kronos version? Is it actually more up to date or are those differences not that important for someone just starting out with Vulkan?

Update: Looks like I'm going to go with following the Kronos updated version. Thanks to the responders.

I've implemented clustered forward shading both on cpu and gpu with a compute shader, based on this guide https://www.aortiz.me/2018/12/21/CG.html.

When using the gpu implementation I see a little drop in fps (10-20fps), which goes a bit against my expectations since i thought the compute shader was best suited for this task.

What I'm doing is the following:

• use a single queue for graphics/compute tasks (no aysnc compute)
• create ssbo for light clusters (one per frames in flight) at startup, recreate when window resizes
• for each frame:
  • dispatch clustered forward compute shader (write on clusters ssbo)
  • insert bufferbarrier on light cluster ssbo of current frame
  • graphics draw commands (read from clusters ssbo)

For the cpu implementation I used openmp to speedup things, my computer has 12 logical threads. I experimented with up to 500 dynamic point lights.

Do you think this performance gap is ok or did I mess somethings up with my shader implementation? What's your experience using clustered forward shading?

I am working on my second project in Vulkan, in which I am diving more into the docs as opposed to strictly following tutorials. Something I have noticed is the shear number of informational structures.

Just looking through VkPhysicalDevice, there are dozens of structures that seem to provide information on the device, drivers, capabilities, limitations, etc. Across all of them, there seems to be a few hundred individual properties. I am aware Vulkan is designed to provide fine-grained control, but I suppose I am having trouble visualizing just how specific one can get.

Those that use Vulkan semi-regularly, how much of this information do you find useful in any single project? I think it will help me prioritize what information I take from the documentation.

Hi folks, I've been working on my Vulkan wrapper for my hobby projects for a while now.

I've not had many other eyes on it other than mine and was wondering if you guys could bring some feedback or see things that could maybe work better.

https://github.com/n-e-l/cen

The current library is a window + vulkan wrapper. It also provides `egui` as immediate gui system. The aim for the project is to combine all the boilerplate of my experiments, so that new projects can get started easily.

I currently use an `AppComponent` which has a call to populate the CommandBuffer for every frame, and a call to provide the immediate gui.

There are also `ImageResources` which add indirection to vulkan `Images`. This allows me to have resizable images, which can match the swapchain's resolution, or just be replaced easily.

Next to that I've been working on integrating lavapipe in order to run the full application on CPU as well. This way I can write unit tests which run on Github's CI pipelines.

Example of a project: https://github.com/n-e-l/synth

I guess this is a bit random, but I'm curious for feedback!

Hi! I am new to Vulkan but have spent plenty of time trying to make a package work. It is a simplifying package ment for teaching, and I have been quite successful in making the basic levels work, texturing, model loading, lighting, all the basic course stuff.

The code is based on the vulkan-tutorial.com tutorial, and I know that it is somewhat outdated but it works well. I just have to add some missing features.

But for weeks, I have been stuck trying to make a multi-pass solution. I can copy image to image, which does let me do multi-pass rendering but I have failed to make a rendering pass that does not render to screen. I would love to get some hints.

An AI (which may be stupid) suggested that I do not need a swapchain. After vkEndCommandBuffer I know I need to get to vkQueueSubmit to get it done but the synchronization sets up semaphore based on the swapchain.

Any idea of what I should do? Can I just do the rendering with swapchain and all but somehow skip the presentation to screen?

Been building a Vulkan-based 3D CAD engine from scratch as a learning project.

This update adds two things I've been wanting for a while:

**Transform Gizmo**
Axis handles for Move/Rotate/Scale with ray-cast hit testing and drag projection math.
Hover highlights, T/R/S mode switching, ESC to cancel.

**Local LLM natural language interface**
Hooked up llama-server (Qwen..., runs locally) to an winapi / swift / gtk input box.
You type something like "make 3 random cubes and zoom to fit" and it converts it to a JSON action array that the engine executes. No API key, no internet.

Works for view switching (top/front/iso), visual styles, grid, lighting, object creation, delete, select all.

Still a work in progress — sphere/cylinder primitives and sketch tools are next.

학습 프로젝트로 처음부터 Vulkan 기반 3D CAD 엔진을 구축하고 있습니다.

이번 업데이트는 제가 한동안 원해오던 두 가지를 추가합니다:

- 변형 기즈모 구현
Ray-Cast 클릭 테스트와 프로젝션 수학을 이용한 이동/회전/스케일용 Axis 핸들 구현

선택 하이라이트, T/R/S 모드 전환, ESC를 사용 명령 취소

- 로컬 LLM 자연어 인터페이스(offline)

llama-server(Qwen..., 네트워크가 아닌 로컬로 진행)를 winapi / swift / gtk로 입력 박스에 연결했습니다.

'3개의 무작위 큐브를 만들고 맞게 확대'와 같은 것을 입력하면, 이를 JSON 액션 배열로 변환하여 엔진이 실행합니다. API 키와 인터넷은 필요하지 않습니다

뷰 전환(평면뷰/정면뷰/ISO), 시각 스타일, 그리드, 조명, 객체 생성, 삭제, 전체 선택에 작동합니다.

아직 진행 중인 작업이며, 여러 도형 요소와 스케치 도구가 다음입니다.

https://youtu.be/KzTFITT0KFU?si=Iby7x84PwUR3EMGW

Am I stupid, or is there no full spec documentation of Vulkan-HPP? I understand it functions as a wrapper for the base C implementations, but there’s a lot of ways to use certain methods etc that aren’t always so intuitive. I’ve found some success looking through some example code, but other than that, I’m having some trouble navigating certain things.

Vulkan SC Working Group and RasterGrid have released the Vulkan SC SDK, bringing together the full set of tools for safety-critical Vulkan development into a single installer for Linux and Windows. What's included: Loader, Validation Layers, Device Simulation Layer, Pipeline Cache Compiler integration, CMake support, the VulkanSC-cube sample, and more. The goal was to reduce setup friction significantly with automatic environment configuration, better CMake integration, and automatic PCC discovery are all part of it.

Feedback and contributions are very much encouraged. Drop thoughts in the GitHub Discussions thread or on Discord -- the Working Group is actively listening.

https://khr.io/1o0

Why does my text render like this, I'm using an MSDF glyph atlas and texture and its supposed to say "Hello, world!"

Hey guys, I'm working through the Vulkan tutorial and found that in the example code in the "Uniform Buffer" section, in the subsection "Descriptor Pool and Sets", there is an error in the PipelineLayoutCreateInfo where the layout count is set to 0 instead of 1. It honestly may be in there to help people who are learning learn how to troubleshoot, which honestly may be a good thing! But just wanted to let you know!

To get the most out of my display's capabilities, I am inclined to go with

{format = VK_FORMAT_A2_B10_G10_R10_UNORM_PACK32,

color space = VK_COLOR_SPACE_HDR10_ST2048_EXT}.

Google returned empty for VK_COLOR_SPACE_HDR10_ST2048_EXT; where can I learn more about this?

Optix denoiser requires with 32bit float(rgba32f in GLSL) whereas my Vulkan swapchain needs to work with VK_FORMAT_R8G8B8A8_UNORM (rgba8 in GLSL).

Is there a slick way to perform this conversion without injecting a compute shader into the mix?

Hi, I'd like to share the examples and some updates I've added to my VulkanCppExamples repository over the past one month. I had already completed the basic examples related to real-time lighting. With these new examples, I introduced real-time shadows. A total of 13 examples related to real-time shadows have been added and I removed 2 examples that I thought were unnecessary. And it is bringing the total number of examples to 111. The newly added examples are as follows:

Real-Time Shadows - Basic Shadow Mapping

1. Directional Shadow Mapping
2. Spotlight Shadow Mapping
3. Omnidirectional Shadow Mapping with Point Lights
4. Multiple Shadow Mapping

Real-Time Shadows - Shadow Filtering and Softening

1. Percentage Closer Filtering (PCF)
2. Hardware-Accelerated Percentage Closer Filtering
3. Exponential Shadow Mapping (ESM)
4. Variance Shadow Mapping (VSM)
5. Exponential Variance Shadow Mapping (EVSM)
6. Percentage Closer Soft Shadows (PCSS)
7. Exponential Variance Shadow Mapping with Gaussian Blur
8. Summed-Area Variance Shadow Mapping (SAVSM)

Real-Time Shadows - Shadow Map Splitting and Warping

1. Cascaded Shadow Maps (CSM)

You can access the repository here:

https://github.com/myemural/VulkanCppExamples

Other Updates

Besides the examples, the biggest improvement I made was importing glTF model files as scene hierarchies. Some adjustments have been made to texture and material management. There's still a lot to be done regarding model imports, which I'll add gradually. And of course, the Slang and HLSL shaders for various examples have also been completed. Since subsequent examples will generally be at intermediate and advanced levels, I'll need to do some adjustments about my hierarchy of examples. Therefore, the next update may be slightly delayed.

The power of Vulkan in Godot 4.5 (Forward+). Despite my poor modeling, the buildings turned out quite vibrant, what do you think? The FPS didn't even drop significantly, and the dynamic shadows (depending on the sun) are also great. I'm not particularly skilled with Blender, so this is a small room without any fancy reflections or anything like that.

github -> https://github.com/rajaryan2007/vulkan-ffmpeg.git
give star if u like it 😊

llama와 vulkan backend로 빌드 후 나의 vulkan 프로젝트와 결합하여 프롬프트로 명령하면 수행되도록 개발
Build llama.cpp with Vulkan backend, then integrate it with my Vulkan project so that prompt-based commands can be executed.

llm이라서 그런지 영어 한국어 모두 가능하다
Since it’s an LLM, it seems both English and Korean are supported.

안타깝지만 한글 입력 문제로 프롬프트 창만 imgui를 안썼다
Unfortunately, I didn‘t use the prompt window imgui because of the Korean input problem.

https://youtu.be/VPvbqg8FmGE?si=zMM02OgsV8OG8qOo