16:19 fdobridge: <g​fxstrand> Yup
16:25 karolherbst: I have to find my patchwork script for nouveau again :(
16:46 fdobridge: <g​fxstrand> Good Monday! As a bit of a PSA, I rebased NVK this morning. Pulled in some new NIR texture helpers for Meta as well as fixed a merge conflict with the newly landed YCbCr code.
17:16 fdobridge: <g​fxstrand> Pull the latest. I just added a simple test which will build all the MMEs on both Volta and Turing when you run `ninja test`
17:17 fdobridge: <g​fxstrand> As long as you're doing a debug build, that should be enough to ensure that you don't run out of registers anywhere.
17:17 fdobridge: <g​fxstrand> One day, we may actually unit test MMEs. Would be cool.
17:47 fdobridge: <g​ouz> @gfxstrand thanks I will try it out.
17:53 fdobridge: <g​ouz> I began writing the test, but you did it faster
17:54 fdobridge: <g​fxstrand> Sorry. I didn't realize if we left that as "you should do this" or "I should do this". 😅
17:54 fdobridge: <g​ouz> Maybe it's a good idea to change mme argument nvk_device to nv_device_info?
17:54 fdobridge: <g​ouz> As we only fill part of nvk_device for the tests?
17:56 fdobridge: <g​fxstrand> Maybe?
17:56 fdobridge: <g​ouz> Maybe it's a good idea to change mme build functions' argument nvk_device to nv_device_info? (edited)
17:56 fdobridge: <g​fxstrand> I thought about that.
17:56 fdobridge: <g​fxstrand> It's not a bad idea. It just makes a few things a bit more annoying.
17:56 fdobridge: <g​fxstrand> Not by much, though.
17:56 fdobridge: <g​fxstrand> Not by much at all....
17:56 fdobridge: <g​fxstrand> There's like one other helper that'd have to change.
17:56 fdobridge: <g​ouz> Shall I change this?
17:57 fdobridge: <g​fxstrand> Sure. Go for it.
17:57 fdobridge: <g​fxstrand> There was a part of me that was imagining a future in which MMEs get compiled based on information that's not in `nv_device_info` but the more I think about it the more I don't want to live in that future. Making that future painful is probably a good idea. 😅
19:55 fdobridge: <p​homes> I am not sure why, but since the new test was added deqp-vk now fails for me
19:55 fdobridge: <p​homes> FATAL ERROR: vk.createInstance(pCreateInfo, pAllocator, &object): VK_ERROR_INCOMPATIBLE_DRIVER at vkRefUtilImpl.inl:212
21:27 fdobridge: <g​fxstrand> Uh, what?!? Let me take a look.
21:32 fdobridge: <g​fxstrand> Looks like my plan to split most of NVK out into a shared lib and link it into a .so later is having linking problems. 🤦
21:35 fdobridge: <g​fxstrand> It's because someone made util depend on gallium 😠
21:44 fdobridge: <k​arolherbst🐧🦀> uhhh
21:44 fdobridge: <k​arolherbst🐧🦀> tell them to not do that?
22:12 fdobridge: <g​fxstrand> Yeah...
22:12 fdobridge: <g​fxstrand> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20734
22:13 fdobridge: <g​fxstrand> Fixed. I force-pushed so we keep the build working through the tree. Sorry about that. The real bug was that I needed to use `link_whole` to prevent the linker from dropping symbols. However, setting `link_whole` caused it to blow up trying to depend on gallium. 😩
22:14 fdobridge: <D​adSchoorse> why are mesa/main and gallium still separate?
22:14 fdobridge: <g​fxstrand> It's only working for other drivers thanks to dead code removing the dependency if you get lucky and link things in the right order.
22:14 fdobridge: <g​fxstrand> No one has done the work to combine them.
22:16 fdobridge: <D​adSchoorse> ah, so purely historical reasons
22:21 fdobridge: <g​fxstrand> Before we forked the classic drivers off into the amber branch, there were GL drivers that didn't use gallium. For those, this would have been a problem. All those drivers are gone now so a gallium dependency on mesa/main doesn't hurt anyone.
22:21 fdobridge: <g​fxstrand> Marek has talked about pulling mesa/main into gallium and merging it all but no one's actually done that yet.
22:21 fdobridge: <g​fxstrand> It'd be a lot of work.
22:22 fdobridge: <g​fxstrand> I'm sure there's a lot of dead code in mesa/main at this point.
23:12 fdobridge: <g​fxstrand> I'm starting to understand why codegen is the way it is and I'm not happy about it. 😕
23:24 airlied: I cleaned up a lot of mesa/main and merged a bunch of the state tracker into it in the past
23:24 airlied: but started to get a bit diminishing returns
23:24 airlied: like in theory we have no need for the mesa/state_tracker anymore
23:35 fdobridge: <k​arolherbst🐧🦀> heh
23:35 fdobridge: <k​arolherbst🐧🦀> what part specifically?
23:37 fdobridge: <k​arolherbst🐧🦀> I think once we can start killing the indirect func calls it starts to get interesting
23:37 fdobridge: <k​arolherbst🐧🦀> maybe it would even makes sense to just focus on that