05:37 omeringen: @karolherbst did you check my new 5.17 kernel log for gf108m issue (wayland+nouveau) ?
06:38 omeringen: test123
14:45 imirkin: anholt: i'm getting a bunch of stuff like "ERROR - dEQP error: WARNING: value %1 not uniquely defined" with your nir enablement. i suspect the issue is due to a shortcoming in the from_tgsi code, but will need to have a look. these sorts of things tend to lead to wrong code at least some of the time.
14:57 karolherbst: imirkin: I think I even know what those are all about...
14:58 karolherbst: something something special input/output things
14:59 karolherbst: vtxBase stuff?
14:59 karolherbst: or something else.. anyway, we do or used to reassign ssa values by applying some modifications on them
15:43 anholt: imirkin: which GPU?
16:35 imirkin: anholt: GT215
16:36 imirkin: anholt: but on things which totally don't matter for any differences between a G92 and that
16:37 imirkin: karolherbst: it can be due to a number of factors, generically. this is pretty commonly with like %1, which i haven't really seen before. usually it's with higher "regs"
16:37 karolherbst: there was something we did with inputs
16:37 karolherbst: but just some
16:37 imirkin: could be
16:38 imirkin: i haven't looked into it
16:38 karolherbst: I remember seeing something like that
16:38 karolherbst: something like projection or whatever and we just assign to the same ssa value. I thought I fixed something like that though
16:38 imirkin: anholt: ERROR - Failure getting run results: parsing results: Reading from dEQP: timed out waiting for fd to be ready (See "gt215-results-nir/c172.r1.log")
16:38 imirkin: getting a _ton_ of those. local disk.
16:39 imirkin: oh. but i think the gpu may be hung. so that's fair.
16:40 karolherbst: imirkin: NV50LoweringPreSSA::processSurfaceCoords does something like this as well
16:40 karolherbst: "coords[1] = bld.mkOp2v(OP_SHL, TYPE_U16, bld.getSSA(2), coords[1], ms_y);"
16:40 imirkin: karolherbst: this is with GLES2 tests
16:41 imirkin: so probably not it.
16:41 karolherbst: it's not the only thing where we do it
16:41 imirkin: that seems reasonable though
16:41 karolherbst: handleMEMBAR as well, and others
16:41 imirkin: i don't see the problem.
16:41 karolherbst: imirkin: you still assign to the same value
16:41 karolherbst: ehh wait
16:41 imirkin: bld.getSSA(2)?
16:41 karolherbst: no, you are right.. I thought about it wrongly
16:41 imirkin: ok
16:42 imirkin: that is definitely the least-baked code we have
16:42 karolherbst: ahh.. handlePOW does it :)
16:42 karolherbst: bld.mkOp2(OP_MUL, TYPE_F32, val, i->getSrc(1), val)->dnz = 1;
16:42 imirkin: mmmmmmmmm
16:42 imirkin: but that's OK if it's pre-ssa
16:43 karolherbst: sure
16:43 karolherbst: we complain nontheless if it's a SSA value
16:43 karolherbst: it's probably not a bug, but
16:43 imirkin: i don't think that's the case
16:43 imirkin: when i dig into it, i guess i'll figure it out
16:43 karolherbst: yeah..
16:44 imirkin: anholt: btw, https://gitlab.freedesktop.org/mesa/mesa/-/issues/6292 -- looks like that lowering pass goes pretty wrong
16:44 anholt: imirkin: note that that entire pass is deleted with !8044
16:44 imirkin: i understand
16:45 imirkin: but i'd be looking to do apples-to-apples
16:45 imirkin: right now the nir thing is still coming up short. and it's broken right now.
16:45 anholt: the nir-to-tgsi mode? in which workloads?
16:45 imirkin: nir-to-tgsi mode
16:45 imirkin: well, the warning i mentioned is very worrying
16:46 imirkin: also it just hung my gpu when doing a full deqp run, which i've never seen in regular mode
16:46 imirkin: (and in fact i had just run it "normally" before, which is what brought up the csel issue)
16:48 imirkin: anholt: the first caselist which was missing is already in GLES31-land, so perhaps some image stuff goes wrong
16:54 anholt: oh, and I haven't tested anything in gles31 because I was on nv92.
16:55 anholt: you had said "there is no difference in shader code until nva0" and somehow I read that as nvc0?
16:55 imirkin: well
16:55 imirkin: heh
16:56 imirkin: so the thing about that is
16:56 imirkin: nv50+ all have compute/images/etc
16:56 imirkin: (well, i wouldn't necessarily try it on the original G80, but... yeah)
16:56 imirkin: however
16:56 imirkin: GLES31 adds more stuff
16:56 imirkin: which is 99% available on nva3+
16:56 imirkin: so we expose GLES31 there
16:56 imirkin: however if you force GLES31 on a G92, it should "work", just some stuff will totally fail
16:57 anholt: so, the maxifdepth thing might be a problem. we had nothing lowering for maxifdepth on the nir side, so once I GCed the tgsi side I removed that code. but we'll need something to do that job for this hardware.
16:57 anholt: lower_if_to_cond_assign was a totally bogus way to lower for maxifdepth since it let side effects happen.
16:57 imirkin: anholt: tbh, i don't know if it's strictly needed. my understanding of this stuff is totally lacking, sadly
16:57 imirkin: i do know that there's a "call" stack
16:58 anholt: but I'll need to do a max-if-depth nir pass. r600 could use one, too, though its limit is a bit bigger than 4.
16:58 imirkin: of finite size. with off-chip options available.
16:58 imirkin: fwiw nvc0 also sets that limit, but to 16
16:58 imirkin: again, no clue what requirement if any there is
17:08 imirkin: anholt: fwiw that pass did use to work, or at least not fail quite as loudly
17:17 imirkin: anholt: if you do force GLES31, expect all the shared atomics stuff to fail, along with the DX10.1 features (query lod, gather, probably something else i'm forgetting)