00:09 dschuermann: o_O do you have a link?
03:19 agd5f: dschuermann, https://llvm.org/docs/AMDGPUUsage.html#call-convention
13:14 pq: Why do EGL_*_gl_colorspace_* extensions exist? They sound like just pass-through to the window system, why not just let apps use window system specific API to set those properties?
13:26 danvet_: tzimmermann, https://patchwork.freedesktop.org/patch/391291/?series=81852&rev=1 review favour return on this very much appreciated, I'd like to settle this
13:26 danvet_: agd5f, j4ni vivijim dolphin https://patchwork.freedesktop.org/patch/391291/?series=81852&rev=1 <- ack for merging this through drm-misc?
13:30 agd5f: danvet_, Acked
13:30 danvet_: agd5f, thx
13:31 danvet_: mripard, btw last 5.10 pull or can I still squeeze this in?
13:35 mripard: danvet_: Linus said there will be an -rc8
13:35 mripard: so we have one more week left?
13:39 mripard: https://lore.kernel.org/lkml/CAHk-=wh+qz0oOjyiQFXR_73RYSDUmJwHC8xd=KG0RzELnbS5OA@mail.gmail.com/T/#u
13:39 mripard: (so, actually not really announced, but it definitely seems we're headed that way)
13:42 danvet_: mripard, where did you find this?
13:42 danvet_: gup lolz is very relevant, but also I much prefer summaries for an idiot like me :-)
13:43 mripard: I set up an ML machine that analyses every mail on LKML to just show me the relevant ones :)
13:44 mripard: (for real, I just follow Thorsten on twitter, and he probably does that)
13:44 mripard: or he just reads every mail, I don't know how he does it
14:26 tzimmermann: danvet_, done
14:28 danvet_: tzimmermann, thx
14:28 tzimmermann: sure. nice to see this resolved
14:29 danvet_: yeah hopefully rsn we can also land the drmm_ helpers for all the kms things that imx is working on
14:29 dcz: for the lack of a better place to ask... cos(float) > 1 in a shader is a bug, right?
14:54 Kayden: dcz: Yeah, that's not allowed, and prohibited by the modern GL CTS
14:54 Kayden: dcz: let me guess, you're hitting this on Intel, on HW older than Kabylake...
15:02 ajax: *coughs violently*
15:02 ajax: that's not the sort of invariant you really want to violate
15:03 MrCooper: congratulations, you just broke the universe
15:03 dcz: Kayden: correct, and correct
15:03 dcz: where do I file bugs? where do I fix bugs?
15:03 dcz: it's Ivy Bridge btw
15:03 Kayden: INTEL_PRECISE_TRIG=1 will prevent that :/
15:04 dcz: works like magic
15:04 Kayden: the hardware's sin/cos instructions have a weird discontinuity at very particular values
15:04 Kayden: where it blips slightly over 1.0
15:06 Kayden: that environment variable unfortunately just multiplies the result by 0.99997 :/
15:06 Kayden: that is, if I recall, the workaround used in the other drivers as well
15:06 Kayden: it got fixed on kabylake HW
15:07 dcz: oh, so I might actually want to use a software sin() if I care about precision
15:09 ajax: Kayden: jebus
15:09 ajax: who writes hardware like that
15:10 imirkin: Kayden: INTEL_PRECISE_TRIG is a bit of a misnomer, no?
15:10 Kayden: ah, sorry, the windows driver apparently is/was doing ternaries to clamp to 1.0 near there
15:11 jekstrand: dcz: If you really care about precision, built-in sin/cos have basically no precision guarantees.
15:11 Kayden: was. eventually they moved to * 0.99997
15:12 imirkin: more like INTEL_NOT_AS_OBVIOUSLY_WRONG_TRIG?
15:12 Kayden: it's apparently 0.08296 .. 0.09888 that blips over 1.0
15:12 dcz: I did notice the spec not saying anything about precision, but I didn't expect people would take advantage of it
15:12 Kayden: for cos
15:14 Kayden: also, sin/cos will go completely haywire beyond -32767*pi, 32767*pi for inputs
15:14 Kayden: like complete and total garbage
15:15 Kayden: due to fixed point math being used for some calculations internally
15:16 ajax: why would you compute sincos in anything other than a unorm and promote to float at the end
15:18 jekstrand: We really should just smack precise trig on all the time
15:18 jekstrand: I doubt that mul matters to anyone's perf
15:18 Kayden: probably so at this point
15:19 Kayden: now that I don't have people trying to can the entire mesa effort based on benchmark numbers
15:19 jekstrand: Does it affect benchmark numbers?
15:19 Kayden: it did
15:19 Kayden: I don't think it was large
15:22 vsyrjala: if (benchmark_detected) no_precise_trig :)
15:23 imirkin: just render black - should get your numbers up in no time
15:24 Kayden: imirkin: we were pretty sure that was happening in some comparisons back in the day
15:24 imirkin: hehe
15:27 imirkin: i doubt nouveau could render black as fast as nvidia blob renders the regular scene...
15:27 jekstrand: :-(
15:27 imirkin: (clock speeds matter)
15:31 dschuermann: can someone confirm if (('ishl', ('pack_half_2x16', ('vec2', a, 0)), 16), ('pack_half_2x16', ('vec2', 0, a))), is completely wrong?
15:35 jekstrand: dschuermann: Yup. ishl sign-extends.
15:35 jekstrand: Oh, wait, left.
15:36 dschuermann: o_O jekstrand it's the wrong direction
15:36 jekstrand: You want ushr
15:36 jekstrand: That would be right, I think.
15:36 dschuermann: yeah, I think the two opts are reversed
15:37 jekstrand: What you have above is right if you s/ishl/ushr
15:37 jekstrand: If you want the ishl version, your vectors are backwards
15:37 jekstrand: Or not...
15:37 jekstrand: No, actually, I think what you have there is fine
15:37 jekstrand: packing is always little-endian
15:38 jekstrand: This is why we really need unit tests for opt_algebraic
15:38 jekstrand: A bit of constant folding would trivially verify it for us
15:39 dschuermann: wait, that would mean we pack our vectors wrong °°
15:40 jekstrand: Yeah, .x goes in the low bits and .y in the high bits
15:40 dschuermann: ah or not. that is really confusing :)
15:41 dschuermann: ok, but we can replace the 0 by some arbitrary input as it gets shifted out anyway
15:42 jekstrand: Yes, the rule above should work for (a, b) as the input and you should get (0, a) as the output
15:42 dschuermann: ok, thx. I'll test if it changes anything
15:54 dschuermann: doesn't do anything. I doubt these opts are hit at all
15:54 jekstrand: Could be
15:56 pendingchaos: dschuermann: I think that opt was made for some battlefront 2 shaders
15:56 dschuermann: ah ok
15:57 dschuermann: there is really odd things with half packing. I also found unpack_half_2x16_split_x(ushr, a, 16)
19:06 anholt: jstultz: do you have any tricks for swapping out the graphics drivers in an android image without reflashing everything?
19:16 jstultz: anholt: so adb remount; adb sync; should do it but we are chasing an issue on db845 that broke it.
19:16 jstultz: I tend to do full flashing. :(
19:17 anholt: W Disabling verity for /vendor
19:17 anholt: E Skipping /endor
19:17 anholt: W Disabling verity for /product
19:17 anholt: E Skipping /product
19:17 anholt: W No partitions to remount
19:18 jstultz: Looks similar. :/
19:22 anholt: oh. adb reboot after the verity disables then try again
19:27 anholt: and there we go. vulkan driver is now getting loaded without LD_PRELOAD hacks.