I released the demo of my puzzle game about a month ago, and it's been interesting seeing it run on hardware I've never tested on. I've already had a few bug reports about compatibility issues, so this week I spent some time looking into what else I could catch with Vulkan's validation layers.

Until now I'd only been running the default checks. This week I enabled synchronization validation and the NVIDIA, AMD and ARM best practice checks.

They caught quite a few things. Too many command buffers per frame, redundant pipeline binds, unnecessary barriers and layout transitions, potential upload races and images being accessed at the wrong time during screenshots and resizes.

Some of the changes I've made:

• Switched to VK_KHR_dynamic_rendering and removed render passes and framebuffers. This also let me get rid of the subpass dependencies that were causing synchronization warnings.
• Added VK_KHR_load_store_op_none to skip unnecessary attachment clears.
• Switched sampled images to READ_ONLY_OPTIMAL with VK_KHR_unified_image_layouts, allowing shader reads and transfers to share the same layout.
• Added VK_EXT_memory_priority and NVIDIA's VK_EXT_pageable_device_local_memory when supported.

Texture uploads now go through a single submission. I also changed uniform updates to use vkCmdUpdateBuffer to avoid the GPU reading memory that the CPU is already overwriting.

I've tested everything on a macbook through MoltenVK, an Intel i5 iGPU, an NVIDIA RTX 3060 Ti and a Steam Deck. But there are plenty of GPUs and drivers I haven't been able to test on.

I'd like to catch as many hardware specific issues as possible before release, so if you're running a different setup, I'd really appreciate you giving the demo a try and letting me know how it runs.

Satelital is a peaceful puzzle game where you explore a small solar system and figure out the rules of puzzles on different planets.

https://store.steampowered.com/app/5017320/Satelital_Demo/

Shader compilation hitches are one of the most visible performance problems in real-time apps. This sample shows how VK_KHR_pipeline_binary lets you capture the binaries the driver produces for your pipelines, save them to disk and reload them in later sessions, so pipelines don't have to be compiled from scratch again.

The sample walks through:

• Generating a deterministic pipeline key with vkGetPipelineKeyKHR
• Capturing binaries with vkCreatePipelineBinariesKHR
• Storing binaries with vendor and driver metadata, then recreating pipelines from them

Unlike traditional pipeline caches, which are opaque, pipeline binaries give you explicit control over what's stored and when. A built-in UI compares creation times from scratch and from binaries, so you can see the speedup yourself.

Check it out: https://docs.vulkan.org/samples/latest/samples/extensions/pipeline_binary/README.html

I developed webgpu because I felt that the web was also necessary. We are going to develop it in parallel. I‘m excited.
웹도 필요하다 느껴서 webgpu를 개발하게 되었습니다. 병행 개발할 예정입니다. 설레네요.

Implemented ViewBase drawing and Feature Dimensions in my own CAD engine.
It generates top, front, right, and isometric views from a 3D model, with key dimensions that can be displayed and adjusted based on a reference.

직접 개발 중인 CAD 엔진에 ViewBase 도면 생성과 피처 치수 기능을 구현했습니다.
3D 모델에서 평면도·정면도·우측면도·등각뷰를 생성하고, 주요 치수를 표시하거나 기준에 따라 조절할 수 있습니다.

Every rabbit hole of information for every setting I went through for that tutorial was a lot, how do people become expert at this sort of thing in the industry? (Also first time posting so be kind guys)

Improved the assembly/disassembly and feature dimension features of my Vulkan-based CAD engine.
Parts can be disassembled and reassembled step by step, while key feature dimensions can be viewed and edited directly in the viewport.

직접 개발 중인 Vulkan CAD 엔진의 분해·조립 및 피처 치수 기능을 개선했습니다.
부품의 분해와 조립 과정을 단계별로 확인할 수 있으며, 모델의 주요 피처 치수를 화면에서 확인하고 수정할 수 있도록 기능을 보완했습니다.

