16:15 Company: I just bisected a new GTK testsuite failure down to this commit: https://gitlab.freedesktop.org/mesa/mesa/-/commit/7f2130c86e17f936be66fa6ad8eda85746b5fc6b
16:15 Company: do I now assume this is likely GTK's shadercode doing something undefined and try to debug that?
16:15 Company: or do I assume that commit has a problem and try to learn enough nir to debug that?
16:21 Company: the GTK bug is that this shader: https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gsk/gpu/shaders/gskgputurbulence.glsl should produce the image at https://gitlab.gnome.org/GNOME/gtk/-/blob/main/testsuite/gsk/compare/turbulence-transformed.png but produces https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/10193#note_2832543
16:22 Company: which is exactly at the repeat boundaries where x - floor(x) and such happen and might result in 0.0 or 1.0 or sth like that
16:25 Ristovski: Company: what hardware?
16:27 Company: Ristovski: llvmpipe
16:27 Company: well, lavapipe
16:27 Company: though I get some artifacts if I run the test with Intel, too
16:32 Ristovski: hm no clue, but lavapipe has LP_DEBUG=fs for dumping the frag shader, might be worth A/B-ing with/without that commit etc
16:41 Company: https://paste.centos.org/view/4f195676
16:42 Company: so what the shader does is:
16:42 Company: x = x + 4096;
16:42 Company: x = fract(x);
16:43 Company: and the addition is to get rid of floating point rounding errors by doing the addition
16:43 Company: ie 0.000000000000001 + 4096 would be 4096
16:44 Company: and the optimization detects that the addition should modify the fractional part so it optimizes it away
16:44 Company: and then the shader gets 0.000000000000001 instead of 0
16:45 Company: now I still have no idea who's fault that is
16:49 karolherbst: Company: you could try to pinpoint which of the rules is doing that
16:50 karolherbst: Company: ohhh.. you might have to declare the part as precise...
16:51 karolherbst: https://wikis.khronos.org/opengl/Type_Qualifier_(GLSL)#Precise_qualifiers
16:51 Company: I wonder if it should just use a better method
16:52 karolherbst: maybe
16:52 Company: adding 4096 to get rid of floating point accuracy seems dodgy
16:53 karolherbst: but yeah.. the optimiation _improves_ precision and therefore it's legal if contraction is allowed
16:53 Company: this code looks copy/pasted from https://drafts.csswg.org/filter-effects/#feTurbulenceElement
16:54 karolherbst: if you rely on computations being done 1:1 how it's in the code, you'll have to declare it as precise for now or figure out a better way of doing that :)
16:55 Company: I wonder if more shaders run into this
16:55 karolherbst: "nextafter(4096.0, +inf) - 4096.0" would give you the floating point precision around 4096.0, and you could compare the initial value with it to see if ti would be rounded away or not
16:55 Company: the one place I know: https://github.com/WebKit/WebKit/blob/9ff899b9b2f4121ebf7e7f5b376e5ad8dab21574/Source/WebCore/platform/graphics/coreimage/FETurbulenceCoreImageApplier.mm#L145 is doing the exact same thing
16:56 karolherbst: well that uses floor
16:57 karolherbst: so it shouldn't run into the issue
16:57 Company: line 151
16:57 karolherbst: or maybe it could...
16:57 Company: does a position - floor(position) essentially
16:58 Company: our shader doesn't use fract() either - because it's ported straight from that example code and C has no fract()
16:58 Company: but nir is smart enough to optimize that
16:58 karolherbst: ahh
16:59 karolherbst: well you have to expect that the shader can improve precision of any operation at any time unless contraction is disabled
16:59 Company: right - so it's something that I need to fix
16:59 Company: and probably the SVG spec, too
16:59 karolherbst: yeah.. just throw in a "precise" on the variable or something
16:59 Company: and maybe Firefox, Servo, Chrome, and Webkit, too ;)
17:00 karolherbst: precise marks the entire expression assigning to the variable on the rhs as "precise"
17:00 karolherbst: yeah... worst case we'll have to disable that optimiation for certain applications
17:00 karolherbst: *optimization
17:01 Company: meh, precise is GL 4
17:02 karolherbst: or ARB_gpu_shader5
17:02 Company: right - and I suppose the other ones can live with the bug
17:02 karolherbst: many 2.x, and 3.x advertise that one
17:02 karolherbst: *devices
17:03 Company: does GLES 3 have prcise?
17:04 karolherbst: no idea :)
17:06 Company: https://paste.centos.org/view/f49cb646 does fix GTK's shader
17:07 karolherbst: rough :)
17:08 Company: only with Vulkan though, not with GLES
17:09 Company: and with GL
17:09 karolherbst: I guess gles ignores the modiifer
17:09 Company: that was my guess there, too
17:10 karolherbst: I do think you can do an algo with nextafter, but that's kinda slow
17:10 Company: I think I will just do x = round (4096 * x) / 4096;
17:10 karolherbst: uhh not sure if gl/gles have nextafter...
17:10 karolherbst: I guess not