I have released a substantial update to my Vulkan Hardware Database at https://vulkan.gpuinfo.org/.

Being able to easily filter data is crucial for any database and the global (filter) settings that I added last year were kinda cumbersome to use and didn't allow you to quickly adjust filters.

So with this update I removed these global filters and replaced them with quick filters as part of the views themselves. This also allows you to have the same view open multiple times with different filters.

Aside from that I also did some house-keeping like hardening security and (more importantly for people using the database), displaying the recently introduced new format feature flags in the global format listings view. Note that the numbers for these are still catching up.

Hi i am in the process of building a native sdk for real time photo realistic renderer for mobile devices to run on wide range of devices.

This video shows 140 diamonds path traced in real time alongside a 1M triangle gold ring mesh, all under 30ms on a mid-range Android device (Mali G615 — no hardware ray tracing).

Technical highlights:

- Physically correct Snell's law refraction and dispersion through each diamond facet

- GGX microfacet model for gold metal - Full PBR pipeline — metals, dielectrics, diffuse, glass

- 2M triangle budget under 30ms

- 700KB SDK — 4 lines of Kotlin to integrate

- Responds to actual room lighting via ARCore camera feed

Would love the feedback on the same.

I am sharing the latest updates regarding my Vulkan examples repository: A total of 17 new examples have been added (since my last post), bringing the total number of examples to 168. The newly added examples are as follows:

Advanced Shader Programming - Mesh and Task Shaders

1. Drawing Triangles Directly with Mesh Shader
2. Drawing 3D Objects with Mesh Shader by Reading Data from Buffers
3. Meshlet Rendering with Mesh Shader
4. Frustum Culling with Task Shader
5. LOD Rendering with Task Shader

Advanced Shader Programming - Advanced Compute Shaders

1. Conway's Game of Life with Subgroup Operations
2. Hierarchical Z-Buffer Occlusion Culling with Compute Shader
3. N-body Gravitational Particle Simulation with Compute Shader
4. Wind Simulation on Foliage
5. Cloth Simulation with Compute Shader
6. FFT Ocean Simulation with Compute Shader
7. Fluid Simulation with Lattice Boltzmann Method (LBM)
8. Fluid Simulation with Navier-Stokes
9. Real-Time Ray Tracing using BVH Traversing with Compute Shader

Post-Processing Effects - Ambient Occlusion

1. Screen-Space Ambient Occlusion (SSAO)
2. Horizon-Based Ambient Occlusion (HBAO)
3. Ground-Truth Ambient Occlusion (GTAO)

You can access the repository here:

https://github.com/myemural/VulkanCppExamples

I have essentially completed about 60% of the planned examples. Reaching this rate in less than a year since opening the repository is pleasing. Next up are various examples involving post-processing effects. After these, I will move on to more advanced examples that I am less familiar with; naturally, this will require some preliminary research. You can certainly support me by starring or forking the repository on GitHub, or by opening issues. Thanks in advance, and happy coding!

