r/vulkan

더해봐야 하겠지만 vulkan이 ios도 적용할 수 있네요. 다음은 안드로이드로 해볼려고요
I need to test it more, but it turns out Vulkan can be applied to iOS as well. Next, I’m planning to try it on Android

https://youtu.be/WXFv1oauXYk?si=vnPBsFyqrt8WYyNu

I think I'm having fun. Nothing can describe the feeling of satisfaction after squashing that last bug. Suddenly the entire scene fully renders! (I know it's not yet PBR and ray tracing but those don't feel too far away now)

I'd been stuck for about a week hunting a bug where Bistro would look like a hellscape of windows to nowhere, I had to quadruple-check every single part of the geometry codebase, implement non-ktx2 texture loading so I could test simpler gltf files... only to have Sponza render only half of itself too. I woke up at 5am this morning with the solution fresh in my sleepy head: it turned out to be a faulty ordering or mesh primitives in my custom gltf loader, leading to duplicate vertex and index buffers on the wrong nodes. 5 seconds later I had a full scene.

So today, filled with joy, I optimized stuff left and right, and within a couple hours the framerate on Bistro jumped from 8 to 80, not bad for a first pass, and without culling yet!

If I can give other beginners some fresh advice: keep using the raw vulkan API for as long as possible instead of abstracting it away from the start. It might sound crazy at first, but I truly think it helped me design and architecture my app around the features I actually know and control rather than around an API I still hadn't properly learned and used. And don't forget to sleep!

hi, i am doing my academic RHI and making posts about design moments that as i think might be helpfull for people who learning graphics. So they might find answers on their question and I might improve my knowledge by repeating.

Exactly this post about CommandBufferAllocator design, soon would be posts about Ring Allocators, DescriptorStates, multi api architecture design and why we need all of this.

All my posts is what i personally learned with blood and sweat, hope you find it usefull. Dont forget to comment and share your thoughts

Thats post in my blog and linked in.

Post in blog
Linked in post
Mad-RHI repo (contains release manager, descriptor state, allocators etc)

So, long story short, but I'm finally at the point where I'm ready to draw a triangle. And I can, at least when I use my NVIDIA GPU (I have an Optimus laptop). But when I use the Intel GPU instead, the triangle doesn't draw.

In both cases, the background clears to the selected colour correctly. It's just that the triangle doesn't appear when using the Intel GPU.

I've tried RenderDoc - although I don't really know much about it - and everything seems identical in what it records between runs of the program with different GPUs selected - except for one thing.

On NVIDIA, the Mesh Viewer looks like this: https://i.ibb.co/jvpttBfM/image.png (hopefully you can see the wireframe triangle).

But on Intel, it looks like this: https://i.ibb.co/qM0pKvvj/image.png

I've got no idea what it means that the triangle is filled red, or what the blue square on the top vertex means.

I don't expect anyone to diagnose the exact problem - although that would be great if you happen to know - but can anyone help me with how I can investigate further? I don't really know what to try next, or what else I can do in RenderDoc to figure it out.

My shaders are simple, by the way - hardcoded vertices in the vertex shader, and returning a constant colour from the fragment shader. I haven't got as far as vertex buffers or attributes yet.

A year ago, I began working through the Vulkan tutorial with the intention of building a graphics engine for my solo MMO project. I knew that building a graphics engine could be a slippery slope and that I might never start working on the actual game, so I set myself a deadline: one year. This post describes the tech I have built over this year.

The renderer was implemented in C++ using Vulkan 1.3. I used Vulkan-HPP bindings (to make the code idiomatic C++) and Vulkan VMA (to simplify GPU memory management). For input and output, I used SDL3. Procedural mesh and scene generation were implemented in Go.

My build system of choice is Bazel. I repackaged all the Vulkan libraries and SDL3 itself for Bazel, which allowed me to build single-binary, statically linked executables with all unused functions tree-shaken out. I do my development on Linux and occasionally test on Windows. In theory, macOS is also possible, but I have left it out for now. I have a working Bazel build of SDL for macOS, so bolting on MoltenVK should not be a problem in the future. Perhaps macOS will support Vulkan natively before I even get to that.

