02:22 airlied: jeez INT_MIN / -1 -> SIGFPE, who knew!
02:22 airlied: blender fixed on llvmpipe at least
02:27 HdkR: airlied: Got to love the `Quotient was too large for the designated register.` problem? :)
02:38 airlied: HdkR: yup, had never come across it before
02:38 airlied: I just assumed something was optimising out the div by zero checks
02:43 HdkR: It's not a common problem to have
03:44 imirkin: anholt: btw, there's some CTS test which really hammers texturing too
03:44 imirkin: it picked up that nv50 apparently has a bug with srgb decoding + texture swizzles
03:45 imirkin: (or nouveau has a bug, but figuring out precisely what's wrong is a pain, so i prefer to think that the hw has a bug, since it doesn't happen on nvc0)
03:46 imirkin: anholt: KHR-GL33.texture_swizzle.functional
04:17 sumits: danvet: so what's the disappointment?
04:17 sumits: danvet: sorry, getting back to work after a bit longish illness, so catching up
04:27 airlied: sumits: I think it was something ot do with dma-buf and gem bo naming not inheriting from each other
04:32 sumits: airlied: ok; in that case, we'd need to update the gem bo code, since dma-buf is an independent framework and doesn't inherit anything from anywhere else?
04:32 sumits: airlied, but yes, I think it'd be better if they were connected clearly
04:33 sumits: airlied, thanks for the clarification :)
05:22 anarsoul: jekstrand: what is "extra dangling SSA sources"?
08:10 MrCooper: tomeu: looks like vertex_attrib_4f is flaky as well on lima: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/1730473
08:13 anarsoul: rellla: ^^
08:16 rellla: MrCooper: tbh, i wondered why exactly this one wasn't a flake :( i will do a MR the next mins
08:19 MrCooper: thanks
08:21 rellla: done. give me arb and i'll merge it :)
08:22 MrCooper: I'll take a look when I get a chance
08:26 rellla: nevermind, got one from anarsoul
08:41 rellla: wtf
08:51 ccr: ls
10:07 Zeising: Hi! I have questions about some egl/glx stuff in mesa, who should I ask?
10:09 MrCooper: just ask your questions
10:10 Zeising: I'm poking around regarding https://bugs.freedesktop.org/show_bug.cgi?id=100627, we have local patches that basically disable dri3 by default, but I'm not sure why, because we should just fall back to dri2 if dri3 init fails, but that issue seem to indicate that's not the case.
10:11 Zeising: And I'm honestly unsure where to start looking.
10:22 danvet: j4ni, pinchartl support for the drm hotunplug model in "[PATCH 03/51] drm: add managed resources tied to drm_device" would be useful I think
10:23 danvet: Lyude, ^^ maybe you too, it's kinda like connector hotunplug, but cranked to 11
10:26 MrCooper: xexaxo1: you seemed to know what's up with Zeising's bug above?
11:25 imirkin: jasuarez: re https://cgit.freedesktop.org/mesa/mesa/commit/?id=784c454607be3e8dc395de429d9b99521d5ef8a8 ... have a look at https://github.com/KhronosGroup/VK-GL-CTS/issues/51 -- i got them to change it a while back
11:25 gitbot: KhronosGroup issue 51 in VK-GL-CTS "KHR-GL44.gpu_shader_fp64.built_in_functions tests for overzealous mod requirements" [Opengl, Bug, Closed]
11:49 imirkin_: and maybe mattst88, jekstrand --^ since iirc we spoke about this? recollection is hazy though
11:50 imirkin_: tpalli: i don't think https://cgit.freedesktop.org/mesa/mesa/commit/?id=de4eb9a3bb9fb073a5bf5cc157918bfa0f62b394 works the way you think it works
11:51 imirkin_: tpalli: this will enable EXT_texture_norm16 if it's *either* texturable *or* renderable
11:51 imirkin_: whereas i think you want if it's *both*
11:55 tpalli: imirkin_ ok, yeah it is both that is wanted
11:57 imirkin_: tpalli: what ES 3.1 driver doesn't support norm16 btw?
11:58 tpalli: imirkin_ v3d
11:58 imirkin_: ahhh
11:58 imirkin_: really? that's very sad.
11:58 imirkin_: i.e. there's really no hw support for 16-bit norm textures?
11:58 imirkin_: or just not exposed in mesa?
11:59 tpalli: that one I'm not sure of, but tests fail
11:59 imirkin_: hehe
11:59 imirkin_: would be worth checking briefly, imho
11:59 imirkin_: i have no clue where the docs are though
11:59 imirkin_: (and have to jump on a call, so can't look now)
11:59 tpalli: well, I think my change should be there anyway .. just need to modify it to check for both
12:31 imirkin_: tpalli: no objections to the check
12:32 imirkin_: but also nice to provide additional functionality if it's as simple as adding a few enums to a table
12:32 imirkin_: but perhaps it's not
12:33 tpalli: yeah I think I need something custom here, perhaps call init_format_extensions twice with own list of formats and make sure both toggle it on
12:34 imirkin_: yeah, you have to add a new "table" which checks both BIND flags, or just do something wholly custom
12:34 imirkin_: [or so goes my fading recollection]
12:35 tpalli: funnily this drops extension support from iris .. seems to not support texturing from PIPE_FORMAT_R16G16B16_[U|S]NORM
12:36 imirkin_: that should not be required
12:36 imirkin_: that means it drops the ext everywhere ... no one supports RGB formats
12:37 imirkin_: fwiw, it's the _rare_ impl that can render to a format it can't sample from
12:37 imirkin_: so perhaps just take it out of the texturing table and be done with it?
12:41 tpalli: agreed
12:41 dj-death: heh
12:42 dj-death: tpalli: back to the first version :)
12:43 tpalli: dj-death :)
12:43 imirkin_: just make sure to not require the RGB variant, since that one's not actually supported by anyone
12:43 imirkin_: really you only need to require RGBA16
12:44 imirkin_: since the others will get auto-upgraded to it iirc... double-check the tables in st_format
12:45 tpalli: hmm ok, I'll send patch soon so we can discuss there
12:45 imirkin_:doesn't do gitlab
12:45 imirkin_: but perhaps someone else will review it there
12:45 tpalli: ok fair enough
13:07 imirkin_: tpalli: can't seem to trackdown the vc5 docs ... any good search strings for google? or are the docs not open?
13:39 tomeu: daniels: wonder how much could help to give higher priority to pipelines associated to MRs, opposed to personal branches
13:39 tomeu: and maybe to Marge's jobs
14:00 apinheiro: imirkin_, : <imirkin_> i.e. there's really no hw support for 16-bit norm textures?
14:00 apinheiro: afaik yes
14:01 imirkin_: boo!
14:01 apinheiro: and they should be renderable and
14:01 apinheiro: hmm
14:01 apinheiro: "texturable"?
14:01 apinheiro: in any case, I think that it is supported, but it is not implemented
14:01 imirkin_: oh, so there is support in the hw
14:01 imirkin_: just not in the software
14:01 apinheiro: anholt implied that it could have been added since then
14:02 apinheiro: but it not
14:02 daniels: tomeu: it would be nice but there's no good way to influence the scheduler atm
14:02 apinheiro: so as tpalli mentioned before
14:02 apinheiro: with v3d those formats
14:03 apinheiro: are supported for texturing not for render-target rendering
14:03 apinheiro: no idea how much is missing to get everything, but it is not a priority right now
14:03 apinheiro: so right now just not exposing the extension for this case would be enough
14:04 apinheiro: never though it would have been so messy, sorry for that
14:04 imirkin_: apinheiro: no objection to making the ext conditional
14:05 imirkin_: i was just curious (a) who needed it (v3d) and (b) if it could be supported (sounds like yes)
15:32 jekstrand: anarsoul: Context?
15:33 jekstrand: imirkin_: I have no recollection of that
15:34 imirkin_: ok. we've had a few compiler discussions over the years, so i couldn't quite remember who i've spoken to about it :)
15:43 jekstrand: imirkin_: Fair. :-)
18:14 Lyude: danvet: I'll take a look tomorrow when I'm back from PTO
18:17 anarsoul: jekstrand: nevermind, I already figured it out, it was a bug in lima_nir_split_loads pass (not merged yet), I just dropped it for now
19:38 danvet: jekstrand, just realized we need to do the same for shared fences
19:38 danvet: if there's an exclusive fence present
19:38 danvet: i.e. make a fence array with the exclusive fence and the one you just added
19:38 danvet: and set that as the shared
19:39 danvet: I think (but not sure) we only need to do that on the first shared fence
19:39 danvet: but not doing it for latter ones is kinda evil and shouldn't really break us
21:44 anarsoul: any ideas why lima may end up in glamor_put_image_bail() and thus in fbPutImage() in x11perf?
21:50 ajax: anarsoul: which part of x11perf?
21:52 anarsoul: ShmPutImage 500x500
21:56 ajax: not like with GXxor or -pm something?
21:58 ajax: ooh, and: you're doing this on a bare X server with no compositor, right?
21:59 anarsoul: yes
22:00 anarsoul: ajax: if there's nothing obvious I guess I'll have to debug it :)
22:00 ajax: then my wild guess is that it's the call to GLAMOR_PIXMAP_PRIV_HAS_FBO in glamor_put_image_gl_failing
22:00 ajax: where the pixmap in question is the root window pixmap
22:01 ajax: whose ->gl_fbo maybe != GLAMOR_FBO_NORMAL
22:02 anarsoul: ajax: so should I try with compositor?
22:05 ajax: sure. it'd validate the hypothesis i think.
22:08 ajax: what are you trying to measure/fix/etc?
22:12 anarsoul: ajax: checking whether similar fix can be done for lima: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3818
22:18 ajax: then yeah i think turning on compositing will get you onto the non-fbPutImage path
22:19 ajax: you might also want to not hit the fbPutImage path by figuring out how to make glamor handle the root window pixmap case
22:34 gtucker: there was a network problem in the Collabora LAVA lab causing some jobs to be aborted in Gitlab CI pipeline 113101 (mesa master branch I believe)
23:12 anholt_: gtucker: thanks for the heads up -- I see those reports and it's good to know that the failures are understood