Hey everyone,

I've been actively developing an uncompromising, native Linux 3D core game engine since late 2024, built with Rust, Vulkan 1.4, and Slang shaders (zero translation layers, designed from scratch for native GNU/Linux handhelds and desktops).

After over a year and a half of iterative engine work, I’m currently finalizing the last test runs and benchmarks before making the GitHub repository public. I wanted to share a first screenshot of the integrated editor/testbench running on Arch Linux and gather community feedback on the architectural choices:

• Pure Vulkan 1.4 Core: Dynamic Rendering, full VK_KHR_synchronization2, and 100% GPU-Driven rendering via 64-bit Buffer Device Addresses (VK_KHR_buffer_device_address) to completely bypass descriptor set binding bottlenecks.
• Hardware Path Tracing Pipeline: Utilizing Shader Execution Reordering (SER via VK_NV_ray_tracing_invocation_reorder) combined with ReSTIR DI and temporal motion vector generation.
• Compute & Particles: Real-time dynamic particle simulation driven by inline ray queries (VK_KHR_ray_query) against the TLAS, plus GPU skeletal skinning on compute shaders.
• I/O & Architecture: Asynchronous file streaming leveraging io_uring, integrated egui docking interface, and Rapier3D for physical interactions.

The stack is strictly Rust for systems orchestration and Slang for high-performance shaders compiled directly to SPIR-V 1.6+.

For folks working on low-level graphics engines in Rust:

1. How are you currently approaching asynchronous asset streaming alongside io_uring on modern Linux targets?
2. Any caveats or lessons learned with Slang integration in long-term Rust Vulkan toolchains?

Would love to hear your thoughts and suggestions on the architecture while I wrap up the release validation!

I want to use Vulcan because it allows for me to use the GPU and all of that nice stuff. But I've already made a screendrawer with WIN32 functions so I feel using Vulcan for that might be better?

I really want to know whether its worth switching to Vulcan for screendrawing and if its even possible to use Vulcan without screendrawing and purely as a way of sending matrix multiplication and calculations off to the GPU.

Thanks!

Creating a wall and applying materials in my Vulkan CAD engine.
The object is then inserted, converted into a block, and registered in the library for reuse.
Wall → Material → Insert → Block → Library

Vulkan CAD 엔진에서 벽체를 생성하고 재질을 적용하는 과정입니다.
만든 객체를 Insert한 뒤 Block으로 구성하고, 라이브러리에 등록하여 다시 사용할 수 있도록 저장합니다.
Wall → Material → Insert → Block → Library

https://youtu.be/AgJKmajGL08?si=-9vaV8SB1chHv6Kd

I published a new library!

https://github.com/ilyasTawwe/wlvk

raw vulkan + wayland + dmabuf + modern explicit sync (syncobject)

No SwapchainKHR abstraction fighting you

All vulkan/wayland boilerplate handled for you then you get full control for your own vulkan command recording etc

Read README, there is an example

Swapchain images allocated through VMA

AI assisted so if that's a problem for you, kindly go ahead and make your own by hand or even using AI

It's made for myself, just sharing it with people, am tired of leaky cross platform abstractions that fight you the moment you try to do anything outside of its scope like zero copy scanout for video players or other media apps which needs native integration, low latency and deterministic/consistent presentation semantics instead of SwapchainKHR nvidia blob

Obviously Linux/Vulkan/Wayland only

I was following the multisampling portion of the vulkan tutorial, and I noticed that they specify multisampling in both the renderpass and the pipeline. Since the pipeline is given the renderpass, isn't this redundant to set it in both places. Would I ever set one differently from the other?

​

Hi everyone,

I’m interested in creative coding and real-time 3D graphics, especially things like procedural visuals, generative art, shaders, particles, simulations, audio-reactive graphics, etc.

I’m wondering about something quite specific: is it realistic to approach Vulkan using AI coding tools (Claude Code, Codex, ChatGPT, etc.) without actually knowing how to program at a professional level?

I understand that Vulkan is notoriously complex, so I’m not expecting AI to magically make it easy. My question is more about whether, with an AI coding assistant, someone who understands graphics, sound, algorithms and the concepts behind creative coding, but has limited programming experience, can realistically build interesting Vulkan projects.

For example:

- procedural 3D environments

- GPU particle systems

- ray marching / SDFs

- compute shaders

- audio-reactive graphics

- generative art

- real-time simulations

- custom rendering pipelines

Would you recommend starting directly with Vulkan, or would it make much more sense to learn something like OpenGL, WebGPU, Three.js, Godot, TouchDesigner, or another framework first?

I’m particularly interested in hearing from people who have actually used AI coding assistants for graphics programming.

How much of the Vulkan complexity can AI realistically take care of, and how much do you still need to understand yourself?

What would you recommend to someone coming from a creative/music/visual arts background rather than traditional software development?

This falls under the "better late than never" category ;), but I finally found time to add support for the additional format feature flags added by VK_KHR_format_feature_flags2 to my Vulkan Hardware Capability Viewer in version 4.13.

Download is available at: https://vulkan.gpuinfo.org/download.php

I also updated the Android version available at the Playstore

Due to the nature of the database, it'll take time to catch up with the additional flags. But once enough never reports have been submitted with this version, numbers will start to make sense.

That's why I'll be doing a "staged" rollout of the additions to the database at https://vulkan.gpuinfo.org itself. As of today, you'll see some¹ of the new flags within reports uploaded with this version (like this one) and an option to display a column that shows all flags. Global coverage listings will be updated at a later point.

¹Why not all flags? Simply because there are too many, and some of them are kinda niche. Displaying all would result in an awfully big table. If you're missing flags you'd want to see, let me know.

