05:45 fdobridge: <S​id> apologies for being stupid but where do we have our VkPhysicalDeviceFeatures2 struct in nvk?
05:48 fdobridge: <S​id> I'm guessing it's nvk_get_device_features in nvk_physical_device.c?
05:51 fdobridge: <S​id> oh wait we use a common vulkan_core
05:52 fdobridge: <S​id> I think
05:55 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> NVK has migrated to a lot of common stuff
05:56 fdobridge: <S​id> evidently, yeah... looks like a lot of the work for extension implementation has been done for me
05:57 fdobridge: <S​id> 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:03 fdobridge: <m​arysaka> Yes exactly
07:21 fdobridge: <g​fxstrand> Yeah, you just modify `nvk_get_device_extensions()` and `nvk_get_device_features()`
07:33 fdobridge: <S​id> got you
07:33 fdobridge: <S​id> how do I identify what I have to put into get_device_features for an extension?
07:51 fdobridge: <S​id> I mean, I know I can just refer to other drivers' code, but still curious as to how to do that without peeking
07:52 fdobridge: <k​arolherbst🐧🦀> that's specified in the extension itself. They generally describe the device properties they add.
07:53 fdobridge: <k​arolherbst🐧🦀> and for the device_extension it's just the extension name
07:53 fdobridge: <S​id> the spec doesn't mention it though
07:56 fdobridge: <k​arolherbst🐧🦀> not every extension adds new device features
07:57 fdobridge: <k​arolherbst🐧🦀> though this one does: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkPhysicalDeviceColorWriteEnableFeaturesEXT.html
07:57 fdobridge: <k​arolherbst🐧🦀> so it should be `colorWriteEnable`
07:57 fdobridge: <k​arolherbst🐧🦀> in the ext spec you have this part:
07:57 fdobridge: <k​arolherbst🐧🦀> "Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:
07:57 fdobridge: <k​arolherbst🐧🦀> VkPhysicalDeviceColorWriteEnableFeaturesEXT"
08:35 fdobridge: <g​fxstrand> Yeah, whatever is in `VkPhysicalDeviceWhateverExtensionFeaturesEXT` ends up in `vk_features`
09:46 fdobridge: <S​id> understood
09:46 fdobridge: <S​id> also, when the vulkan CTS if it tells me
09:46 fdobridge: <S​id>
09:46 fdobridge: <S​id> \`Fail (Incorrect value found in attachments; please check logged images)\`
09:47 fdobridge: <S​id> where can I find the said log
09:47 fdobridge: <S​id> full thing is
09:47 fdobridge: <S​id>
09:47 fdobridge: <S​id> \`\`\`
09:47 fdobridge: <S​id>
09:47 fdobridge: <S​id> Test case 'dEQP-VK.pipeline.monolithic.color\_write\_enable.all\_channels.cmd\_buffer\_start.enable\_first'..
09:47 fdobridge: <S​id>
09:47 fdobridge: <S​id> Fail (Incorrect value found in attachments; please check logged images)
09:47 fdobridge: <S​id>
09:47 fdobridge: <S​id> \`\`\`
09:59 fdobridge: <p​homes> can I get a NVK label for https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25550 ?
10:03 fdobridge: <S​id> :o
10:11 cwabbott: the log is in TestResults.qpa in the folder where deqp-vk is
10:15 fdobridge: <S​id> thank you
10:19 fdobridge: <S​id> where are we managing our dynamic state in the driver?
12:02 fdobridge: <g​fxstrand> Done
12:02 fdobridge: <g​fxstrand> color write enables are handled in nvk_graphics_pipeline.c
12:02 fdobridge: <g​fxstrand> Well, they would be
12:03 fdobridge: <g​fxstrand> That's where the rest of the blend-like stuff is, at least for now.
12:04 fdobridge: <g​fxstrand> That was for @tiredchiku
12:10 fdobridge: <S​id> okie, got you
12:11 fdobridge: <S​id> or at least I think I did 🙃
12:22 fdobridge: <m​ohamexiety> @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:22 fdobridge: <m​ohamexiety> 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:34 fdobridge: <S​id> no such folder, no such script
12:35 fdobridge: <m​ohamexiety> https://github.com/KhronosGroup/VK-GL-CTS/blob/main/scripts/qpa_image_viewer.html this thing, sorry
12:35 fdobridge: <S​id> oh, thank
12:48 fdobridge: <g​fxstrand> Check out https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25813. I think you'll need to be fiddling with the same bits.
12:49 fdobridge: <S​id> I'm looking through https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24872 as well
12:50 fdobridge: <S​id> 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:51 fdobridge: <g​eorgeouzou> This is mostly all dynamic state
12:51 fdobridge: <g​eorgeouzou> Except dynamic rasterization samples for which i was not so sure
12:52 fdobridge: <S​id> 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:52 fdobridge: <S​id> I *could* be horribly wrong, and I hope I am .-.
12:55 fdobridge: <g​eorgeouzou> I think VK_EXT_color_write_enable does not require these other features
12:57 fdobridge: <S​id> 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:58 fdobridge: <S​id> 74% out of `dEQP-VK.pipeline.monolithic*.color_write_enable.*`
12:59 fdobridge: <S​id> across the rgba channel, *.enable_all are all passing, while everything else fails
13:01 fdobridge: <S​id> so for example, that's the trend across it all
13:01 fdobridge: <S​id> https://paste.sloughland.dev/raw/eel-ant-mouse
13:01 fdobridge: <g​eorgeouzou> Have you implemented the extension?
13:02 fdobridge: <S​id> that is exactly what I am trying to figure out how to do 🙃
13:02 fdobridge: <S​id> 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:04 fdobridge: <S​id> 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:04 fdobridge: <g​eorgeouzou> Oh ok! Take a look at other dynamic state in nvk_cmd_draw.c
13:05 fdobridge: <S​id> I'm struggling to connect the dots between what the spec's telling me to do and how nvk itself is laid out 😅
13:05 fdobridge: <S​id> also, will do, thank
13:13 fdobridge: <g​fxstrand> So, dynamic state for this one is going to be a tad bit tricky. Definitely possible but tricky
13:14 fdobridge: <S​id> yeah I feel like it'd be simpler for me to pick a vulkan 1.0 extension to implement for now 😅
13:14 fdobridge: <g​fxstrand> Yeah, start there.
13:17 fdobridge: <S​id> 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:17 fdobridge: <S​id> so apologies for being annoying in advance
13:33 fdobridge: <S​id> quick question: is it among our goals to have every extension that the proprietary driver also has?
14:07 fdobridge: <g​fxstrand> You're fine. No need to apologize. Just go ahead and ask questions. 😄
14:08 fdobridge: <g​fxstrand> 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:09 fdobridge: <k​arolherbst🐧🦀> @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:10 fdobridge: <k​arolherbst🐧🦀> ehh wait.. there are vec2 🙃
14:11 fdobridge: <k​arolherbst🐧🦀> and the mod exists on all sources
14:11 fdobridge: <k​arolherbst🐧🦀> I just checked with HADD2 first
14:12 fdobridge: <g​fxstrand> Woo
14:12 fdobridge: <k​arolherbst🐧🦀> so yeah, it's all vec2 and you can swizzle freely
14:12 fdobridge: <g​fxstrand> Yay!
14:12 fdobridge: <g​fxstrand> And we can use PRMT to vec stuff up at-will.
14:12 fdobridge: <k​arolherbst🐧🦀> yeah
14:13 fdobridge: <k​arolherbst🐧🦀> however
14:13 fdobridge: <k​arolherbst🐧🦀> F2F also has source modifiers for hi/lo
14:14 fdobridge: <k​arolherbst🐧🦀> though I don't see you can write to hi/lo.. annoying
14:14 fdobridge: <k​arolherbst🐧🦀> ohhh
14:15 fdobridge: <k​arolherbst🐧🦀> @gfxstrand you want F2FP
14:15 fdobridge: <k​arolherbst🐧🦀> it can pack it into the higher/lower part of the reg
14:16 fdobridge: <k​arolherbst🐧🦀> it takes two fp32 floats and packs them into hi/lo
14:17 fdobridge: <k​arolherbst🐧🦀> it can do a bit more than that, but that's the basic instruction to help with packing if the source is fp32
14:20 fdobridge: <g​fxstrand> Yeah, that's useful
14:21 fdobridge: <k​arolherbst🐧🦀> apparently it can also nd has a third source.. but better to figure out the details. Those instructions have tons of flags
21:37 benjaminl: any idea why nvdisasm doesn't like IADD3 ops when I pass it raw binary?
21:37 benjaminl: I'm able to get ptxas to emit IADD3, and then using nvdisasm on the resulting elf object is fine
22:17 fdobridge: <d​adschoorse> nice, another driver that needs better nir vectorization
22:18 fdobridge: <r​hed0x> VK_NVX_binary_import >:)
22:28 fdobridge: <s​aancreed> VK_NV_cuda_kernel_launch
22:28 fdobridge: <s​aancreed> (might be extra tricky because no public docs exist for that one)
23:13 fdobridge: <b​utterflies> Is that a challenge
23:14 fdobridge: <b​utterflies> https://developer.nvidia.com/nsight-graphics-2021_4
23:14 fdobridge: <b​utterflies> > 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:15 fdobridge: <s​aancreed> > soon
23:15 fdobridge: <s​aancreed> <https://github.com/KhronosGroup/Vulkan-Docs/issues/2133> 🐢