jrmuizel has quit [Remote host closed the connection]
jrmuizel has joined #lima
jrmuizel has quit [Remote host closed the connection]
Barada has quit [Quit: Barada]
jrmuizel has joined #lima
jorik_ has quit [Read error: Connection reset by peer]
jonkerj has joined #lima
guillaume_g has quit [Quit: Konversation terminated!]
<rellla>
anarsoul, enunes: i'm digging through some piglit test and noticed, that glsl-fs-fragcoord-zw-ortho for example fails due to wrong depth. is correct depth implementation missing or do I miss sth?
<enunes>
rellla: it also fails for me, I don't know if something is missing exactly. looks like initial depth support is from https://github.com/yuq/mesa-lima/pull/46 , other than that I'd check dumps with the blob
<anarsoul>
rellla: maybe it misses some knob?
<anarsoul>
rellla: IIRC polygon offset isn't implemented but I doubt it should affect depth value
<anarsoul>
rellla: can you show test result?
griffinp- has joined #lima
griffinp has quit [Read error: Connection reset by peer]
<rellla>
except the difference of two separate instructions of course
<rellla>
i think i will also do a mr for it and see what others think about it
<rellla>
i addition i added a PIPE_CAP in order to skip nir_lower_wpos_ytransform fot fddy and gl_FragCoord, as i couldn't see offline compiler doing it
<rellla>
iirc it also doesn't make piglit tests fail...
<rellla>
sry for the typos btw
<anarsoul>
rellla: something else could be different
<rellla>
i think, i have to check first, if the blob passes the test and then check whats the difference
<rellla>
...running piglit with control-flow branch now ...
jrmuizel has quit [Remote host closed the connection]
<anarsoul>
rellla: I wonder how many regressions are there :)
jrmuizel has joined #lima
jrmuizel has quit [Remote host closed the connection]
jrmuizel has joined #lima
<anarsoul>
enunes: rellla: I guess we need to introduce a control-flow-aware helper that adds movs properly
<anarsoul>
we're adding movs in several places and currently it's a mess
<enunes>
anarsoul: I'm a bit out of the loop, what is the awareness required in movs?
<anarsoul>
enunes: we don't add deps for a node if they're in different blocks
<anarsoul>
it's totally fine since they will be evaluated in correct order anyway
<enunes>
not only movs then, but all nodes that we create while lowering?
<anarsoul>
yeah
<anarsoul>
but I believe they're mostly movs
<anarsoul>
constants are fine, we can just clone them. They're free anyway (up to 2 vec4 consts for any instruction)
<enunes>
so it is not enough if the branch/jump node has a dep to the next block?
<anarsoul>
see lower_select()
<anarsoul>
ppir_lower_select()
<anarsoul>
ppir_node_foreach_pred {} will do nothing if select condition is in another block
<anarsoul>
and then it'll hit assert
<anarsoul>
enunes: it's not really about branches
<anarsoul>
ssa can be defined in 1st block but used in 2nd
<anarsoul>
ppir_node_add_dep() doesn't add any deps if pred and succ are from different blocks
<enunes>
I wonder why, I see the condition in ppir_node_add_dep but why can't we just have deps between the different blocks?
<anarsoul>
enunes: because block ordering guarantees that it will be evaluated before it's used
<anarsoul>
also if you add inter-block deps compiler doesn't respect block boundaries and branch targets become invalid
<anarsoul>
especially if there are any nir registers involved