00:22 <anarsoul> enunes: IIRC we have a flag to force spilling

00:24 <anarsoul> just use a simple shader like: https://gist.github.com/anarsoul/b4105755ab31022aa7701c567363debc

00:24 <anarsoul> and force spilling

00:25 <anarsoul> and then change size of color

08:13 <rellla> cwabbott: with https://freenode.irclog.whitequark.org/lima/2019-08-27#25233224; you mean that we better should look into nir_opt_undef and walk through the instructions to lower things like

08:16 <rellla> ssa0 = undefined; ssa1 = feq(ssa0, 1.0); ssa2 = bcsel(ssa1, ssa3, ssa4) to

08:16 <rellla> ssa2 = ssa4 ?

08:19 <cwabbott> rellla: yes, there's already a nir_opt_undef for things like this but it's kinda incomplete unfortunately

08:21 <rellla> that's why i asked. i tried to lower that special instr set above, but i've noticed that i first have to learn nir a bit better :)

08:23 <rellla> imho lowering undef to 0.0 is wrong and can have side effects. for example if the above is changed to "ssa1 = feq(ssa0, 0.0)" it's simply wrong ...

08:45 <cwabbott> no, it's not wrong

08:46 <cwabbott> it would lower that to "ssa1 = feq(0.0, 1.0)"

09:04 <rellla> cwabbott: i mean, if the above would be : "ssa0 = undefined; ssa1 = feq(ssa0, 0.0); ssa2 = bcsel(ssa1, ssa3, ssa4)" it would be wrong, if undef is lowered to 0.0 and there is a comparision with 0.0 afterwards

09:06 <cwabbott> again, no it wouldn't

09:07 <cwabbott> we can return whatever we want for undef, and if it's read multiple times we can return a different result each time

09:11 <rellla> hm, not sure if we talk past each other :p

09:12 <rellla> otherwise i simply don't understand it :)

09:15 <rellla> if we take alyssas approach and lower all undefs to const 0.0 -> suppose i have sth like "ssa0 = undefined; ssa1 = feq(ssa0, 0.0);" -> after const lowering we have "ssa0 = const 0.0; ssa1 = feq(ssa0, 0.0);"

09:16 <rellla> so in my understanding, we get 2 different results in the end - for the case with just keeping the undef and for the case lowering it to const 0.0

09:16 <rellla> but i could be wrong for sure

09:24 <cwabbott> with undef, we're allowed to assume that it returns whatever we want

09:24 <cwabbott> i.e. we're allowed to produce whatever result we want

09:24 <cwabbott> exactly as if you have an uninitialized value in C

09:29 <rellla> i think i move on to understand. the term "lowering undef to 0.0" isn't wrong, because we are allowed to do that. so the approach per se isn't wrong at all.

09:36 <rellla> then it's just a matter to handle the things in a right order. meaning, first lower down the instructions which are affected by the undef within nir and then handle the remaining ones later - in case they have not been sorted out before.

09:37 <rellla> i wonder, if undefs are worth the effort at all :)

13:25 <rellla> yeah, have added my first case with feq/bcsel undefs added to nir_opt_undef and it works :)

13:25 <rellla> need to cleanup and think about how i should do that without breaking anything :p