16:19fdobridge: <gfxstrand> Yup
16:25karolherbst: I have to find my patchwork script for nouveau again :(
16:46fdobridge: <gfxstrand> 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:16fdobridge: <gfxstrand> 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:17fdobridge: <gfxstrand> 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:17fdobridge: <gfxstrand> One day, we may actually unit test MMEs. Would be cool.
17:47fdobridge: <gouz> @gfxstrand thanks I will try it out.
17:53fdobridge: <gouz> I began writing the test, but you did it faster
17:54fdobridge: <gfxstrand> Sorry. I didn't realize if we left that as "you should do this" or "I should do this". 😅
17:54fdobridge: <gouz> Maybe it's a good idea to change mme argument nvk_device to nv_device_info?
17:54fdobridge: <gouz> As we only fill part of nvk_device for the tests?
17:56fdobridge: <gfxstrand> Maybe?
17:56fdobridge: <gouz> Maybe it's a good idea to change mme build functions' argument nvk_device to nv_device_info? (edited)
17:56fdobridge: <gfxstrand> I thought about that.
17:56fdobridge: <gfxstrand> It's not a bad idea. It just makes a few things a bit more annoying.
17:56fdobridge: <gfxstrand> Not by much, though.
17:56fdobridge: <gfxstrand> Not by much at all....
17:56fdobridge: <gfxstrand> There's like one other helper that'd have to change.
17:56fdobridge: <gouz> Shall I change this?
17:57fdobridge: <gfxstrand> Sure. Go for it.
17:57fdobridge: <gfxstrand> 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:55fdobridge: <phomes> I am not sure why, but since the new test was added deqp-vk now fails for me
19:55fdobridge: <phomes> FATAL ERROR: vk.createInstance(pCreateInfo, pAllocator, &object): VK_ERROR_INCOMPATIBLE_DRIVER at vkRefUtilImpl.inl:212
21:27fdobridge: <gfxstrand> Uh, what?!? Let me take a look.
21:32fdobridge: <gfxstrand> 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:35fdobridge: <gfxstrand> It's because someone made util depend on gallium 😠
21:44fdobridge: <karolherbst🐧🦀> uhhh
21:44fdobridge: <karolherbst🐧🦀> tell them to not do that?
22:12fdobridge: <gfxstrand> Yeah...
22:12fdobridge: <gfxstrand> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20734
22:13fdobridge: <gfxstrand> 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:14fdobridge: <DadSchoorse> why are mesa/main and gallium still separate?
22:14fdobridge: <gfxstrand> 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:14fdobridge: <gfxstrand> No one has done the work to combine them.
22:16fdobridge: <DadSchoorse> ah, so purely historical reasons
22:21fdobridge: <gfxstrand> 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:21fdobridge: <gfxstrand> Marek has talked about pulling mesa/main into gallium and merging it all but no one's actually done that yet.
22:21fdobridge: <gfxstrand> It'd be a lot of work.
22:22fdobridge: <gfxstrand> I'm sure there's a lot of dead code in mesa/main at this point.
23:12fdobridge: <gfxstrand> I'm starting to understand why codegen is the way it is and I'm not happy about it. 😕
23:24airlied: I cleaned up a lot of mesa/main and merged a bunch of the state tracker into it in the past
23:24airlied: but started to get a bit diminishing returns
23:24airlied: like in theory we have no need for the mesa/state_tracker anymore
23:35fdobridge: <karolherbst🐧🦀> heh
23:35fdobridge: <karolherbst🐧🦀> what part specifically?
23:37fdobridge: <karolherbst🐧🦀> I think once we can start killing the indirect func calls it starts to get interesting
23:37fdobridge: <karolherbst🐧🦀> maybe it would even makes sense to just focus on that