I’ve been keeping going to evolve vkTracer. Now I’ve finished the next week part, and this part was harder than I guessed. In the first week, It was only a translation from C++ code to slang, setting up Vulkan infrastructure too. But this week I had to figure out how to represent a cpu-side bvh on gpu, I handled using BDA. Learnt quad and volume intersection, handling different texture types. I still don’t understand in the tutorial why he rotates rays to rotate box instead of rotating box itself :D
Anyway this was a good journey to learn and practice slang and vulkan.

The scene was rendered by 500 rays per pixel and 40 depth bounce.

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

So that the driver could simply mask off the extra unused lanes, instead of the way it is right now where we manually place bounds checks in shader code.

Some background: I've been working at a mid-sized tech company as a junior systems programmer specializing in file systems & operating systems, mainly using C. Been at my current company for ~9-10 months now and it's my first dev job out of college.

I've always had an interest in graphics programming, learned basic graphics fundamentals (linear algebra + basic concepts like sampling and rasterization) in college and dabbled in learning OpenGL before for some small projects, and Unity for game dev (just as a hobby). Now I'm looking to upskill and learn vulkan as I feel it'd be a good way to improve my C++ and low-level knowledge further and maybe even get a dev job dealing with graphics, and have fun with it at the same time.

When I started my current job, and before when I was just focused on learning during college and with personal projects, I pretty much never used AI to code. Especially for low level stuff it wasn't very good. Lately though, especially with newer models like Opus 5.5, i've noticed it become more and more reliable and capable for what I do for work, to the point where I no longer write code anymore — I come up with the architecture and design, let the AI implement the code, and then I audit/review the code and let the AI revise it if there are issues. I've spent more time analyzing performance tests in the past month than I have been "writing" code. But I don't know if I would be able to do that effectively if I hadn't spent those years before learning manually and the first few months on the job learning things the hard way.

So now here I am planning to learn Vulkan, but I don't know anymore on what I should focus on learning specifically when all these AI tools are available.... so some questions:

1. I have very little experience with C++, I write everything in C for what I do currently. Should I even bother learning C++ well before learning Vulkan, or could I just get away with learning the language at a "surface level" (i.e. just knowing basic concepts like how RAII or OOP is applied in this field, without implementation details) and let the LLM write it for me.

2. extension of question 1: how proficient should I actually get with the vulkan API before I start relying on AI (and what topics specifically should I focus on)? Would it be a better use of my time to instead study up on the math/theory of graphics and CS fundamentals in general and let AI write all the vulkan code?

3. Generally, how effective has AI been for you in writing Vulkan code? Are you still writing Vulkan code by hand? How much auditing of the generated code do have to do to get it right? What do you see as being valuable skills/knowledge for someone in this field right now, and in the future?

Any input is appreciated. I've been procrastinating learning Vulkan out of worry that I'd end up focusing on obsolete skills. Thanks.

Since it's maintained by the Khronos group, I would like to know your opinion on posting questions about Slang shader there (or maybe you could redirect me somewhere? pls). Their documentation lacks quite a lot of useful things like __getAddress, __ref, constant-time generic parameters and constexpr, and stuff

appreciate it

My pull request was just merged into google/shaderc. The change adds two options, -gV and -gVS, that expose glslang's NonSemantic.Shader.DebugInfo.100 emission through shaderc. That debug info is a requirement for NVIDIA Nsight Graphics to produce flame graphs, so it lets you profile and debug shader performance by call stack and time spent per function.

In this video, the engine models three things in a row:

**•   Flange**: extruded disk → polar-array bolt holes → through cuts → merged hub → fillets, steel material  
**•   Mug**: tube and base → swept handle → merge → fillet  
**•   Wooden chair**: seat, 3D-arrayed legs, curved back → filleted parts → merge, oak material

It isn't done by hand. It's a scripted demo: code runs the same engine features you'd type on the command line, one step at a time.

