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