In this repo: https://github.com/DrewGilpin/EsenthelEngine

Claude Code did ~97% of the work. Added some Vulkan specific tutorials:




Tutorial_17_RayTracing — Hardware ray tracing
The marquee Vulkan-vs-OpenGL feature. Renders a small scene (ground plane + 3 colored boxes) entirely via vkCmdTraceRaysKHR running on the GPU's RT cores — no rasterization at all. Includes:

BLAS (bottom-level acceleration structure) built from raw vertex/index buffers
TLAS (top-level) with one instance of the BLAS
4-shader raytracing pipeline: raygen + primary miss + shadow miss + closest hit
Shader binding table built per Vulkan spec alignment rules
Hardware ray-traced primary rays + hardware ray-traced shadow rays from a directional light, with Lambert shading using flat geometric normals computed in the closest-hit shader via SSBO lookups into the vertex/index buffers
OpenGL has no hardware RT path at all — the legacy GL RT extensions are NV-only and dead. The OpenGL build of this tutorial compiles cleanly but only renders the "Ray tracing: N/A on OpenGL" HUD line.

GPU requirements: any GPU exposing VK_KHR_ray_tracing_pipeline, VK_KHR_acceleration_structure, and VK_KHR_deferred_host_operations. Verified working on AMD Radeon RX 6650 XT (RDNA2) under Mesa RADV; should work on any RTX 20-series+ NVIDIA, RDNA2+ AMD, or Arc Alchemist+ Intel GPU.





Tutorial_17_AsyncCompute — Particle sim on a dedicated compute queue
Demonstrates Vulkan's async-compute feature: a 4096-particle gravity simulation runs on a separate compute queue (when the GPU exposes a queue family with VK_QUEUE_COMPUTE_BIT but NOT VK_QUEUE_GRAPHICS_BIT) while the engine's frame rendering happens in parallel on the graphics queue. OpenGL has no equivalent — it is strictly single-queue.

The HUD reports whether the GPU has a dedicated compute family. The compute shader is hand-written GLSL (particle_update.comp), pre-compiled once to SPIR-V via glslangValidator and checked in as a C header (particle_update_spv.h) so the build needs no shader tooling installed.






Tutorial_17_Benchmark — Renderer throughput benchmark
Renders 50 animated characters in a 10×5 grid with vsync disabled, an atmospheric sky, the FPS counter, and the active API name. On Vulkan it also shows a per-phase GPU time breakdown (Prepare / GBuffer / Light / Sky / Blend / Post) measured via real vkCmdWriteTimestamp query pools. Useful for measuring relative renderer throughput between OpenGL and Vulkan builds on the same hardware.

The GPU timer API (Engine/H/Graphics/GpuTimer.h: GpuTimerEnable, GpuTimerMs, GPU_TIMER_PHASE) is exposed engine-wide so any tutorial can read per-phase GPU times. On DX11/GL it compiles to stubs that return 0.


See README.md for more info.

Wow! Amazing!
Didn't know you could do so much with Claude.
I really want to add Vulkan support at some point, to check if it can improve performance / reduce cpu usage.

I tried compiling/running on Windows to see performance differences, by changing project preprocessor DX11->VULKAN, but looks like Windows is not yet supported.

After making some changes, it compiled but crashed on:
vkGetPhysicalDeviceSurfaceCapabilitiesKHR(VkPhysDev, VkSurf, &capabilities);
Exception thrown: read access violation.
vkGetPhysicalDeviceSurfaceCapabilitiesKHR was 0xFFFFFFFFFFFFFFFF.

So it looks like it needs more effort.

As of this commit:

https://github.com/DrewGilpin/EsenthelEn...7d7482cbe6

It works on Windows 11 w/ NVidia RTX A2000 8GB, it also seems to still work on the Linux AMD Mesa RADV driver.

It is completely unoptimized both code-wise and shader-compile-options wise so I would expect it to be much slower than OpenGL or DX11 at this point.

Thanks for the great engine, Claude complimented also it saying it is well designed with good platform abstraction.

First of all: Very cool stuff!
But also: Isn't the whole point of Vulkan that it's faster than OpenGL/DX11?

Thank you Fex and Claude! ❤️
Tottel: yeah of course but that was AI generated, so probably could make use of hand-tuning, and it's still WIP.

Disclaimer - I wrote the forum post then let AI rephrase it:

Vulkan is not automatically faster than OpenGL or DX11. Sometimes it wins, sometimes it loses, and sometimes there is barely any difference. In a lot of cases, the real advantage is lower CPU overhead and more stable frame times, so even if peak FPS is lower, 1% lows can still be better and stutter can be reduced.

In our case, after an optimization pass done entirely by Claude through repeated tweaks and benchmark reruns, Vulkan is now about 20% slower in the simple benchmark tutorial, around 700 FPS versus 900 FPS OpenGL. Before that pass, it was about 70% slower. The Vulkan shaders are also still compiled without optimization, which may explain part of the remaining gap. That said, this benchmark is basically just a tight render loop with everything already loaded into VRAM at startup, so it is probably not a very good test of Vulkan’s strengths. A more realistic stressed benchmark with heavier asset streaming and GPU uploads would be more meaningful.