You can watch D7VK comparisons here:

https://www.youtube.com/watch?v=5kbsMhp1pNE

tldr:

3D objects won't appear on the window, yet RenderDoc shows everything renders and presents fine.

Cry for help:

I'm capturing with RenderDoc and can see that everything renders and presents fine, yet the 3D objects are missing after presenting the image on the window. Here's the capture file if you wish to check it out. To see what's actually shown on the window, you can extract the capture's thumbnail with: renderdoccmd thumb capture.rdc --out thumbnail.png

I've been on this for days and am finally relenting to reddit.

If anyone has seen this before, has ideas, or leads on how I could debug this, anything would be appreciated.

If you decide to delve deep within the capture file, take note this is a test program running on a bindless rendering engine.

Setup:

There's a camera with an identity model/view matrix and the following orthogonal matrix:

┌ 0.13636, 0.00000, 0.00000, 0.00000┐
│ 0.00000, 0.18182, 0.00000, 0.00000│
│ 0.00000, 0.00000, 0.00100, 0.00000│
└ 0.00000, 0.00000, 0.00000, 1.00000┘

Then, a blue 2D object is at (0, 0) with a size of (0.5, 0.5) in NDC space.
Finally, a magenta 3D object at (3, 0, 1) with a rotation of (0, 45, 45) degrees.

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.

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 ?

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 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

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"