00:49 imirkin: how does one debug meson not finding llvm?
00:49 imirkin: in days past, i'd look in config.log to see wtf was going on
00:50 imirkin: now i get this: https://hastebin.com/anoloyunil.coffeescript
00:52 kisak: imirkin: what llvm and meson version do you have?
00:53 imirkin: meson 0.53.1, llvm 9.0.1
00:53 bnieuwenhuizen: maybe some more info in ${BUILDDIR}/meson-logs/meson-log.txt or is that just stdout?
00:54 imirkin: hm, does seem to have more info for some things, but not for llvm
00:54 imirkin: https://hastebin.com/gozeriyona.rb
00:55 imirkin: and what's the way to figure out how you had configured a thing, so i can wipe the build dir and start over?
00:56 imirkin: aha, found that at the top of meson-log
00:57 bnieuwenhuizen: but I suspect llvm-config is not on your path or something?
00:57 imirkin: $ llvm-config --version
00:57 imirkin: 9.0.1
00:58 bnieuwenhuizen: bleh, so that is ok ...
01:01 imirkin: aha, there's a separate stderr thing:
01:01 imirkin: llvm-config found: NO need '>= 3.9.0'
02:31 imirkin: mareko: looks like fd6636ebc06d55b59851701c436b8b97f50fd7f4 misses something. i end up with a user buffer in nouveau without min/max set (just bisected to this commit)
02:54 imirkin: mareko: the program doesn't do anything too clever - just glEnableClientState + glDrawElements, all client data
03:02 imirkin: huh. _mesa_draw_nonzero_divisor_bits is returning 0x10003 which is clearly bogus
03:02 imirkin: return ~vao->_EffEnabledNonZeroDivisor & ctx->Array._DrawVAOEnabledAttribs;
03:02 imirkin: this feels backwards... the ~ shouldn't be there
03:05 imirkin: yeah, getting rid of the ~ fixes it
03:22 imirkin: anyone around who understands how to operate gitlab? i'm trying to figure out how to submit a MR, but i'm being stymied at every turn
03:27 imirkin: i had a personal mesa repository, i pushed a branch there, but it doesn't come up when i click on "create merge request"
03:27 imirkin: i think i didn't create it as a fork, so i moved it out of the way
03:27 imirkin: and tried to fork from the main mesa thing, but it says that there's already a "mesa" repository
05:09 orbea: imirkin: you could try nuking your repo, creating it as a fork, then adding that as a new remote to your local repo, rebase and push your branch.
05:09 imirkin: i already renamed it =/
05:09 imirkin: but it's still thinking there's a namespace collision
05:09 imirkin: anyways, wtvr, i don't want this badly enough
08:50 daniels: imirkin: you only changed the display name, not the path - I've moved it properly out of the way for you now so you can fork
12:04 Venemo: imirkin: after you fork the mesa repo, it will automatically offer you to open a MR when you push a new branch. just click on the link that it gives you on the command line
12:08 jcdutton: Can anyone tell me what this message means?
12:08 jcdutton: [drm:amdgpu_ttm_backend_bind [amdgpu]] *ERROR* failed to pin userptr
12:13 bnieuwenhuizen: jcdutton: what are you doing triggering that? Is that some ROCm or are you using host ptrs in GL/vulkan?
12:15 bnieuwenhuizen: (I think the message should happen when you take some memory not allocated by the GPU driver and try to use it from the GPU, if that "import" fails)
12:43 jcdutton: bnieuwenhuizen, clinfo using rocm. Kernel 5.3 no errors. Kernel 5.5.7 shows the error
14:38 MrCooper: imirkin: maybe you passed a native file to meson which overrides the llvm-config path? If so, "bin/meson-cmd-extract.py <build directory>" should show it
16:55 imirkin: daniels: thanks
16:55 imirkin: figured it was something like that
16:57 imirkin: MrCooper: i've wiped the build dir several times already (for unrelated reasons), so i'm fairly sure i don't have a "native" file passed into that build
16:57 imirkin: although i have used that on occasion... maybe something's getting picked up?
16:58 imirkin: MrCooper: no, i just have a -Dprefix, but hopefully that doesn't affect it too much
17:04 imirkin: since it last worked, i've updated both meson and llvm (both regular gentoo package installs)
18:42 imirkin: so what's the etiquette around broken runners? e.g. all the panfrost jobs timed out.
20:17 robclark: imirkin: if intermittent failure, just restart the CI job.. if it is some sort of outage and no one is around to deal with it immediately, you push an MR to disable the runners
20:17 imirkin: robclark: from the looks of it, the runners are just down
20:17 imirkin: but i don't know how to debug it further
20:18 imirkin: https://gitlab.freedesktop.org/imirkin/mesa/pipelines/114304
20:18 imirkin: i've tried restarting one of them, but that didn't help
20:21 robclark: so not an expert, but I think at least the lava machine that controls all the panfrost runners is doing something, but maybe not able to communicate w/ board.. so I think it would be ok to push something to disable the runners (since presumably someone will need to physically do something?).. for panfrost, it is useful to mention the issue to tomeu and alyssa
20:21 imirkin: robclark: and to disable, i just stick a "." in front of the runner definition (thereby making it a class or whatever it is)?
20:21 imirkin: tomeu: alyssa: --^ :)
20:21 robclark: yeah
20:21 robclark: see 18657c0c0a9074d3dfc0763b396929bcf34f71b4 for an example (although in that case it was the freedreno runners)
20:21 imirkin: thanks
20:22 robclark: np
20:22 robclark: things seem to have a habit of falling over on the weekends when no one is physically in the office
20:22 imirkin: ok, and then my MR would include the commit to dsiable those jobs, and thus would pass, right?
20:23 imirkin: or separate MR to disable?
20:26 robclark: probably separate MR is normally what is done.. to not hold up pushing the disable on review or whatever of whatever is in your main MR
20:26 robclark: (unless maybe that is also a quick/obvious fix to get things working again)
20:26 imirkin: the main MR is already reviewed (the patch i sent last night)
20:26 imirkin: and i already ran it against the intel CI separately
20:26 robclark: ahh, then probably ok to lump them together
20:26 imirkin: although it's not 100% clear to me that any drivers other than like nouveau are affected
20:27 imirkin: since everythign else uses u_vbuf
20:27 robclark: I guess use your judgement.. but we have llvmpipe and decent gallium coverage for gles2/3/31 via the a6xx runners
20:27 imirkin: right, and all that stuff passes too
20:28 robclark: the reason to keep them separate is just so the "disable broken runners" can be pushed sooner if there is any reason to hold back on the other things
20:28 imirkin: but i think in practice the bug only affects certain cases. i do remember airlied pushing something to "fix" llvmpipe a while back
20:28 imirkin: which may have been fallout from this bug
20:28 imirkin: but also maybe not :)
20:28 robclark: I'm not sure there is hard/fast rule about pushing CI disables
20:28 imirkin: anyways, will make separate MR
20:28 robclark: you can always rebase 2nd MR on first MR
20:28 imirkin: is it possible to make a MR that is not a branch head?
20:29 robclark: hmm, I dont know of one..
20:29 imirkin: super.
20:29 daniels: robclark, imirkin: please push a commit to disable panfrost hw testing with my Rb
20:29 imirkin: daniels: running git commit as we speak. will throw your r-b in there
20:32 imirkin: daniels: object now if you don't want this going out: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4011
20:33 daniels: imirkin: thanks a lot
20:54 imirkin: robclark: dEQP-GLES3.functional.fbo.blit.conversion.r16f_to_srgb8_alpha8,Fail on a630 =
20:55 imirkin: robclark: i think there's some core thing broken in the blit logic - something not being cleared - or something else -- you seem to be blacklisting them one at a time, but whenever you blacklist one, another one fails
20:55 robclark: you can probably just restart that job.. r16 formats seem more prone to flakes, and in general flakes have gotten worse when we enabled UBWC in more cases..
20:55 imirkin: yeah, i'm restarting it
20:56 robclark: yeah, I'm not a fan of blacklisting one at a time.. we should probably just disable UBWC in CI.. on one hand it isn't great to not be testing in CI what is used in production, otoh I doubt core gallium changes (for example) would break something UBWC related..