01:03bnieuwenhuizen: anholt: are you aware of any issues wrt the number of jobs? on my 32 core/64 thread CPU I only get 31 deqp-vk processes at the same time and if I try to use -jN I get anywhere 8-(N+1) deqp-vk processes active at the same (and the number seems stable over a given run)
01:03bnieuwenhuizen: (wrt deqp-runner)
01:33anholt: bnieuwenhuizen: interesting! I haven't seen that.
01:33anholt: so, I think without a -j, getting cores-1 is believable.
01:33anholt: (though I thought based on our load numbers in the job runs we'd been doing fine. maybe not!)
01:36bnieuwenhuizen: well, it is weird because if I don't set j but increase the min group size to 2000 I get the proper 64 parallelism now
01:36bnieuwenhuizen: so I'm kinda inclined to say that 31 is just luck based on whatever it does
01:37bnieuwenhuizen: but if I got for a manual -j45 or so I end up with 8-15 most of the time ...
01:40anholt: threw up an issue so I can remember this next week.
01:40bnieuwenhuizen: cool, thanks!
01:41anholt: so, the default -j issue, I believe, is that the results collection thread is eating a thread in the pool which is sized to cores. so I need to just default an unset run.jobs to # cores and do the same behavior as manual -j
01:41anholt: but no clue yet on manual -j being wrong
01:42bnieuwenhuizen: yeah the 31 vs 32 issue is IMO not a problem
01:42bnieuwenhuizen: just it not being closer 64 was weird
01:42anholt: for CI, it's a bigger deal.
01:42bnieuwenhuizen: ah
03:53shoober420: hi frens
03:54shoober420: quick question
03:54shoober420: if i wanted to debug a game incase there is an error, what commands would i use?
03:55shoober420: like if i loaded up csgo, and wanted to search the log for potential bugs, how would i do that?
04:01HdkR: Hunting for graphical bugs is not a short answer
04:01imirkin: HdkR: what about fixing them? :)
04:02HdkR: imirkin: Do it correctly, ez right? :P
04:02imirkin: hehe
04:05shoober420: so i do see some graphical bugs in csgo
04:06shoober420: and wanted to get a log to see if it could find any clues
04:06imirkin: make an apitrace, and verify that replaying the trace shows those same issues
04:06imirkin: assuming it does, find a frame (preferably early on) which shows the issue
04:06imirkin: then figure out what causes the issue to appear by analyzing the api calls in the frame
04:06shoober420: what if it happens over and over
04:07imirkin: to see if (a) it's a driver problem or (b) an application problem
04:07imirkin: then fix the appropriate component.
04:07shoober420: this lighting bug happens on NVIDIA too
04:07imirkin: ok, so game is most likely then
04:08imirkin: but it's also entirely possible that multiple libs make the same mistakes
04:08imirkin: anyways, that's the rough set of steps that i'd follow
04:08imirkin: there's also renderdoc, which is another tool, although i've been unable to use it successfully
04:09imirkin: but others clearly have :)
04:09shoober420: if i rana debug log on a game, are there errors i can look for to find?
04:09HdkR: Probably not
04:09shoober420: like for example, when i compile a program, sometimes i get errors about values being too large
04:10HdkR: Just because there is a graphical glitch doesn't mean anything will appear in a log
04:10imirkin: you want a (replayable) log of the GL commands
04:10shoober420: i see i see
04:10imirkin: the tool for that is "apitrace"
04:10imirkin: another one is "renderdoc", but like i said, i couldn't work out how to operate it
04:10shoober420: i understand now
04:10shoober420: what about compile errors?
04:11shoober420: i want to learn to program honestly
04:11HdkR: Hopefully if you're building apitrace or renderdoc then it won't have any compiler errors, and I doubt you'll be compiling CSGO :)
04:11imirkin: if there are compile errors in the shaders, you'd have a lot more than glitches
04:15hurricos: How can I direct piglit towards a particular display interface without actually bringing up a display?
04:15hurricos: I suspect it's a matter of environment but I haven't quite figured it out.
04:15hurricos: Say, if I have an intel iGPU and a dGPU, but no head.
04:18imirkin: hurricos: something like PIGLIT_PLATFORM=gbm GBM_DEVICE=/dev/dri/renderD1234
04:18imirkin: check it with the "glinfo" piglit first to make sure it's going to the right place
04:20imirkin: hurricos: hm, that's not quite right. hold on...
04:20hurricos: imirkin: The glinfo piglit, I took to mean "./piglit run glinfo results/glinfo", but no dice there
04:21imirkin: well, much easier to just run it as "bin/glinfo", but yeah, that didn't work for me either
04:21imirkin: give me a sec to work out the actual thing to do
04:21hurricos: Thanks :)
04:21imirkin: hurricos: try WAFFLE_GBM_DEVICE
04:21imirkin: i'm getting crashes, but i think it's because i've neglected to recompile something
04:31hurricos: imirkin: fyi, the only difference in {,WAFFLE_}GBM_DEVICE is that WAFFLE_ intentionally fails if an X.org session is not running
04:32imirkin: https://gitlab.freedesktop.org/mesa/waffle/-/blob/master/src/waffle/gbm/wgbm_display.c#L130
04:32imirkin: it _should_ work, but i guess it doesn't (anymore?)
04:32shoober420: thanks for the info guys, looks like i dont need to debug like that afterall
04:33shoober420: im going to go eat
04:33shoober420: goodbye
04:33hurricos: quite the trace :^)
04:34imirkin: but tbh i'm not clear on what the diff is between the two paths. maybe the 'fd' isn't being respected either way? dunno. i do see the open() in the trace
04:34imirkin: (strace)
04:34imirkin: [for the right device]
04:34imirkin: but then it does what i feel like is the usual loader logic
04:34imirkin: so something's off
04:35hurricos: Neat, it builds by default with symbols and breakpoints.
04:35imirkin: and/or regressed, coz i'm like 99% sure this used to work. i might have been the one to request the WAFFLE_GBM_DEVICE in the first place...
04:35imirkin: https://gitlab.freedesktop.org/mesa/waffle/-/commit/cef67496e379b660601f64ab2ddf7cf06307b8aa :)
04:37imirkin: yeah, even this fails: WAFFLE_GBM_DEVICE=/dev/dri/renderD129 wflinfo -p gbm -a gl
04:37imirkin: so it's not a piglit issue. sigh...
04:38hurricos: fwiw: With no X.org, I do get: PIGLIT_PLATFORM=gbm WAFFLE_GBM_DEVICE=/dev/dri/renderD128 bin/glinfo
04:38hurricos: piglit: error: waffle_display_connect failed due to WAFFLE_ERROR_UNKNOWN: failed to open gbm device "/dev/dri/renderD128"
04:38hurricos: PIGLIT: {"result": "fail" }
04:38hurricos: which is better as it's not a segfault :^)
04:38imirkin: ok, so you have a diff set of problems
04:38imirkin: you just don't have rw permissions on the device in question
04:38hurricos: oh
04:39hurricos: the group changes when you X.org off??
04:39imirkin: depending on distro, you might have some bit of cleverness
04:39imirkin: which tries to do multi-seat bs
04:39imirkin: huzzah for ease of use!
04:40hurricos: ligthdm to manage the greeter, and it's just Ubuntu Server, with a few DE's set up.
04:40imirkin: so probably with systemd?
04:40hurricos: yes.
04:40imirkin: well there ya go
04:40hurricos: whence multiseat
04:43hurricos: truly a strangeness, it must be systemd. On desktop:
04:43hurricos: printenv > /tmp/a
04:44hurricos: in console: ( source /tmp/a; bin/glinfo; )
04:44hurricos: desktop works. Console does not. :^(
04:44imirkin: nothing a chmod can't fix.
04:44hurricos: even sudo doesn't
04:44imirkin: note that 'renderD128' is probably the default anyways
04:46hurricos: hmm :^)
04:46hurricos: labby@cleric:/mnt/wiz/devel/piglit$ PIGLIT_PLATFORM=gbm WAFFLE_GBM_DEVICE=/dev/dri/renderD128 bin/glinfo
04:46hurricos: Segmentation fault (core dumped)
04:46hurricos: Y
04:46hurricos: That^ is on desktop
04:46imirkin: woohoo!
04:46imirkin: so you also get a crash
04:46hurricos: so it's WAFFLE :^)
04:46hurricos: yes
04:46hurricos: now let's trace it ;P
04:46imirkin: something regressed in the intervening 5 years since i've used it
04:46imirkin: well, it crashes in the teardown
04:47imirkin: coz something fails to create
04:47imirkin: which isn't ideal either - it shouldn't crash - but even more ideally it wouldn't fail to create.
04:47hurricos: is this limited to piglit or would I have to hop mesa versions?
04:47hurricos: I am happy doing a git bisect.
04:47imirkin: it's waffle-specific
04:47hurricos: oh
04:47hurricos: that's not good :^(
04:47imirkin: like i said, i get the same issue with wflinfo
04:47imirkin: which is completely not piglit-based
04:48imirkin: (it's a tool included with waffle)
04:48imirkin: feel free to bisect waffle
04:48imirkin: should be quick - it's not a big project that gets tons of commits
04:48imirkin: start at the commit i pointed to when the feature was introduced
04:48hurricos: not quick. I installed it through my OS's package manager
04:48imirkin: ah ok
04:48imirkin: well you don't have to do a system install of it
04:49hurricos: uses quite a few things according to `ldd`
04:49imirkin: ok
04:49imirkin: well i might have a look tomorrow or something
04:49imirkin: although i'll probably forget
04:49hurricos: no worries, you don't have to
04:49imirkin: file a bug in gitlab, i guess
04:49imirkin: perhaps someone will care
04:49hurricos: I don't know if I'll get there, my cat is presently tearing down frames off walls :^)
04:50imirkin: hehe
04:50imirkin: if you're in X
04:50imirkin: and have DRI3
04:50imirkin: you can also do like
04:50imirkin: DRI_PRIME=pci-0000_04_00_0
04:50hurricos: oh everything works when I'm in X in fact
04:50hurricos: sorry, not to mislead
04:50imirkin: (you can figure out the right tag with udevadm info /dev/dri/renderDxxx)
04:50imirkin: it works with renderD128
04:51imirkin: i thought you had multiple devices
04:51hurricos: I am on a desktop with i7-4790S and HD 5470, and piglit works just fine.
04:51imirkin: and wanted to pick out a specific one
04:51jekstrand: bnieuwenhuizen, airlied, dj-death: https://gitlab.freedesktop.org/jekstrand/mesa/-/commit/00fe7d80d1949ddc0f34deaddbf845720678eb9f
04:51hurricos: but I have many HD5470's
04:51imirkin: right
04:51hurricos: and a thirst to get RuneLite's GPU extension to work without crashing with some 'radeon ring 3 stall' or somesuch
04:52hurricos: and I'm going to be racking a set of bladeservers tomorrow so I thought
04:52jekstrand: bnieuwenhuizen, airlied, dj-death: Just have to figure out a good solution for the version in ICD json files and restricting extensions and API versions on Android and I'll be able to delete 100% of anv's codegen. \o/
04:52imirkin: sounds like you know how to have a fun weekend!
04:52hurricos: why not stick those GPUs in them and piglit every mesa commit so I can know when I should retest?
04:53hurricos: not much you can't chew through with 4 x 2xL5640 :^)
04:53hurricos: but alas, it is not so easy :^(
04:55imirkin: in X, you can use DRI_PRIME=<tag> to force use of a different gpu device for rendering
04:56hurricos: Frankly I don't even know how to get my BIOS to use the intel-connected display when I have a dGPU :^)
04:56hurricos: I think it just ignores it. I think.
04:57hurricos: I wonder if a wonderful hack like xpra might work though.
04:57hurricos: .... to set up the environment correctly for piglit to work
04:59imirkin: some bios's let you force the igpu
05:00imirkin: on some motherboards, the igpu disappears entirely with a dgpu plugged in
05:00imirkin: that said, if you're talking about 5640's, those are xeon's - don't think those had igpu's
05:00imirkin: (and they were around ironlake generation anyways...)
05:05hurricos: hahahahahahaha
05:05hurricos: hahahahahah it works :')
05:05hurricos: I'm dying.
05:06hurricos: oh no
05:06hurricos: wait no it doesn't :'( it's skipping most of them.
05:06imirkin: hurricos: use PIGLIT_PLATFORM=sl
05:06hurricos: or it did, in fact, rather. Xpra must set up its own environment
05:06imirkin: aka surfaceless
05:06hurricos: oh?
05:06imirkin: instead of gbm
05:07hurricos: nope, just fails.
05:07imirkin: oh wait, no
05:07imirkin: just kidding
05:07imirkin: ha ha ha. funny stuff.
05:07hurricos: :'(
05:07imirkin: surfaceless defaults to the last gpu, instead of the first
05:07hurricos: well, xpra skips about 1/3 and succeeds about 2/3
05:07hurricos: oh. that's easy to fix -- do you know the flag to point it at my renderD128?
05:09imirkin: hurricos: filed https://gitlab.freedesktop.org/mesa/waffle/-/issues/69
05:09hurricos: bless :^)
05:10imirkin: hurricos: not sure what Xpra is
05:10hurricos: G84? I just fixed an iMac with a mobile MXM version of that guy :^)
05:10imirkin: hurricos: i also have a Riva TNT2 plugged in.
05:10hurricos: to what exactly?
05:10imirkin: my desktop
05:11imirkin: PCI
05:11hurricos: through what kind of sourcery do you have an AGP slot
05:11hurricos: oh, must be a G4
05:11imirkin: there were only AGP Riva TNT's, but TNT2's also came in the PCI variety
05:11hurricos: oh
05:11hurricos: aha
05:12hurricos: Xpra is the work of the devil, it's the X version of GNU Screen
05:12imirkin: and i have a GT 1030 plugged in. so slightly anachronistic, but ... wtvr
05:12hurricos: I have an RX560D on my desk which crashes every 30 minutes but which I don't have the heart to throw away.
05:13hurricos: Maybe I'm hoping one day we'll have a reflow station.
05:13hurricos: But who am I kidding.
05:13hurricos: reflow only delays the inevitable.
05:15imirkin: ask mupuf for reflow advice
05:16hurricos: I might as well ask mupuf for a reflow station at that point
05:16imirkin: he used his oven :)
05:17imirkin: anyways, i gtg. good luck!
05:17hurricos: oh :^)
05:17hurricos: take care!
05:17hurricos: thank you :^)
05:17imirkin: look at DRI_PRIME if you're in Xorg and want to switch between GPUs
05:17hurricos: nah, Intel sucks :^)
05:17hurricos: thanks though
05:18imirkin: not sure what intel has to do with it
05:18hurricos:says despite that my only working GPUs are Intel
05:18hurricos: will keep in mind though
05:18imirkin: it's a way of addressing diff gpu's
05:19imirkin: nothing to do with intel or nvidia or any other manufacturer
05:19hurricos: Right, but as far as I can tell I can't get my desktop to output on non-discrete ports if a dGPU is in the machine anyways
05:19hurricos: unless you're suggesting I use DRI_PRIME to poke that somehow?
05:19imirkin: mmmmmm
05:20imirkin: check the bios
05:20imirkin: there's usually a setting
05:20imirkin: to prefer the igpu
05:20hurricos: Modern X.org is fancy and well configured and warns you away from doing anything funky :^)
05:20imirkin: even if a dgpu is plugged in
05:20hurricos: Dell XPS. It's super funky and minimal UEFI
05:20imirkin: really? the uefi i've seen on dell xps is ... extensive
05:20hurricos: well let's see now
05:20hurricos: well
05:20imirkin: and i definitely got both to work at the same time on a dell optiplex
05:21hurricos: rather, I'll check back in if I find good results
05:21imirkin: (maybe 3050 or 3060? somewhere in there)
05:21hurricos: since I'm speaking from here
05:21imirkin: good luck
05:21hurricos: thank you!
05:33idr: imirkin: There were definitely PCI Riva TNT cards. I'm pretty sure I had a PCI Diamond Viper V550 back in the day.
05:33idr: http://www.vgamuseum.info/index.php/cpu/item/591-diamond-viper-v550-nvidia-riva-tnt
11:43Lightkey: idr: That was my first graphics card!
14:41hurricos: evel
16:23imirkin: idr: wow, that's news to me! neat! but less available on ebay i guess.
16:25imirkin: idr: that still leaves the nv2x's (GF4 Ti) series which I think were AGP-only (if you don't count the xbox)
16:32imirkin: something should be done with https://github.com/waffle-gl/waffle ...
16:33dcbaker: It would be nice if we could make it a mirror
16:37imirkin: hurricos: waffle 1.6.2 fixes the segfault problem btw
16:37imirkin: mattst88: friendly request to bump waffle to 1.6.2 in gentoo
16:38mattst88: ah, thanks. will do
16:38mattst88: imirkin: or you can send me a github pull req :)
16:38imirkin: hehe
16:40jekstrand: chadv: ^^
17:34dcbaker: I think xexaxo1 might be able to help too
17:36imirkin: it actually looks like the waffle 1.6.2 release was not completed, at least a separate "release" was not created for it
17:37dcbaker: Yeah, i don't see a release
20:04jekstrand: bnieuwenhuizen: I know you're getting tired of me adding patches to !8676 so I made a second MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8792 :-P
20:11bnieuwenhuizen: jekstrand: hah, I was inspired and started removing the radv format table generation scripts. Gotta have that zero-python too :P
20:18jekstrand: bnieuwenhuizen: :D
20:18jekstrand: I'm not opposed to codegen in general. I think I've written most of the codegen that's been added to Mesa in the last 6 years.
20:19jekstrand: But it is always at least a little bit broken somewhere and it definitely is harder to maintain.
20:19jekstrand: And I think the code-gen around Vulkan has gotten a bit out-of-hand. :-/
20:19bnieuwenhuizen: well, I think the out-of-hand part applies here given that it is an almost copy of the gallium one that diverged
20:20bnieuwenhuizen: (of course we're going to have lots of python still in e.g. nir and aco(?))
20:20jekstrand: Not as out-of-hand as the 5 divergent copies of anv_entrypoints_gen.py. :-P
20:21bnieuwenhuizen: only because anholt got to it sooner with turnip
22:08Venemo: bnieuwenhuizen: ACO has a bunch of python, yeah, and I don't think that's bad
22:08Venemo: definitely less error-prone than copy pasting C/C++
22:40hurricos: imirkin: Testing :^)
22:44jekstrand: Wow, for the first time in 6 years, someone actually found a bug in NIR's out-of-SSA pass.
22:44jekstrand: A liveness bug was found and fixed 6-12 months ago. That's the only real liveness bug I'm aware of.
22:45jekstrand: Oof. I hete debugging those passes.
22:45jekstrand: Maybe this one's the 2nd in 6 years. In any case, they don't happen often. :)
22:46hurricos: some compilation involved -- will check back later, finishing racking up some servers :^)