← [Back to Twitter thread index](../README.md)

---
title: "Next pre-device opening activity is choosing queue(s). Going to make another eff"
author: "NOTimothyLottes"
handle: "@NOTimothyLottes"
post_url: "https://x.com/NOTimothyLottes/status/2074725506050642021"
post_id: "2074725506050642021"
timestamp: "2026-07-08 05:21:21"
post_count: 5
reply_count: 0
repost_count: 0
like_count: 5
view_count: 536
---

# @NOTimothyLottes — Next pre-device opening activity is choosing queue(s). Going to make another eff

## Post 1 (2026-07-08 05:00:47)

Oh, my RADV driver says vkGetShaderInfoAMD is available [GPU disassembly dumps]. Going to be exciting to see how RADV compiler does. Will definitely be filing optimization bugs, would like to help the RADV team make this the best AMD Vulkan driver that can exist.

## Post 2 (2026-07-08 05:05:59) — reply to Post 1

One other concern was if RADV would support DEVICE_UNCACHED_BIT_AMD - and looks like RADV already has that, which means low-latency CPU/GPU communication should just work out of the box

![Media 1](./media/2074721638378086822_1.jpg)

## Post 3 (2026-07-08 05:13:07) — reply to Post 2

One of the pain points of doing header-free Vulkan is the VkPhysicalDeviceLimits structure. I avoid it completely and replace the structure with an equal size array of 63 64-bit values (504 bytes total). Then use direct byte offset for timestampPeriod (only thing useful in there)

![Media 1](./media/2074723430734111222_1.png)

## Post 4 (2026-07-08 05:16:02) — reply to Post 3

The other component of vkGetPhysicalDeviceProperties that is useful is the vendorID, which is important for vendor specific engine permutations -> I use to enable vkGetShaderInfoAMD disassembly dumps automatically on all shaders

## Post 5 (2026-07-08 05:21:21) — reply to Post 4

Next pre-device opening activity is choosing queue(s). Going to make another effort at beam racing, this time on Linux, so probably want a separate queue for presentation only. To fully decouple {dispatch, and swap}. Will see why later ...