To generate meshes, I built a DSL that allowed me, as a programmer, to model 3D objects through code. It is similar to OpenSCAD but operates in more artistic terms than in points and vectors. I can express a 3D model as a sequence of commands: create a cube, select the right face, extrude it, rotate, subdivide, attach sub-objects, etc. The parser creates an AST in the form of a Protobuf message that I can serialize and tweak procedurally before passing it to the modeler. The modeler outputs a number of meshes per shader and a recipe on how to assemble the final object from smaller sub-objects and transformations. Some transformations are static, while others are tied to named parameters and enable object animation. All metadata is stored in two formats: one for the server (to understand the semantics of each transformation, for example) and one for the renderer (to upload to the GPU).

The generated meshes then go through the baker. I used the open-source GPU baker "Fornos," but I had to strip out all Windows-specific code, convert it to Vulkan, and make it headless to run on my server. With the help of the baker, I generate base color, normal maps, metalness, roughness, and ambient occlusion textures.

Once models are generated, they are serialized and stored on disk as Protobuf messages.

The scene generator creates the environment as multiple voxel grids. At the highest level, it generates large voxels, each corresponding to a whole room, a tunnel, huge pillars under the building, etc. In principle, I could use wave-function collapse at this level, but it was left out of the prototype. Level generation will be handled separately during actual game development.

Once the coarse grid is ready, a second generation pass kicks in. It creates a fine-grained voxel grid describing where the scene will have concrete, air, windows, etc. The core algorithm is straightforward: if a voxel has contact with both the interior and exterior simultaneously, it becomes a structure. The floor/ceiling boundary checks the "room index" stored in the coarse grid alongside the voxel type. If the voxel below belongs to room X and the voxel above to room Y, the current voxel is turned into a structure as well.

The third pass “cuts out” windows. It looks at large vertical slabs of concrete, decides how many windows to make, and replaces structural voxels with window voxels where necessary.

Next, the generator iterates over all voxels to recognize small patterns (e.g., if there is concrete on the left and a window on the right, it adds a window frame object at that position oriented accordingly). In some places, it creates corner meshes for window frames. In others, it adds exterior decorations to the building. The pattern-matching engine is very generic; a predicate describes what to check around the current position, and an action performs the task, such as adding an object.

The final stage identifies all continuous planes of concrete and, depending on their orientation and the surrounding voxels, creates scene-level geometry such as walls and floors. The exported scene contains meshes ready to be uploaded to the GPU with minimal preprocessing.

The scene is serialized and stored on disk as a Protobuf message again. A lot of things are stored as protobufs. It’s a pretty compact binary format that is easily accessible from C++ and Go.

Finally, we come to the Vulkan renderer. I use Vulkan 1.3 with dynamic rendering and bindless textures.

I experimented with deferred rendering, but the lack of MSAA was a significant downside. I tried implementing anti-aliasing with TAA but couldn't achieve decent results; it was either too blurry or ghosty. Ultimately, I settled on Forward+ rendering and 8x MSAA. The screen is split into small 3D boxes in (x, y, depth) space. For each box, a light clustering shader computes which lights and reflection probes affect it, storing this information in a buffer.

A depth pre-pass fills the depth buffer to reduce the number of fragment shader calls later. The main rendering pass samples the light clustering buffer and applies the lights and reflection probes from the generated lists. Window glass is rendered using weight-based order-independent transparency. It’s very cheap and produces decent results. The shader for large flat surfaces, such as walls and roofs, uses the Hextile algorithm to eliminate repetitive tiling patterns.

Global illumination uses a hierarchy of 3D voxel buffers of increasing size, similar to the technique used in Enlisted. Simplified scene geometry is rasterized to a 3D scene buffer, then a compute shader traces rays from each non-empty voxel to each light to compute voxel illuminance. Finally, another compute shader handles the most expensive part: tracing rays in all directions for each voxel in the scene to update six-sided irradiance. I have not yet implemented a 3D ring buffer to update GI incrementally as the camera moves; this will be done when converting this prototype into a real game client. It should be straightforward.

