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