01:07 mareko: gfxstrand: shouldn't nir_from_ssa call nir_divergence_analysis? it depends on it, but almost no callers call it
01:12 alyssa: mareko: It doesn't really depend on it
01:12 alyssa: IIRC
01:12 alyssa: If you feed it SSA divergence analysis, it will give you nir_reg divergence analysis
01:12 alyssa: If you don't care about divergence, you don't run the analysis and then the results after will be bogus
01:17 mareko: alyssa: but this is failing: assert(!copy_value_is_divergent(src) || copy_value_is_divergent(dest));
01:19 alyssa: Uhoh
01:20 alyssa: mareko: Well, if you never call divergence analysis, that will be satisfied
01:20 alyssa: so that's failing only because you have.. stale divergence results, I guess?
01:20 alyssa: I can see that being broken
01:21 alyssa: see also https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30814 I guess
01:23 mareko: the GLSL linker calls nir_vertex_divergence_analysis, which reuses the "divergent" field, then it's obviously random after some other passes
01:24 mareko: hm, we need a pass that sets all divergent fields to false
01:24 alyssa: ah..
01:25 alyssa: !30814 would probably solve this "properly" but yeah
16:08 mareko: if I wanted to enable modesetting for r600 and amdgpu by default, where would I do it?
16:09 mareko: r600 and radeonsi that is
16:19 mattst88: mareko: I think you set radeon.si_support=0 amdgpu.si_support=1 on the kernel command line (also .cik_support)
16:20 mattst88: looks like CONFIG_DRM_AMDGPU_SI / CONFIG_DRM_AMDGPU_CIK kconfig options are relevant
16:23 mareko: mattst88: that doesn't affect modesetting
16:23 mareko: xf86-video-amdgpu is used if it's installed
16:23 mattst88: oh, you mean xf86-video-modesetting
16:23 mareko: yes
16:24 mattst88: In that case, I don't know
16:24 mareko: the question is, if we wanted to deprecate xf86-video-amdgpu, what would we have to do
16:27 MrCooper: don't install it
16:27 mareko: is there no table where the selection is determined?
16:27 MrCooper: when it's installed, the modesetting driver can be forced with a ~4-line xorg.conf
16:28 mareko: then it's not the default
16:28 MrCooper: mareko: it's the xorg.conf.d snippet shipped by xf86-video-amdgpu
16:29 MrCooper: shipping the driver but not using it by default doesn't make much sense though
16:29 mareko: ok
16:30 mareko: how distros determine what to install?
16:32 MrCooper: mareko: for -ati it's trickier because the xorg.conf.d mechanism is based on the kernel driver, which is the same for R600 and older Radeons
16:33 mareko: but not amdgpu?
16:34 MrCooper: not sure what you're asking
16:35 mareko: nevermind
18:25 alyssa: mareko: fyi I plan to review all the i/o stuff, either today or early next week
18:31 daniels: mareko: distros generally don’t choose dynamically, but it’s a set list per-arch, so for Ubuntu ping tjaalton, for fedora ajax, etc
18:32 alyssa: mareko: although looks like stuff is blowing up :melt:
19:25 alyssa: jenatali: I don't understand https://gitlab.freedesktop.org/mesa/mesa/-/jobs/66005875
19:26 alyssa: Could you push a fixup? thanks
19:26 alyssa: ../src/compiler/clc/mesa_clc.c(10): fatal error C1083: Cannot open include file: 'getopt.h': No such file or directory
19:26 jenatali: Looking
19:27 jenatali: Apparently getopt.h isn't POSIX
19:27 jenatali: There's a util version, isn't there?
19:31 jenatali: Ah, idep_getopt
19:35 jenatali: alyssa: Fixed
19:35 alyssa: thx
20:12 alyssa: jenatali: mmm nope? :/
20:12 alyssa: clangDriver.lib(MSVC.cpp.obj) : error LNK2019: unresolved external symbol VerQueryValueW referenced in function "class llvm::VersionTuple __cdecl getMSVCVersionFromExe(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (?getMSVCVersionFromExe@@YA?AVVersionTuple@llvm@@AEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z)
20:12 jenatali: Yeah looking...
20:12 alyssa: UHHH
20:14 jenatali: Looks like dep_version needs to be added as a transitive dependency of LLVM
20:26 jenatali: alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/66008570 seems concerning?
20:27 jenatali: SIGSEGV after reporting a passing result
20:28 alyssa: mupuf: ^^
20:32 mupuf: ...
20:32 mupuf: and the previous job also failed: ERROR - dEQP error: malloc(): unaligned tcache chunk detected
20:33 jenatali: Oh I didn't look at the previous one to see it was different
20:44 jenatali: Passed on re-re-run, good enough to reassign to Marge I guess
20:50 mupuf: jenatali: I'll let the radv devs know about these flakes
20:51 mareko: alyssa: there are just some assertion failures in many drivers that seem easy to fix, traces are expected to have slightly different hashes, the fixes can be in the second MR
20:52 mupuf:logs out
20:58 alyssa: mareko: I posted you a patch that should fix most of it
20:59 alyssa: not sure it's sane to try to rework every driver instead of just generating variables that have the proper sizes.
21:01 alyssa: just semantically, it doesn't make sense to have a vec4 VARYING_SLOT_PSIZ and it seems mean to drivers to give them one
21:02 alyssa: (which - even after lowering I/O again - turns into a vec4 store_output instead of a scalar one which is uhhh not great)
21:15 mareko: alyssa: yeah the vector size needs to be different based on the location
21:16 mareko: that should be fixed in the pass, thanks for the code
21:25 alyssa: :+1:
21:45 mareko: the other issue is caused by compact_varyings
21:47 zmike: alright mesa, I'm out for the year
21:47 zmike: take it easy
21:47 jenatali: Have a good vacation!
21:47 alyssa: cheers!
21:53 mareko: enjoy!
22:07 Ermine: How much time should I wait for patch review until resending the patch?