05:45fdobridge: <Sid> apologies for being stupid but where do we have our VkPhysicalDeviceFeatures2 struct in nvk?
05:48fdobridge: <Sid> I'm guessing it's nvk_get_device_features in nvk_physical_device.c?
05:51fdobridge: <Sid> oh wait we use a common vulkan_core
05:52fdobridge: <Sid> I think
05:55fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> NVK has migrated to a lot of common stuff
05:56fdobridge: <Sid> evidently, yeah... looks like a lot of the work for extension implementation has been done for me
05:57fdobridge: <Sid> if I'm understanding this right, I just have to enable it, run the CTS, and fix anything that shouldn't be broken on the hardware
06:03fdobridge: <marysaka> Yes exactly
07:21fdobridge: <gfxstrand> Yeah, you just modify `nvk_get_device_extensions()` and `nvk_get_device_features()`
07:33fdobridge: <Sid> got you
07:33fdobridge: <Sid> how do I identify what I have to put into get_device_features for an extension?
07:51fdobridge: <Sid> I mean, I know I can just refer to other drivers' code, but still curious as to how to do that without peeking
07:52fdobridge: <karolherbst🐧🦀> that's specified in the extension itself. They generally describe the device properties they add.
07:53fdobridge: <karolherbst🐧🦀> and for the device_extension it's just the extension name
07:53fdobridge: <Sid> the spec doesn't mention it though
07:56fdobridge: <karolherbst🐧🦀> not every extension adds new device features
07:57fdobridge: <karolherbst🐧🦀> though this one does: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkPhysicalDeviceColorWriteEnableFeaturesEXT.html
07:57fdobridge: <karolherbst🐧🦀> so it should be `colorWriteEnable`
07:57fdobridge: <karolherbst🐧🦀> in the ext spec you have this part:
07:57fdobridge: <karolherbst🐧🦀> "Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:
07:57fdobridge: <karolherbst🐧🦀> VkPhysicalDeviceColorWriteEnableFeaturesEXT"
08:35fdobridge: <gfxstrand> Yeah, whatever is in `VkPhysicalDeviceWhateverExtensionFeaturesEXT` ends up in `vk_features`
09:46fdobridge: <Sid> understood
09:46fdobridge: <Sid> also, when the vulkan CTS if it tells me
09:46fdobridge: <Sid> \`Fail (Incorrect value found in attachments; please check logged images)\`
09:47fdobridge: <Sid> where can I find the said log
09:47fdobridge: <Sid> full thing is
09:47fdobridge: <Sid> \`\`\`
09:47fdobridge: <Sid> Test case 'dEQP-VK.pipeline.monolithic.color\_write\_enable.all\_channels.cmd\_buffer\_start.enable\_first'..
09:47fdobridge: <Sid> Fail (Incorrect value found in attachments; please check logged images)
09:47fdobridge: <Sid> \`\`\`
09:59fdobridge: <phomes> can I get a NVK label for https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25550 ?
10:03fdobridge: <Sid> :o
10:11cwabbott: the log is in TestResults.qpa in the folder where deqp-vk is
10:15fdobridge: <Sid> thank you
10:19fdobridge: <Sid> where are we managing our dynamic state in the driver?
12:02fdobridge: <gfxstrand> Done
12:02fdobridge: <gfxstrand> color write enables are handled in nvk_graphics_pipeline.c
12:02fdobridge: <gfxstrand> Well, they would be
12:03fdobridge: <gfxstrand> That's where the rest of the blend-like stuff is, at least for now.
12:04fdobridge: <gfxstrand> That was for @tiredchiku
12:10fdobridge: <Sid> okie, got you
12:11fdobridge: <Sid> or at least I think I did 🙃
12:22fdobridge: <mohamexiety> @tiredchiku yeh that's the log, and there should be a HTML script in the scripts folder of the CTS that will allow you to view the logged image. you'll just copy paste the `</image>` marked stuff into that script and run it
12:22fdobridge: <mohamexiety> now ymmv whether that particular CTS test's error logs are useful or not but in my experience most of the time viewing the image is useful for a particular error pattern
12:34fdobridge: <Sid> no such folder, no such script
12:35fdobridge: <mohamexiety> https://github.com/KhronosGroup/VK-GL-CTS/blob/main/scripts/qpa_image_viewer.html this thing, sorry
12:35fdobridge: <Sid> oh, thank
12:48fdobridge: <gfxstrand> Check out https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25813. I think you'll need to be fiddling with the same bits.
12:49fdobridge: <Sid> I'm looking through https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24872 as well
12:50fdobridge: <Sid> I'm *basically* looking at radv's implementation of the extension and trying to figure out what's what, but I'm not entirely sure we have everything required for it
12:51fdobridge: <georgeouzou> This is mostly all dynamic state
12:51fdobridge: <georgeouzou> Except dynamic rasterization samples for which i was not so sure
12:52fdobridge: <Sid> yes, and implementations of color_write_enable across the board (anv, radv, tu) all rely on it to some extent if I'm reading those commits right
12:52fdobridge: <Sid> I *could* be horribly wrong, and I hope I am .-.
12:55fdobridge: <georgeouzou> I think VK_EXT_color_write_enable does not require these other features
12:57fdobridge: <Sid> cts logs say otherwise, I ran it for `dEQP-VK.pipeline*.color_write_enable.*` and while most of them were not supported because of missing GPL and missing VK_EXT_shader_object, a lot of them failed (74%!) failed
12:58fdobridge: <Sid> 74% out of `dEQP-VK.pipeline.monolithic*.color_write_enable.*`
12:59fdobridge: <Sid> across the rgba channel, *.enable_all are all passing, while everything else fails
13:01fdobridge: <Sid> so for example, that's the trend across it all
13:01fdobridge: <Sid> https://paste.sloughland.dev/raw/eel-ant-mouse
13:01fdobridge: <georgeouzou> Have you implemented the extension?
13:02fdobridge: <Sid> that is exactly what I am trying to figure out how to do 🙃
13:02fdobridge: <Sid> so far I've only just enabled it. I realize this is a bit frustrating but I am more or less a newbie at this
13:04fdobridge: <Sid> I understand what the spec's telling me, that I have to extend a few structs, and add in a few enum constants, the concept's all clear
13:04fdobridge: <georgeouzou> Oh ok! Take a look at other dynamic state in nvk_cmd_draw.c
13:05fdobridge: <Sid> I'm struggling to connect the dots between what the spec's telling me to do and how nvk itself is laid out 😅
13:05fdobridge: <Sid> also, will do, thank
13:13fdobridge: <gfxstrand> So, dynamic state for this one is going to be a tad bit tricky. Definitely possible but tricky
13:14fdobridge: <Sid> yeah I feel like it'd be simpler for me to pick a vulkan 1.0 extension to implement for now 😅
13:14fdobridge: <gfxstrand> Yeah, start there.
13:17fdobridge: <Sid> sorry btw, I know I'm gonna be a bundle of questions for a while because my approach to learning things is diving in the deep end and figuring it out as I go along e-e
13:17fdobridge: <Sid> so apologies for being annoying in advance
13:33fdobridge: <Sid> quick question: is it among our goals to have every extension that the proprietary driver also has?
14:07fdobridge: <gfxstrand> You're fine. No need to apologize. Just go ahead and ask questions. 😄
14:08fdobridge: <gfxstrand> Not necessarily every extension but we should enable most of them if we can. There's some I consider pretty silly so we may skip a few but we're trying to be pretty full-featured.
14:09fdobridge: <karolherbst🐧🦀> @gfxstrand the half instructions have two modes: F16_V2 outputting two packed fp16 values and F32 doing the calculation in fp16 and then converting to fp32, and on the source you have H0_H0, H1_H1, H1_H0, selecting both low, both high or low+hi. They don't have a src1, that's part of the source selection modifier on src0
14:10fdobridge: <karolherbst🐧🦀> ehh wait.. there are vec2 🙃
14:11fdobridge: <karolherbst🐧🦀> and the mod exists on all sources
14:11fdobridge: <karolherbst🐧🦀> I just checked with HADD2 first
14:12fdobridge: <gfxstrand> Woo
14:12fdobridge: <karolherbst🐧🦀> so yeah, it's all vec2 and you can swizzle freely
14:12fdobridge: <gfxstrand> Yay!
14:12fdobridge: <gfxstrand> And we can use PRMT to vec stuff up at-will.
14:12fdobridge: <karolherbst🐧🦀> yeah
14:13fdobridge: <karolherbst🐧🦀> however
14:13fdobridge: <karolherbst🐧🦀> F2F also has source modifiers for hi/lo
14:14fdobridge: <karolherbst🐧🦀> though I don't see you can write to hi/lo.. annoying
14:14fdobridge: <karolherbst🐧🦀> ohhh
14:15fdobridge: <karolherbst🐧🦀> @gfxstrand you want F2FP
14:15fdobridge: <karolherbst🐧🦀> it can pack it into the higher/lower part of the reg
14:16fdobridge: <karolherbst🐧🦀> it takes two fp32 floats and packs them into hi/lo
14:17fdobridge: <karolherbst🐧🦀> it can do a bit more than that, but that's the basic instruction to help with packing if the source is fp32
14:20fdobridge: <gfxstrand> Yeah, that's useful
14:21fdobridge: <karolherbst🐧🦀> apparently it can also nd has a third source.. but better to figure out the details. Those instructions have tons of flags
21:37benjaminl: any idea why nvdisasm doesn't like IADD3 ops when I pass it raw binary?
21:37benjaminl: I'm able to get ptxas to emit IADD3, and then using nvdisasm on the resulting elf object is fine
22:17fdobridge: <dadschoorse> nice, another driver that needs better nir vectorization
22:18fdobridge: <rhed0x> VK_NVX_binary_import >:)
22:28fdobridge: <saancreed> VK_NV_cuda_kernel_launch
22:28fdobridge: <saancreed> (might be extra tricky because no public docs exist for that one)
23:13fdobridge: <butterflies> Is that a challenge
23:14fdobridge: <butterflies> https://developer.nvidia.com/nsight-graphics-2021_4
23:14fdobridge: <butterflies> > This includes applications that use the new VK_NV_cuda_kernel_launch API. Note that more information about the extension will be shared soon
23:15fdobridge: <saancreed> > soon
23:15fdobridge: <saancreed> <https://github.com/KhronosGroup/Vulkan-Docs/issues/2133> 🐢