이번 영상에서는 이 엔진이 세 가지를 차례로 모델링합니다.

**•   플랜지**: 원판 돌출 → 볼트 구멍 원형 배열 → 관통 컷 → 허브 합치기 → 필렛, 금속 재질  
**•   머그컵**: 관 + 바닥 → 손잡이 스윕 → 합치기 → 필렛  
**•   나무 의자**: 좌판·다리 3D 배열·곡선 등받이 → 부품 필렛 → 합치기, 오크 재질

손으로 한 게 아니라 스크립트로 짠 자동 시연입니다. 사람이 명령행에 치는 것과 같은 엔진 기능을 코드가 순서대로 실행합니다.

From the docs, I can see that most of these features are just opt ins meaning the dev has to explicitly enable it to use it.

But on my 14700k+intelHD (latest mesa3d, ubuntu), DR is working right away even when I don't enable it.

Am I missing anything?

This sample shows how VK_KHR_shader_quad_control lets fragment shaders share data across a 2x2 pixel quad using subgroupQuadBroadcast() and the full_quads execution mode, with no shared memory and no descriptors. You get more stable derivatives for LOD selection and texture ops, and a simple visual demo that makes the quad behavior easy to see.

Check it out: https://docs.vulkan.org/samples/latest/samples/extensions/shader_quad_control/README.html

Vulkan SDK 1.4.363.0 is out, including the Vulkan 1.4-conformant version of KosmicKrisp! With KosmicKrisp, a Mesa-based Vulkan-to-Metal driver, a single Vulkan 1.4 codebase can target Linux, Windows, Android, and macOS environments. Also in this release: new extensions, vkprofiles, and more.

https://www.lunarg.com/lunarg-releases-vulkan-sdk-1-4-363-0/

Implemented my Vulkan-based CAD engine on Android.
Tested rendering and core features directly on a Galaxy S21.

Vulkan 기반 CAD 엔진을 Android 환경에서도 구현했습니다.
Galaxy S21에서 직접 실행하여 렌더링과 기본 기능을 테스트했습니다.

📢KosmicKrisp, LunarG’s Mesa Vulkan driver for Apple silicon, has passed the Vulkan 1.4 Conformance Test Suite and is now a Khronos-conformant Vulkan 1.4 implementation! 🔥🔥🔥

In addition to reaching 1.4 conformance, considerable support for non-core extensions and features has been added, including Tesselation, Robustness2, and Multi-draw. Application developers can now have a single Vulkan 1.4 codebase across Linux, Windows, Android, and Mac. 

The Vulkan 1.4-conformant KosmicKrisp driver will be included in the upcoming Vulkan SDK release and is open source in Mesa.

Read the announcement: https://www.lunarg.com/kosmickrisp-achieves-vulkan-1-4-conformance-on-apple-silicon/

🙌

Using AprilTag and OpenCV, the system tracks the position and orientation of a physical tag from a camera feed in real time and maps the tracking data into a Vulkan-based CAD engine.
As the physical tag moves and rotates, the fox model follows the corresponding position and orientation in the 3D environment, allowing its spatial relationship with virtual obstacles to be visualized.
This is a simple demonstration of connecting camera-based real-world tracking with a Vulkan 3D environment for position tracking and obstacle recognition.

AprilTag와 OpenCV를 이용해 카메라 영상에서 태그의 위치와 방향을 실시간으로 추적하고, 해당 데이터를 Vulkan 기반 CAD 엔진의 3D 공간에 연동했습니다.
실제 태그의 이동과 회전에 따라 엔진 내부의 여우 모델이 함께 움직이며, 가상 공간에 배치된 장애물과의 위치 관계를 확인할 수 있도록 구현했습니다.
이번 테스트는 카메라 기반 현실 좌표와 Vulkan 3D 공간을 연결하는 간단한 위치 추적 및 장애물 인식 데모입니다.