# Vulkan 1.4.363 Exposes the Intel Graphics IP Version, and Games Can Retire Their Device ID Tables > Source: > Published: 2026-09-21 09:12:01+00:00 *A new vendor extension lets an application ask the driver which Intel graphics generation it is actually talking to, instead of guessing.* Khronos pushed out Vulkan 1.4.363 over the weekend, and sitting among the usual pile of spec clarifications is one new vendor extension that fixes something Intel has been quietly living with since it got back into the graphics business. VK_INTEL_device_info lets an application read the Intel graphics IP version straight from the driver: the architecture generation, the release within that generation, and the hardware revision of that release. That sounds like bookkeeping, and it is not. Until now the only handle a Vulkan application had was the PCI device ID in the physical device properties, and a device ID tells you which product you are looking at without telling you what is inside it. Intel is blunt about the reasoning: the deviceID field does not expose the graphics IP version, so applications and games end up maintaining a manual lookup table that maps device IDs to generations. ## Why a device ID is not enough Anyone who has kept one of those tables knows how it ages. It is correct on the day the game ships and wrong the next time Intel launches anything. Intel has been launching a lot: Alchemist in the Arc A-series, Xe-LPG inside Meteor Lake, Xe2 in both Lunar Lake integrated graphics and the Battlemage cards, Xe3 in Panther Lake. Same vendor, same API, very different silicon, and a fresh batch of device IDs every time. When the table misses, the engine drops to a generic path. That is usually harmless and occasionally not, because engines branch on generation to choose render paths, to switch off features a given architecture handles badly, and to apply workarounds that only ever applied to one family. A brand new GPU landing in the unknown-Intel bucket is one way a launch-day card ends up slower or glitchier than the part it replaced, for reasons that have nothing to do with the hardware. Asking the driver is the obvious fix, and it is faintly surprising it took this long. The version triplet also covers the two cases a device ID cannot describe: two products sharing an architecture while carrying different IDs, and one ID spanning more than one hardware revision. It describes what the silicon is rather than what it was sold as. The rest of 1.4.363 is routine maintenance. There are assorted clarifications and fixes scattered through the specification, plus new multi-instance validity rules for DMA-BUF external memory in VkMemoryAllocateInfo and VkMemoryGetFdInfoKHR. Nothing in there changes how anyone writes a renderer. The obvious caveat is the prefix. VK_INTEL_ means vendor extension, so this is for code that already knows it is running on Intel and wants better information about which Intel: it does nothing on AMD or NVIDIA hardware. Landing in the registry is also only half the job. Intel needs to expose the extension in its Linux and Windows drivers before an application can query anything, and engines then need a reason to bother, which in practice means waiting until the lookup tables break again. Sources: [Phoronix](https://www.phoronix.com/news/Vulkan-1.4.363) and the [Khronos Vulkan registry](https://registry.khronos.org/vulkan/specs/latest/html/vkspec.html).