Vulkan 1.4.363 adds an Intel GPU version query

The Khronos Group released version 1.4.363 of the Vulkan specification on September 18, 2026. It adds a new Intel extension called VK_INTEL_device_info, which lets a program ask an Intel graphics chip exactly which hardware generation it is. Until now developers had to work that out themselves from a hand-written table, and a wrong guess meant shipping the wrong code path to real users.

Vulkan is the open graphics and compute interface that games, game engines and some machine-learning tools use to talk to a graphics card. The Khronos Group is the industry body that writes it. Small specification updates land often, and the last part of the version number counts them.

What the new extension reports

The extension is number 709 in the Vulkan registry, and it ships at revision 1. It adds one new structure, VkPhysicalDeviceInfoPropertiesINTEL, holding three unsigned 32-bit integers.

Field	What it reports
deviceIpVersionArch	The graphics architecture generation
deviceIpVersionRelease	The release within that generation
deviceIpVersionRevision	The hardware revision of that release

"IP" here is short for intellectual property. Chip designers reuse blocks of a design across many products, and the IP version identifies which block a given chip contains.

The structure attaches to VkPhysicalDeviceProperties2 through its pNext member. That is the standard way Vulkan bolts extra fields onto an existing query. A program that already asks a device for its properties gets these three numbers in the same call.

The extension's specification page credits two Intel engineers as its authors, Jakub Szymczyk and Sławomir Grajewski. It is dated September 8, 2026, ten days before the specification release that carried it.

Why Intel asked for it

Vulkan already reports a numeric deviceID for every graphics device. That number identifies the product, not the design inside it.

According to Phoronix, the existing field "doesn't expose the graphics IP version and so applications/games would need to maintain a manual look-up table correlating device IDs to graphics IP versions/generations."

A lookup table like that has an obvious failure mode. Every time Intel ships a new product, the table is out of date. Software written before that product existed cannot recognize it, so it falls back to a safe but slower path, or picks the wrong one. Asking the driver directly removes that whole class of bug.

This matters because engines routinely change behavior by hardware generation. A shader that runs well on one generation may need a different approach on the next.

The rest of the 1.4.363 update

The release is a routine specification update alongside the new extension. Phoronix reports that it carries clarifications to various parts of the specification and several fixes.

One change covers DMA-BUF external memory, which is the Linux mechanism for sharing a block of memory between drivers without copying it. The update adds multi-instance validation rules for it, affecting the VkMemoryAllocateInfo and VkMemoryGetFdInfoKHR structures. Validation rules are the conditions a program must satisfy; the validation layers developers run during testing check them.

The specification tag itself was published on the Khronos Vulkan-Docs repository on September 18, with Phoronix covering the release two days later.

What this means for developers

Do not call the new query yet without a guard. VK_INTEL_device_info is a vendor extension, so it exists only on Intel drivers, and only on drivers new enough to have picked up the September specification. Check that the device advertises it before you read the structure, and keep the lookup table you already have as the fallback.

Plan on that fallback living a long time. A specification release is the start of the rollout, not the end of it. The extension has to reach Mesa's Intel driver on Linux and Intel's own Windows driver, and then reach users through distribution updates and driver downloads. Users on older drivers will keep reporting nothing.

Revision 1 is also worth noting. Early revisions of vendor extensions can change before they settle, so read the revision number rather than assuming the fields stay put.

The cost of adopting it is low. The structure chains onto a properties query most engines already make at startup, so it adds no new round trip and no per-frame work. If your code currently branches on Intel hardware generations, this is a small change that deletes a table you have been maintaining by hand.

Watch Mesa's commit history for the first driver-side implementation. That, rather than the specification release, is the point at which the query starts answering on real machines. Intel shipped its Linux NPU driver 1.38 with Ubuntu 26.04 support earlier this month, and driver features tend to reach distributions on that same cadence.