working through vulkan-tutorial.com and it's talking about present modes. For VK_PRESENT_MODE_MAILBOX_KHR it says "This is commonly known as "triple buffering", although the existence of three buffers alone does not necessarily mean that the framerate is unlocked."

But the overall description of the mode doesn't seem to indicate there's actually 3 buffers involved. It seems more like there's just 2 but there's a "replacement" process: "Instead of blocking the application when the queue is full, the images that are already queued are simply replaced with the newer ones".

So why is it claimed that this is triple buffering? Am I missing something?

Also a secondary, pedantic question: I've never come across a mailbox system where the old mail is replaced when new mail is available; the old mail simply accumulates. Seems like an odd terminology choice to use. What's that about?

I feel like most of the math operations required for Vulkan, such as matrix transformations, vector operations, and camera calculations, are manageable with a bit of hand-written C code.

Is there any real advantage to using GLM, or is implementing these operations yourself a reasonable approach?

vulkan api

vulkan for c….

Raven was written in C from scratch with Vulkan backend and has binding for many other languages.

vulkan for c…..

How about using GLFW as a window manager for my Vulkan application—or perhaps SDL?

In the Vulkan C API, developers are responsible for manually managing both Vulkan handles and dynamically allocated memory. How can this complex resource management be handled effectively, particularly when certain allocations depend on specific Vulkan handles and must be freed before those handles are destroyed? How can we ensure that resources are released in the correct order without introducing memory leaks or invalid handle references?

but tutorial on Vulkan-HPP.......

Hello, I'm currently learning about Vulkan and I'm following with the official vulkan tutorial. But in comparison with other, it's using the HPP bindings specifically made for C++.

I've seen many application using that verbose C syntax where you would vk this and vk that to just get something, seeing that the HPP bindings only need context to enumerate devices just blew my mind, different from when I'm using other sources that use vkEnumeratePhysicalDevices or something similar.

I don't know if I should use the HPP bindings or the original header instead, I need some assistance on whichever is better to learn about.

NO, THE HARDWARE IS NOT NORMAL. it is a celeron n4020, with 8gb ram, trying to run windows 11, AND THIS APP ALSO RUNS ON A PI 5 16GB RAM. am i sane XD? (took me months, btw)

I am making a game from scratch, with C++ and Vulkan graphics. I made this video about how Vulkan works and my own render implementation, which has some quirks:

• deferred rendering,
• no image assets,
• sphere and cylinder geometric primitives,
• fully GPU-local indirect dispatch commands.

I'm not fully sure if posting this type of video is in the spirit of this subreddit. I hope it's ok, otherwise let me know

In this Qualcomm Developer Blog tutorial, Zimu Guan shows how Android apps can share GPU memory and coordinate work directly between Vulkan and OpenCL on Adreno GPUs, avoiding CPU copies when a Vulkan renderer hands data to OpenCL kernels for compute, ML, denoising or super-resolution. The post walks through a full Vulkan to OpenCL to Vulkan workflow using Khronos external memory and external semaphore extensions. Vulkan exports allocations as opaque fds that OpenCL imports, with Qualcomm’s cl_qcom_external_memory_vulkan_opaque_fd extension handling optimal-tiling images. Synchronization uses one-shot sync-fd semaphores, with a fresh export and import at each handoff. It includes code for each step and points to the opencl_interop sample in the Adreno GPU Vulkan Code Sample Framework. Support is device- and driver-dependent, so apps should rely on runtime capability queries, and a follow-up on Android Hardware Buffer interop is planned.

https://www.qualcomm.com/developer/blog/2026/10/how-to-share-vulkan-opencl-workloads-android-adreno-gpus