01:11 alyssa: karolherbst: why do you call nir_convert_from_ssa when nouveau seemingly has its own out-of-SSA pass?
01:16 imirkin: nouveau SSA != nir SSA
01:17 imirkin: not easy to plug one into the other
01:17 imirkin: oh, also nouveau's not set up to receive SSA on input. so lots of passes assume non-ssa
02:24 alyssa: got it
02:24 alyssa: out of curiousity what's the difference, other than nouveau enforcing CSSA (from the looks of it)?
02:48 imirkin: alyssa: well, SSA isn't just the single assignments. SSA is also the information about ins/outs, block connections for phi's, etc. it could all be hooked up properly, probably, but it's not 1:1
02:49 imirkin: alyssa: the bigger problem is definitely that all the lowering logic lives in non-SSA land
10:30 karolherbst: alyssa: yeah.. before we can get rid of the pre SSA stage a lot of things need to be moved around
14:57 Ilgaz: wow many people around
15:00 alyssa: imirkin: karolherbst: fair enough
15:16 Ilgaz: It is the first time I use XFCE4 and its terminal has major issues with nouveau. Is it known or I found another crazy issue? nvidia 9400 (ducks)
15:17 Ilgaz: I have video but can't really upload yet I am on a live USB
15:48 anholt: imirkin: got the test box back up, but I'm only making it like 10% of the way into a -j1, single-test-at-a-time dEQP-GLES31.* test run before the nv92 dies and doesn't come back. tgsi backend.
15:50 imirkin: anholt: hrmph. ok. i'm trying to remember what i did ... before i plugged the GT215 in, i think i had a G92. it was missing some features, but i don't think it was super-dying...
15:50 imirkin: (but i was trying to make stuff actually work, so that obv wasn't good enough)
15:50 imirkin: anholt: anyways, pretty sure i'll be able to try stuff today
15:51 imirkin: anholt: out of curiosity, what appears to be the method of death?
17:04 anholt: this one started with a bunch of
17:04 anholt: Apr 24 08:49:14 wales.anholt.net kernel: nouveau 0000:01:00.0: gr: magic set 0:
17:04 anholt: Apr 24 08:49:14 wales.anholt.net kernel: nouveau 0000:01:00.0: gr: 00408904: 20087f0a
17:04 anholt: Apr 24 08:49:14 wales.anholt.net kernel: nouveau 0000:01:00.0: gr: 00408908: 000220df
17:04 anholt: Apr 24 08:49:14 wales.anholt.net kernel: nouveau 0000:01:00.0: gr: 0040890c: 40000430
17:04 anholt: Apr 24 08:49:14 wales.anholt.net kernel: nouveau 0000:01:00.0: gr: 00408910: 21a00000
17:04 anholt: Apr 24 08:49:14 wales.anholt.net kernel: nouveau 0000:01:00.0: gr: TRAP_TEXTURE - TP0: 00000003 [ FAULT]
17:05 anholt: also some of this mixed in:
17:05 anholt: 00200000 [] ch 2 [001f9e9000 deqp-gles31[2974]] subc 3 class 8297 mthd 194c data 00000000
17:05 anholt: trapped read at 000220df00 on channel 2 [1f9e9000 deqp-gles31[2974]] engine 00 [PGRAPH] client 0a [TEXTURE] subclient 00 [] reason 00000002 [PAGE_NOT_PRESENT]
17:05 karolherbst: anholt: ohh, you can't run the multithreaded tests in case you are
17:05 anholt: this is dEQP-GLES31, it doesn't have multithreaded tests
17:05 anholt: the eventual timeouts are:
17:05 anholt: TRAP_MP_EXEC - TP 0 MP 0: 00000008 [TIMEOUT] at 07fff0 warp 8, opcode f7c00001 8000c781
17:06 karolherbst: anholt: yeah.. seems like the shader accesses memory which isn't there
17:06 karolherbst: there is probably something wrong in how we track resources, but couldn't figure out what's actually wrong, as those faults are not easily triggered
17:07 karolherbst: (also our recovery code isn't really stable either :( )
17:08 karolherbst: anholt: do you know which tests were running at the point it crashed?
17:08 anholt: dEQP-GLES31.functional.texture.gather.basic.2d_array.depth32f.filter_mode.min_linear_mipmap_linear_mag_linear was the first timeout from deqp-runner in this run
17:08 anholt: but it was dEQP-GLES31.functional.texture.gather.basic.cube.rgba8.filter_mode.min_linear_mag_linear last time
17:09 karolherbst: mind running "dEQP-GLES31.functional.texture.gather.basic.*" looped and see if that triggers it?
17:09 karolherbst: mhh but sometimes it also matters which tests were ran before
17:10 anholt: given the number of fails in tex gather tests, I should probably just check them in the skip list actually
17:10 karolherbst: ohh, so those tests fail?
17:10 karolherbst: okay, then maybe that's not hard to figure out then
17:10 karolherbst: textureGather is GL 4.0+, right?
17:11 karolherbst: given that it's 3.3 hardware, maybe ew implement it wrongly or something
17:12 karolherbst: I don't even know if nvidia exposes ARB_texture_gather on those GPUs
17:12 karolherbst: or well GLES3.1
17:13 karolherbst: anholt: I think it would be best to skip those tests for now and I can see if I figure something out
17:14 imirkin: karolherbst: hrm, there's no gather on G92
17:14 imirkin: karolherbst: perhaps we generate stupid code for that. i'd just exclude texture_gather.*
17:14 imirkin: er, anholt --^
17:14 karolherbst: yeah.. that would be my guess
17:14 imirkin: karolherbst: gather is a DX10.1 feature, available on nva3+
17:14 karolherbst: ahh
17:15 karolherbst: then I am wondering why those tests even run on g92
17:15 anholt: anything else you can think of the hw won't do that could help save me time?
17:15 karolherbst: or do we expose GLES3.1 there?
17:15 imirkin: because i asked him to force-enable ES 3.1
17:15 karolherbst: okay
17:15 karolherbst: imirkin: I guess we emit the nva+ code then
17:15 imirkin: (or use a nva3+ board, but only nv92 is available iirc)
17:15 imirkin: yeah
17:15 imirkin: i don't think we're super-careful about that
17:15 karolherbst: probably not
17:16 karolherbst: might want to assert in codegen or something
17:16 imirkin: i'll test stuff out on my GT215 later today
17:16 karolherbst: so the test just crash
17:17 karolherbst: what was textureGather again, TXG?
17:17 imirkin: or TG4
17:17 imirkin: both names are used
17:17 karolherbst: right, but emit nv50 doesn't know TG4 at all :)
17:17 imirkin: yeah, i think OP_TXG in nv50 ir
17:17 karolherbst: yeah, so we simply emit the stuff on g92
17:18 karolherbst: we do handle it inside isOpSupported though
17:18 imirkin: but we never check it iirc
17:21 karolherbst: how hard would it be to emulate TXG anyway :D
17:23 imirkin: mmmm ... it's _incredibly_ annoying
17:23 imirkin: i tried a bunch of "simple" things on adreno a4xx, and it totally didn't work
17:23 imirkin: (a4xx has a buggy texgather impl, and in the end i just worked around the bugs, as painful as it was)
17:24 imirkin: vs emulating the gather with tex & co
17:24 karolherbst: I see
17:24 imirkin: obv achievable if push comes to shove. but it'd be a ton of code.
17:24 imirkin: offsets make it esp annoying.
17:24 karolherbst: the doc of textureGather makes it sound so simple :D
17:24 imirkin: yes.
17:25 imirkin: and it's easy to make it _mostly_ work
17:25 imirkin: otoh, integer borders are just plain broken on nv50, so perhaps we can keep some of the more annoying bits equally broken? dunno
17:28 karolherbst: anholt: image_load_store probably doesn't work at all besidnes in compute shaders, but no idea how the situation is in GLES
17:28 imirkin: image_load_store definitely should work
17:28 imirkin: esp in compute shaders :)
17:28 imirkin: exclusively in compute shaders :)
17:28 karolherbst: :)
17:28 imirkin: [along with ssbo]
17:28 anholt: compute.shared_var has a bunch of fail in it. haven't made it to touch-testing load/store
17:28 karolherbst: I guess that's all legal in GLES to only do that in CS?
17:28 imirkin: anholt: shared_var fails are expected
17:28 anholt: I'm no longer trying to run whole CTS, just hitting subsections.
17:29 imirkin: anholt: on G92
17:29 imirkin: karolherbst: yeah, ES 3.1 only requires that stuff in compute
17:29 imirkin: karolherbst: AEP bumps the requirement to frag (as does ES 3.2 iirc)
17:29 karolherbst: ahh
17:30 karolherbst: sadly I really don't know much about GL(ES) so I couldn't tell what's in GLES3.1 but not supported by nv50 :(
17:30 imirkin: karolherbst: we expose ES 3.1 on nva3+
17:30 imirkin: it's 99.9% supported ... i ignored a couple of (imho) very minor things
17:30 karolherbst: yeah, but we still talk about g92 here, no?
17:30 imirkin: correct
17:30 imirkin: so the DX10.1 stuff is not supported on G92, but almost everything else is
17:31 anholt: so imirkin asked me to test on nv92 because that would approximate the nva3+ support to see if the NIR transition breaks this subset of functionality
17:31 imirkin: anholt: tex gather, tex query lod are not supported
17:31 imirkin: anholt: a few more shared things will fail, due to no atomics
17:32 imirkin: [on the G92]
17:32 imirkin: anholt: also texture border colors are *expected* to fail for integers
17:32 anholt: I've put that in my xfails
17:32 imirkin: anholt: iirc i did test originally on G92, so stuff like image load store and ssbo should largely pass
17:47 anholt: whoops, found another pocket of texture gathers
17:49 anholt: would sure be neat if nouveau could give up on trying to recover the gpu while I was trying to reboot.
17:49 karolherbst: anholt: yeah ... :( but we will have new code in this regard soonish
17:49 karolherbst: Ben is working on something
17:51 karolherbst: anholt: do you know if it's waiting on the userspace process? Because I have patches to add detection of crashed contexts, which one just needs to review
17:52 anholt: I don't understand how reboot would be waiting on deqp userspace in the first place.
17:52 karolherbst: depends on the system, like if you have systemd waiting on logind to stop, and logind waits on the user session to quit or something
17:53 karolherbst: but we do also have bugs in the kernel here, so ... :(
17:53 anholt: nouveau is unique in being bad at this, I don't have this issue with gpu hangs on other drivers.
17:54 karolherbst: I got tired to bring those issues up, because the response I am getting usually is "just fix userspace" or "just fix the bug instead" :)
17:55 anholt: yeah. I feel like if I was to work on nv vulkan in mesa, I'd probably just write against the nvidia kernel module.
17:56 karolherbst: yeah... it sucks, but Ben promised me that the new code should fix those issues, so I kind of wait for that now
17:56 imirkin: anholt: gpu hangs + nouveau = fatal
17:56 imirkin: the general solution is "avoid gpu hangs"
17:56 imirkin: it's gotten much worse over the years
17:56 imirkin: used to be a lot less fatal
17:56 imirkin: the various efforts to make recovery better have made gpu hangs worse, paradoxically
17:58 karolherbst: luckily that's all solved on newer GPUs
18:07 imirkin: unluckily, newer gpu's are pretty useless
18:38 imirkin: [on re-reading, what i said wasn't entirely fair -- there are *fewer* hangs now, but they are *more* fatal. hangs used to happen all the time before, but they generally sorted themselves out]
19:03 karolherbst: imirkin: depends on what means "fatal", detecting hung channels does fix one category of those and we should really get those patches in tbh
19:03 imirkin: hard hang.
19:03 karolherbst: well.. the one sort of hang just freezes the desktop, without crashing the kernel
19:04 karolherbst: but yeah, there are also this sort of hand, where the GPU DOSes the kernel with IRQs
19:04 imirkin: yeah, esp with heavier GPU usage among generic programs, it's all been exacerbated as well
19:04 imirkin: so hard to tell exactly what's going on
19:04 karolherbst: yep
19:04 karolherbst: anyway, we should get my patches in :P
19:05 karolherbst: like this one: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/188
19:44 anholt: ok, looks like nir backend is missing some <GF100 image/ssbo support. I'll look at tomorrow.
19:47 karolherbst: anholt: yeah.. soo.. we don't really support that for non compute things
19:48 karolherbst: could be that I missed something, because I think back at the time we didn't supported those things for nv50
20:23 karolherbst: anholt: I guess we'll need f451854f39f580c6c95a574428498e32ffb6e840
20:24 karolherbst: and potentially c95d2a86d38bab02214dba3bdca0269f8ee4a3e0
20:24 karolherbst: I can look into this tomorrow