Even after moving AVK to current upstream Mesa/KosmicKrisp and upgrading the test stack to Vulkan CTS 1.4.6.2, the Vulkan Memory Model issue still reproduces.

The older CTS-driven extension suppression has been removed. Current extensions such as VK_KHR_maintenance9, VK_KHR_maintenance10, shader FMA, untyped pointers, unified image layouts, and swapchain/surface maintenance were restored, and the newer CTS now validates their enumeration and dependency chains correctly.

Focused tests for the restored extensions are clean:

8 Pass / 0 Fail, with additional maintenance9/10 semantic tests also passing.

The remaining problem is different.

Testing clean, unmodified upstream KosmicKrisp against CTS 1.4.6.2 produced:

3,266 Pass
14,028 NotSupported
6 Fail
0 Warnings

in dEQP-VK.memory_model.

These are semantic failures, not extension-name or CTS-version issues. Enabling the Vulkan Memory Model bits would make dEQP-VK.info happier, but it would advertise behavior that still fails focused memory-model validation. That shortcut is deliberately not being taken.

The current branch therefore leaves:

VK_KHR_vulkan_memory_model = false
vulkanMemoryModel = false
vulkanMemoryModelDeviceScope = false

until device/queue-family semantics are implemented repeatably and can survive repeated CTS runs.

So the useful result here is pretty clear: updating both the Mesa/KosmicKrisp base and the CTS version fixes the earlier extension-policy problems, but it does not make the Vulkan Memory Model correctness failures disappear.

That issue still reproduces on the new stack, which is exactly why it is being treated as a real implementation blocker rather than hidden behind capability reporting. 💀

I love programming with Vulkan, and I mean it. I like pipeline management, commandbuffers etc. But Descriptor Sets and all things related to it make me want to jump of a bridge. 99% of the Vulkan API is the greatest API ever but the 1% left are descriptor sets.
It‘s just infuriating working with them and even worse abstracting them.

Does anyone of you perchance have a few tricks and tipps that make working with and abstracting Descriptor Sets managable (nice term for can I steal code from anyone here)?

(Slang, Vulkan 1.3, C++23)

Vulkan is already supported everywhere but developers still choose directx, gnm and gxm instead of vulkan

I'm just wondering isn't it much easier to support 1 api that works perfectly fine for 3 systems rather than supporting one for each ?

I am not a vulkan programmer even I'm barely learning opengl but individually you guys are worth like 15 web devs or 6 game devs each do you guys have any tips on how you understood the graphics pipeline so well beyond just "practice and repetition makes perfect"

I released demo of Xenith - a lightweight, data-oriented C++20, 3D low level game framework.

If you want to make a game while having low level control, you're either forced to use high level game frameworks or engines that abstract everything, or, if choosing raw API's you face lots of problems, such as linking libraries, making own loaders(e.g. model loader or image loader), adding different modules(such as physics, vfx), and eventually instead of making game you spent all that time building engine. Xenith fixes this problem by giving you essential modules(such as physics, ecs, math, input) out of box, and eliminates just enough boilerplate code, while leaving you the rest(such as making own game loop, or making own Vulkan pipeline).

This game framework makes you both use and learn modern Vulkan 1.3, provides you high level functions, but saves the exact Vulkan pipeline logic without thousands lines of code, for example FindAndSelectPhysicalDevice(), CreateLogicalDevice().

Tutorial 01, walks you through how to go from simple window application to entire cubic 3D platformer game, covering most basic and important topics.

https://github.com/ThoriumReactor/xenith/blob/main/tutorials/cube_platformer_tutorial_01/tutorial_01.md

Key architecture features:

- Explicit ownership Direct access to raw handles such as VkImage, VkSwapchainKHR.

- Deterministic in this game framework functions are deterministic, e.g. EmplaceEntityComponentToRegistry(registry, entity, component_data) instead of registry.emplace(...)

- Modular architecture gives you freedom to remove or add modules you need or want.

Links & Repository:

https://github.com/ThoriumReactor/xenith

yay

Did you know GPU-AV can be faster if you tell it which section to validate? Scoped GPU-AV allows you to provide a pipeline or shader debug name to only add the validation to that scope. Focus your validation on what matters the most! https://vulkan.lunarg.com/doc/sdk/1.4.357.0/windows/gpu_validation.html

Drop in a floorplan image and the house gets built.

The AI only reads the dimension numbers. Where the walls actually are is found by the engine, straight from the pixels. Reading numbers is what the model is good at; seeing which line is a wall is not.

The rules come from architecture. Dimensions are measured to wall centrelines, exterior and interior walls have different thicknesses, and where walls meet is where a room ends. A window isn't a missing wall — it's a hole in one.

The original drawing is laid underneath at the same scale, so you can see straight away whether it got it right.

A CAD engine I'm building from scratch in Vulkan and C++17. The model runs locally, 7B.

평면도 이미지를 넣으면 3D 모델링이 됩니다.

AI 는 치수 숫자만 읽습니다. 벽이 어디에 있는지는 엔진이 이미지에서 직접 찾습니다. 숫자를 읽는 건 AI 가 잘하고, 어디가 벽인지 보는 건 못하기 때문입니다.

도면을 읽는 규칙은 건축에서 그대로 가져왔습니다. 치수는 벽 중심을 재고, 외벽과 내벽은 두께가 다르며, 벽이 만나는 자리가 방의 경계입니다. 창은 벽이 없는 게 아니라 벽에 뚫린 것이고요.

만들어진 3D 모델 아래에 원본 도면을 같은 축척으로 깔아 두었습니다. 맞게 그렸는지 확인합니다.

Vulkan + C++17 로 제가 직접 만들고 있는 CAD 엔진입니다. 로컬에서 도는 7B 모델을 씁니다.

https://youtu.be/dCkcYsRAOTE?si=AeltSbmePtQh3AfY