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