When sampling reflection probes and GI voxels, I had to fight light leaks through thin walls. If an irradiance voxel ends up right on the wall, it will sense light from both sides, so sampling it will produce incorrect results - light from the left will be visible on the right and vice versa. I found a pretty simple solution. At the scene generation time, I insert “sampler repellents” into each large wall. Each repellent is a thin rectangle that repeats the shape of the wall. Before sampling the voxel grid, I look up those repellents in the vicinity of the point and if it’s too close, then I shift the sampling along the normal. To make it efficient, I use a similar approach to clustered lighting: for each (x, y, depth) box I precompute a list of sampling repellents that can affect that box. However I think in the production version of the engine, I’ll probably scrap this clustered thing and implement a simple global BVH lookup.

For the UI, I used RmlUi and implemented a custom rendering interface interfacing with my engine. My original implementation suffered from multi-millisecond latencies for complex UIs because every rectangle and line of text was rendered with a separate draw call. I couldn't batch them together because those calls were a) order-dependent and b) each used a different texture. Eventually, I discovered bindless textures in Vulkan and fell in love with them. Instead of separate draw calls, I now bind all textures as a large array, add texture index as an instance attribute, and add draw commands to the single draw command buffer. Now, the entire UI is rendered with a single draw call without any texture rebinding between draws, and it takes 0.1ms latency, regardless of the UI complexity.

The final step does tonemapping, color grading, and compositing. I used a piecewise filmic curve and exposed all settings in a custom debug panel. The LUT table is precomputed on the CPU side and sampled in the single compositing shader.

I attached a bunch of screenshots from the last version of the engine to the post.

Just recently stumbled upon this gem from u/SaschaWillems:
https://www.howtovulkan.com/

This is really a game changer for me. I always struggled with multiple textures, until i get to know descriptor set indexing. Recently switched from RenderPasses/FrameBuffers to dynamic rendering, and I will never look back. Now a naive render graph implementation is a no-brainer. With that, I can dare to think of implementing a more complicated effects, instead of fighting an uphill battle with my own code. Thanks for this!

After more than a month of rewriting my entire renderer I finally have something to show again, not much just some basic texture loading but yeah, the engine's comming along nicely now

Highlights:

• Major KosmicKrisp upgrades on macOS (Tessellation shaders + 7 new extensions supported)

• 16 new extensions across all platforms

• GFXReconstruct now ARM64X on Windows on ARM

• Alpha release of GPU Dump tool

• Improved validation coverage

A useful maintenance release that rewards staying current. Full blog + download 👉 https://www.lunarg.com/lunarg-releases-vulkan-sdk-1-4-350-0/

Currently playing with stencil test in my samples projects for my RHI.

I have a deferred renderer who enable the stencil test for the depth prepass, the g-buffer pass, the skybox pass and the lighting pass.

For the OIT pass the stencil test is disabled with VkPipelineDepthStencilStateCreateInfo.stencilTestEnable=false (VK_DYNAMIC_STATE_STENCIL_TEST_ENABLE is not enabled in the dynamic states) but the depth/stencil buffer is the same as the other passes (third image, layout VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL)

On Nvidia GPU, the stencil test is correctly disabled in the OIT pass both on Windows & Linux.

On AMD GPU the stencil test is correctly disabled on Linux (second image, OIT revealage buffe) but not on Windows (first image).

RenderDoc shows no stencil state on the OIT pass (fourth image), which is correct since the stencil test is disabled, but we can see in the ouputs buffers that the stencil is applied.

Did I miss something in the pipeline config parameters ?

This is the pipeline creation code : https://github.com/HenriMichelon/vireo_rhi/blob/main/src/vulkan/VKPipelines.cpp#L255

UPDATE : I tried on a computer with an integrated AMD GPU (my AMD development computer have a RX5700) and it works correctly (both computers have the same drivers versions).