03:28 robclark: karolherbst: re modifier information, drivers already need a back-door for that for equiv vk<->gl extension
03:30 robclark: see MSM_INFO_GET_METADATA/MSM_INFO_SET_METADATA.. and and I think intel should have something similar
03:34 robclark: *amd and
04:37 soreau: it seems mixing highp and mediump is a bad idea or broken in mesa for some gpu's.. specifically, using highp for uv attributes and mediump for floats is a recipe for all kinds of strange oddities in the output
04:39 soreau: but the outcome was as expected on RX cards, currently the issue surfaced on 'raphael_mendocino' gpu
08:44 mareko: zmike: sample 0 for GL
08:44 mareko: zmike: on any random sample
08:44 mareko: *or
08:45 mareko: soreau: mediump float is FP16, which has terrible range
08:46 mareko: it can't even represent integer numbers after 2048
08:49 mareko: between 1024 and 2047, it can only represent integer numbers, so no fractional part
08:51 mareko: it's not very usable for numbers greater than 16 or less than -16
12:08 arnd: robclark: I get "drivers/gpu/drm/msm/msm_gem.c:106:54: error: invalid use of undefined type 'struct msm_kms'" on linux-next today, is that a known issue? I couldn't immediately come up with a good fix
12:24 robclark: arnd: hmm, maybe from a combo of the VM_BIND series vs CONFIG_DRM_MSM_KMS.. enabling CONFIG_DRM_MSM_KMS would "fix" it
12:29 arnd: robclark: sure, I could just move the "select CONFIG_DRM_MSM_KMS" from the various specific symbols into CONFIG_DRM_MSM, but my impression was that this is not the intention
12:30 arnd: right now, we select KMS from MDP4, MDP5, DPU, DP, DSI and HDMI, so the error happens in randconfig builds where all of those are turned off
12:31 robclark: yeah, no the fix is some additional `#ifdef CONFIG_DRM_MSM_KMS`.. I'll look at that later this AM
12:31 arnd: ok, thanks
12:31 robclark: just pointing out a w/a (and why I didn't see that)
12:51 zmike: mareko: that explains a lot, thanks
13:18 sima: tzimmermann, fyi https://lore.kernel.org/dri-devel/CAH2r5msRuE91Udov3eaFB=7x-8petRYY2wM_PRD2LSmBMhVCqA@mail.gmail.com/
13:19 tzimmermann: sima, i've meanwhile merged the fix into -misc-fixes
13:20 tzimmermann: so no more bug reports
13:20 sima: tzimmermann, yeah just figured if you haven't yet could add that
13:48 soreau: mareko: ok, thanks
14:09 robclark: arnd: sent some more ifdef for ya
17:02 zzyiwei: robclark: Hi Robin ^o^, wonder if you can take a quick look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35875. Only missing turnip and lavapipe votes now. Thanks!
18:40 Lynne: just to check, supposing I don't use subgroups, gl_LocalInvocationID.x should be identical to gl_LocalInvocationID.z if I rename every occurence and change the local size, right?
18:40 Lynne: I'm seeing breakage if I swap them, and at this point I'm thinking it could be the shader compiler
18:41 pendingchaos: that would change the value of gl_LocalInvocationIndex
18:49 Lynne: I don't use it
18:51 Lynne: what's weird is that lavapipe works, but both intel and nvidia are broken
19:05 zzyiwei: robclark: just a tiny thing. Your email in bin/people.csv _seems_ to be out of date. I've been using bin/rb.py (thx to Alyssa) a lot these days and just noticed that.
19:10 alyssa: i should probably document that thing more
19:10 alyssa: but happy to hear people other than me use it :>
19:10 alyssa: i have `urb` defined as `rb -r upstream/main $*`
19:11 alyssa: which means i'll just type like `urb jesse mel samuel` and that's it, tags for the whole series applied :}
19:12 zzyiwei: Good to learn that, thanks again!
19:12 robclark: til about people.csv
19:12 alyssa: tbf we added -r later
19:12 alyssa: robclark: yeah this is my fault sorry/not sorry
19:13 robclark: zzyiwei: the fd.o email addr still works
19:13 zzyiwei: Got it ^^
19:17 Sachiel: ohh, I had missed the -r
19:18 alyssa: Sachiel: I really gotta be better at writing docs >.>
19:18 alyssa: I just assume everyone reads every MR in Mesa like a hawk
19:31 Sachiel: I 'git log ..upstream/mesa' to start evey working day
19:37 jenatali: I really can't tell if that's sarcasm
19:37 Sachiel: heh, it's not
19:40 idr: I think people.csv (also.. TIL) has the non-preferred email for mattst88 too.
19:41 idr: At least I've never seen that address in a Rb. :shrugh:
19:49 Lynne: figured out the issue
19:50 Lynne: for some reason, out float array[64]'s writes kinda got lost, if I used inout, most of the time the writes made it through
19:51 Lynne: any combination of volatile/coherent made no difference. removing arguments and hardcoding the array names in the function works perfectly
19:51 Lynne: classic glsl
19:53 mattst88: idr: oh, oops. I didn't know about people.csv, nor that my @google account was listed in it. I also didn't realize that I'd committed patches under that address...
19:54 mattst88: I'll make an MR to correct that
20:06 alyssa: jenatali: I read gitlab MRs as opposed to git log but yes
20:06 jenatali: I used to do that too. Haven't been following closely recently though