01:01karolherbst: might be some firmware problem
01:05fodasso: I think I have them all installed...
01:05fodasso: They might be not loading properly with inbuilt modules, perhaps?
01:06karolherbst: ahh yes.. don't use builtin modules with drivers requiring firmware
01:06karolherbst: or make sure you include all the files you need
01:06karolherbst: anyway, dmesg should tell
01:07fodasso: ok, tyvm. Will try rebooting to try to fix that up and will get that dmesg output. see ya :)
03:29fodasso: It was indeed the firmware, which was not installed properly. Now I installed the files, checked which ones were loaded and built them all to the kernel
03:30fdobridge: <airlied> been trying to solve dEQP-VK.renderpass.suballocation.attachment_write_mask.attachment_count_2.start_index_1 but something in the fragment shader output routing is escaping me
03:30fodasso: This way I bloat up the kernel, but limit what files could be loaded as firmware from userspace...
03:30fodasso: Next thing I will try NVK properly. tyvm once again
06:34fdobridge: <airlied> @gfxstrand once I dump shaders with the dump layer, what do I do with the output files?
06:40fdobridge: <gfxstrand> Oh, I have a better tool for shaders
06:41fdobridge: <gfxstrand> https://gitlab.freedesktop.org/gfxstrand/nvdump
06:41fdobridge: <gfxstrand> IDK that it works with all the stages yet, though. My attempts at decoding their binary headers are still really sketch.
06:42fdobridge: <gfxstrand> That little bit of rust takes a spv file (binary) and runs it through their driver with `VK_EXT_shader_binary` and disassembles the binary.
06:42fdobridge: <gfxstrand> When it works it's amazing.
07:14fdobridge: <airlied> oh I might be able to leverage that,
07:40fdobridge: <airlied> ah found it without shaders. https://gitlab.freedesktop.org/nouveau/mesa/-/merge_requests/247
07:51fdobridge: <airlied> that only took 2 or 3 days to dig up, flu sucks 😛
08:04fdobridge: <airlied> @karolherbst @gfxstrand just noticed LOAD_ROOT_TABLE/SET_ROOT_TABLE_SELECTOR in some traces on turing, is it a new way to launch shaders or bind things?
08:27fdobridge: <airlied> also dEQP-VK.binding_model.shader_access.primary_cmd_buf.uniform_buffer.geometry.descriptor_array.offset_view_nonzero passes with NV50_PROG_OPTIMIZE=0 or 1
08:27fdobridge: <airlied> if anyone is feeling codegen
08:37fdobridge: <airlied> AlgebraicOpt:LOGOP
09:18fdobridge: <karolherbst🐧🦀> yeah, turing was a big rework on a couple of things
09:20fdobridge: <karolherbst🐧🦀> mhhhhh... mind sharing the diff between that enabled/disabled?
10:05fdobridge: <airlied> uggh coloriser
10:05fdobridge: <airlied> https://paste.centos.org/view/raw/d8524a4b
10:06fdobridge: <airlied> https://paste.centos.org/view/raw/71b4b2c9 non-color
10:22fdobridge: <karolherbst🐧🦀> @airlied nvk should add a `info->omitLineNum = debug_get_num_option("NV50_PROG_DEBUG_OMIT_LINENUM", 0);` thing 😄
10:23fdobridge: <karolherbst🐧🦀> makes diffing way better
10:25fdobridge: <karolherbst🐧🦀> mhhhh
10:27fdobridge: <karolherbst🐧🦀> I wonder if that `OP_LOP3_LUT` stuff messes up things
10:28fdobridge: <karolherbst🐧🦀> @airlied mind dumping the shader right after AlgebraicOpt and with omitLineNum set?
10:29fdobridge: <karolherbst🐧🦀> `this->print();` should do it
10:30fdobridge: <airlied> Will be tomorrow, powered down for night
10:30fdobridge: <karolherbst🐧🦀> okay
13:44fdobridge: <gfxstrand> @karolherbst Any thoughts about https://gitlab.freedesktop.org/nouveau/mesa/-/merge_requests/248 before I pull it in?
13:45fdobridge: <gfxstrand> In particular, any thoughts around how I'm handling the handful of depricated APIs we're using. I wanted to keep nouveau_drm.h an exact copy of the kernel header if possible.
13:54fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> "depricated"
13:58 #dri-devel: < KungFuJes14:16 fdobridge: <karolherbst🐧🦀> yeah.. I don't know if userspace can even use it
14:16fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> You can resolve this thread now: https://gitlab.freedesktop.org/nouveau/mesa/-/merge_requests/248#note_2022419
14:16fdobridge: <karolherbst🐧🦀> anyway... my bet was on "new UAPI" so I didn't really bothered as much
14:17fdobridge: <karolherbst🐧🦀> I think the idea was to use nvif for everything, but...
14:17fdobridge: <karolherbst🐧🦀> all that stuff is a bit weird
14:17fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> I remember there being a MR for Wine which fixed quite a few typos 🍷
14:18fdobridge: <gfxstrand> Where does nvif come from? Is it a kernel-defined thing or something that's actually in hardware?
14:18fdobridge: <karolherbst🐧🦀> kernel defined
14:18fdobridge: <gfxstrand> Then it needs to be in `src/include/uapi/`
14:18fdobridge: <karolherbst🐧🦀> well.. it's not
14:18fdobridge: <gfxstrand> Yeah, I can see that
14:19fdobridge: <karolherbst🐧🦀> I think the best bet is on making it all proper with the new UAPI and move things over so we can just cut it all of or something...
14:22fdobridge: <gfxstrand> This whole think feels like a case study in why we have open-source userspace requirements for new kernel API...
14:23fdobridge: <gfxstrand> In any case, I think I'm going to go ahead with that MR. It doesn't make anything worse (now that I've fixed the typos) and it makes it easier to pull in the updated headers.
14:23fdobridge: <karolherbst🐧🦀> yeah
14:24fdobridge: <karolherbst🐧🦀> might as well pull in all the other headers... but...
14:29fdobridge: <karolherbst🐧🦀> maybe we want to require that NVK only uses things from `src/include/uapi/` and clean that entire mess up
14:30fdobridge: <gfxstrand> Yes, I would like that.
14:30fdobridge: <gfxstrand> IDK that I want to make it a requirement for merging NVK because APIs do exist even if they're badly documented and in the wrong spot but that should be the end goal.
14:31fdobridge: <karolherbst🐧🦀> ahh yeah.. maybe "unless it's used by GL" is a fair exception