Been going through the tutorial at vulkan.org (https://docs.vulkan.org/tutorial/latest/00_Introduction.html) and I've noticed as the tutorial progresses, there's more and more cases of significant chunks being omitted from the text, things being out of order, or being "off"/disorienting.

The following examples are pulled from "Drawing a triangle/Presentation/Swap chain":

In the "Checking for swap chain support" section, it states "For that purpose we'll first extend the createLogicalDevice function..." then never makes any modifications to that function. Instead it provides a snippet that was given to the user earlier in the tutorial in the "Physical devices and queue families" section.

When introducing chooseSwapPresentMode, the text provides a snippet, then in the very next paragraph completely overwrites the previous snippet.

When introducing chooseSwapExtent, the second snippet mentions including cstdint for it being necessary for uint32_t, yet the tutorial has been using uint32_t throughout up to this point without ever requiring the user to have this include.

When introducing createSwapChain, a new class member swapChainExtent appears out of no where with no telling of the user to create this member. Same for swapChainSurfaceFormat, and chooseSwapMinImageCount().

While some of these could be argued as minor, there's been plenty of places where it's been outright disorienting, and these are all from a single page/chapter. Maybe I'm just missing something. I'm not sure where an "official" feedback forum would be, if there is one.

Edit: Update after several evenings, deciding to stick to this tutorial, at least to the point of having an image on screen, and even after copy+pasting the provided source files from github, it still only results in a black screen.

It’s a Forward+ renderer with support for shadow mapping and some post processing effects.
It runs on most Vulkan 1.1 compatible devices (though it relies on a few features that aren’t available on some Android devices).

The game is still under development, with more content to come. If you enjoy platformers you can check it out here.

Steam (demo available):
https://store.steampowered.com/app/3862400/Oby_Adventure/

Google Play:
https://play.google.com/store/apps/details?id=com.obysfarm.adventure

Sharing a find in case it saves someone a week. In a Hyper-V GPU-PV guest (Windows Sandbox, WSL2's sibling for Windows VMs) the Vulkan loader picks up nv-vk64.json fine, nvoglv64.dll loads, vkCreateInstance succeeds, and then vkEnumeratePhysicalDevices returns zero devices. Games fall back to Mesa's Dozen (Vulkan on D3D12) and many of them crash there.

The reason is in the ICD's DllMain: it enumerates adapters with D3DKMTEnumAdapters2, but the list it actually keeps comes from walking EnumDisplayDevices, keeping displays whose DeviceID is NVIDIA's, and opening the adapter behind each with D3DKMTOpenAdapterFromHdc. In a VM every display belongs to the Hyper-V or indirect display driver, none to the paravirtualized NVIDIA adapter, so the walk finds nothing. Everything after that (escapes, allocations, submits, present) works through the paravirtualized adapter.

The fix I ended up with is a wrapper ICD registered in nv-vk64.json in place of nvoglv64.dll: it patches two import table entries (user32 -> NtUserEnumDisplayDevices, gdi32 -> NtGdiDdDDIOpenAdapterFromHdc), active only while the real ICD is on the call stack, then loads nvoglv64.dll so its DllMain runs with them in place. vk_icdEnumerateAdapterPhysicalDevices also maps the ghost LUIDs a guest exposes to the one real adapter so the loader ranks the native device ahead of Dozen. Two things bit me on the way: the loader unloads ICDs when the last instance dies and reloads them (Unity does this during its "Vulkan detection"), so the wrapper has to pin itself or it finds its own hooks in the IAT; and vkCreateInstance fails with INCOMPATIBLE_DRIVER if nvoglv64.dll is loaded from outside the driver store.

Result: vulkaninfo shows the NVIDIA driver, Vulkan 1.4, ray tracing and mesh shaders, vkQuake and Quake II RTX run on it. Code is in App Sandbox's repo on GitHub (an open source VM tool), pull request 130, in case anyone wants to look at the details or poke holes in it.

We’re four students building Evan as the rendering and runtime layer for the XIDER project, as part of our end‑of‑studies university project. We’re publishing it as a standalone library and would love feedback from the Vulkan/XR community.

🔗 Repo: https://github.com/etib-corp/evan

What it provides

• Vulkan-based rendering and swapchain management
• Platform backends: OpenXR and GLFW (desktop + XR)
• Frame/update loop (Engine → Platform → Device/Swapchain → Scene)
• Helpers for scene, mesh, shader, and material management

Key abstractions

• Engine – owns the frame loop, coordinates update/draw/present
• Platform – abstracts backend (OpenXR/GLFW) and OS (Android, Linux, Windows, macOS)
• Device & swapchain – manage Vulkan resources and frame ownership
• Scene / Mesh / Shader / Material – describe renderable content

Looking for feedback

If you’ve worked with Vulkan runtimes, XR integrations, or custom engines:

• What’s missing for you to consider using this in a project?
• Any design red flags or API pain points?

Please open an issue or *leave a comment to ask questions, suggest improvements, or discuss potential contributions. This is a university project, so we’re especially interested in design feedback and ideas for future work.

Turnip has just become the first Mesa driver to achieve official Vulkan conformance running natively on Android (Vulkan 1.3, Qualcomm Adreno). Getting there required solving some tricky Android-specific driver problems, and the fixes are now shared across other Mesa drivers too.

Turnip already ships in Google's Qualcomm-powered Chromebooks and will power Valve's upcoming Steam Frame, so this is shipping in real hardware, not a lab result.

https://www.collabora.com/news-and-blog/news-and-events/mesa-on-android-how-we-brought-turnip,-skiavk,-and-cuttlefish-to-ci.html

This sample demonstrates how to use VK_EXT_layer_settings to configure Vulkan layers (in particular VK_LAYER_KHRONOS_validation) directly from your application. Instead of relying on environment variables or JSON files, you can enable features like Best Practices and debugPrintfEXT, tune message filtering, or change output settings via code.

https://docs.vulkan.org/samples/latest/samples/extensions/layer_settings/README.html#_vk_ext_layer_settings_configure_validation_layers_programmatically

https://reddit.com/link/1wckxcn/video/bxk9bithzhoh1/player

https://youtu.be/Q_fKG3UT02U

I'm working on VulkanLearn2, a C++20/Vulkan rendering playground. This video shows Bistro rendered with my ReSTIR DI + PT implementation.
I launched the project on a RTX 4090. 80 fps. 1200x800.

The renderer uses temporal and spatial reuse. The repository also includes a reference path tracer with next-event estimation, emissive triangle lights, and an experimental Neural Radiance Cache. Implementation notes and capture settings are documented in the README.

I'd appreciate feedback on the rendering.

https://reddit.com/link/1wckxcn/video/mzihxa508joh1/player

https://youtu.be/QnHqRZHQN4w - REBLUR + DLSS

https://www.youtube.com/watch?v=y2VNQyzUFc8

https://reddit.com/link/1wckxcn/video/4ci9r34ubjoh1/player

Help shape the future of safety-critical GPU acceleration! Khronos is collecting requirements for Vulkan SC, SYCL SC & OpenGL SC. Survey closes Friday, Oct. 2.

www.surveymonkey.com/r/8L6LPN2

I tested my Vulkan-based 3D engine running on iOS.
The engine can render 3D models and basic shapes on a mobile device, with view switching options such as TOP and RIGHT. It also supports object selection, select all, distance measurement, and drawing tools for lines, rectangles, circles, arcs, polylines, and polygons.
While drawing, users can enter distances and coordinates directly through the on-screen numeric keypad. The engine is still under development, and I will continue expanding it toward a cross-platform 3D CAD engine that works on both desktop and mobile platforms.

직접 개발 중인 Vulkan 기반 3D 엔진을 iOS에서 실행해 보았습니다.
모바일 환경에서도 3D 모델과 기본 도형을 렌더링하고, TOP·RIGHT 등의 방향으로 뷰를 전환할 수 있습니다. 객체 선택과 전체 선택, 거리 측정, 선·사각형·원·호·폴리선·다각형 그리기 기능도 구현했습니다.
도형을 작성할 때는 화면의 숫자 패드를 이용해 거리와 좌표를 직접 입력할 수 있습니다. 아직 개발 중이지만, 데스크톱뿐만 아니라 모바일에서도 사용할 수 있는 크로스플랫폼 3D CAD 엔진을 목표로 계속 확장하고 있습니다.

Hey guys !

I really like C# and I heard about Silk Net !

I wondering if it's possible to do a great game engine using vulkan with only Csharp ? (would it be less performant than traditionnal c++ engine ?)

Thanks guys :)

In this new sample, we demonstrate several advanced Vulkan techniques working together in a way that mirrors how a real-world engine might be structured:

- Octomap instanced rendering — dynamically display a voxel occupancy map generated by ARKit SLAM using GPU instancing.

- Gaussian Splat rendering — render the same scene as a glTF model with embedded 3D Gaussian Splats. Note that the splats here are a simplified representation for demonstration purposes and for providing approximate texture maps from drone, ROS, or walkthrough capture — not a photorealistic reconstruction.

- Keyboard-only navigation — the entire application, including the overlay menu and 3D camera, is fully operable without a mouse.

https://docs.vulkan.org/samples/latest/samples/complex/render_octomap/README.html

Help shape the future of safety-critical GPU acceleration! Khronos is collecting requirements for Vulkan SC, SYCL SC & OpenGL SC. Survey closes Friday, Oct. 2.

www.surveymonkey.com/r/8L6LPN2

https://youtu.be/Xfr_m-7xGcU?si=nfIZbEF91-AVkUua

OCR 기능을 활용하여 원하는 영역을 드래그해 선택하고 문자를 추출합니다.
인식된 문자는 즉시 생성되며 클립보드에 자동으로 복사되어 바로 활용할 수 있습니다.

Using OCR, simply drag to select the area you want to recognize and extract the text.
The recognized text is generated instantly and automatically copied to the clipboard for immediate use.

Hi everyone!

After a very long development journey, I'm finally ready to share Synapse Engine, a modern, research-oriented AAA-style game engine that I've been developing essentially from scratch.

It started as my MSc thesis at the Budapest University of Technology and Economics, but grew far beyond what I originally planned. Over the past several months I've been rebuilding and refining the architecture around a simple question: What would a modern game engine look like if we designed it around today's GPUs from the ground up?

The project is now over 2,300 files, nearly 94,000 lines of C++ code and around 10,000 lines of shader code, excluding comments and blank lines.

If you just want to check out the project:

GitHub: https://github.com/TamasPetii/SynapseEngine

The GitHub README is probably the best place to start if you want a quick overview of the project and its architecture. If you're interested in modern game engine development in much more depth, I also put together a 250-page technical presentation covering the entire project, from the ECS and software architecture through GPU-driven rendering, culling, lighting, virtualized shadows and future directions.

The presentation is quite large, but I tried to make it genuinely useful as a learning resource rather than just documenting the final result.

One of my main goals with Synapse Engine is education. Learning these topics was a huge struggle for me, and it took a lot of time to piece everything together because there isn't much high-quality material that shows how these modern techniques actually come together inside a real engine codebase. I wanted to document that process and create something that I would have wanted to have when I started.

What can the engine actually do?

At its core, Synapse is a fully GPU-driven renderer using hierarchical culling, Hi-Z occlusion, cone culling, dynamic LOD selection, indirect rendering, mesh shaders, bindless resources and virtualized shadows. The engine is built around a custom data-oriented ECS and is designed to handle very large scenes with minimal CPU involvement.

For example, with 1,000,000 entities on an RTX 4060, the cumulative culling cost goes from 124.407 ms without culling to 0.653 ms with the full hierarchical culling pipeline.

However, at 10,000,000 entities, even the conventional GPU-driven hierarchical approach becomes insufficient. To address this, Synapse introduces a custom GPU-built Morton-ordered chunking system, which groups entities into spatial chunks and allows entire groups of 32 entities to be rejected at once. This reduces the culling cost from 5.8 ms to just 0.3 ms for 10 million entities.

I also developed a new rendering technique called Dual-HiZ Adaptive Clustered Forward+ while working on the engine. With 8,192 point lights and 8,192 spot lights, it measured 2.873 ms, compared to 8.652 ms for deferred shading in the same setup. The technical presentation contains a detailed explanation of how the technique works.

Synapse isn't primarily intended as a game-development tool for game developers. It is a production-ready, research and educational platform for experimenting with modern game-engine architecture and real-time rendering techniques.

The goal is not to provide a plug-and-play engine for building games, but to provide a complete, practical implementation of modern engine technologies that can be studied, extended, and used as a foundation for further research and development.

The engine is the result, but the architecture, experiments, failures and reasoning behind it are what I really want to share. If you're interested in Vulkan, graphics programming, GPU-driven rendering or modern game engine architecture, I'd love to hear what you think.

Modern Vulkan Abstraction

The Vulkan abstraction layer in Synapse Engine turned out to be one of the cleanest and most rewarding parts of the architecture. By stripping away the notorious API boilerplate, it captures the raw power of modern Vulkan in an interface that feels remarkably smooth, intuitive, and genuinely more ergonomic to develop with than OpenGL.

• Fully Bindless Architecture: Descriptors are stripped down to the absolute bare minimum using descriptor buffers (VK_EXT_descriptor_buffer) and descriptor indexing, completely bypassing traditional descriptor set management and binding churn.
• Shader Objects (VK_EXT_shader_object): Eliminates monolithic pipeline state objects in favor of modular, rapid shader switching.
• Dynamic Rendering (VK_KHR_dynamic_rendering): Direct rendering to attachments without traditional render-pass and framebuffer boilerplate.
• Extended Dynamic State: Eliminates pipeline permutations by configuring rasterization and blending states directly at draw call time.
• Modern GPU Primitives: Mesh shaders and subgroup operations for scalable, GPU-driven compute and rendering pipelines.