02:14 daniels: anarsoul: should be fixed now, thanks
02:17 anarsoul: daniels: thanks!
02:54 airlied: daniels: some of the arm builders seem out of disk space
02:54 airlied: https://gitlab.freedesktop.org/airlied/mesa/-/jobs/1711177
03:00 daniels: grr, why is it only now they're acting up ...
03:01 daniels: maybe try a bit, there's cronjobs to clean the cache
03:01 daniels: I won't be able to look at it till the nothing
03:01 daniels: *morning
03:02 airlied: daniels: that's like the 2nd or 3rd failure in the past 4-5 hour
03:02 airlied: but I'll kick some more off later
03:03 imirkin: i remember someone complaining about arm builders earlier too
03:03 imirkin: yeah, 9h ago, anarsoul mentioned something
03:03 daniels: right, and they were offline until I brought them back an hour or two ago
03:04 imirkin: oh ok. oh, and i see you even mentioned that an hour ago. didn't read enough scrollback, sorry
03:27 daniels: heh np
09:58 MrCooper: azubieta: do you mean glibc? Mesa doesn't link against glib, and I'd be surprised if the nvidia driver did
10:44 bbrezillon: pinchartl: ping on "drm: Add support for bus-format negotiation" v10, patches 8-10
11:33 pinchartl: bbrezillon: I'll try to look at it in the next few days
11:33 bbrezillon: pinchartl: thx
13:18 tomeu: robher: now we'll know it if you break panfrost: https://kernelci.org/test/board/rk3399-gru-kevin/job/mainline/kernel/v5.6-rc2-55-gca7e1fd1026c/
13:29 robher: tomeu: Cool! It's when, not if.
15:16 MrCooper: hmm, none of the LAVA (panfrost) jobs of https://gitlab.freedesktop.org/idas/mesa/pipelines/111995 are getting picked up
15:23 tomeu: daniels: any ideas?
15:23 daniels: working on it
15:25 daniels: there we go
15:26 MrCooper: thanks!
15:26 MrCooper: what was the issue?
15:26 MrCooper: (out of curiosity)
15:47 daniels: MrCooper: for some reason packet-2 had got really unhappy with KVM so I restarted it for bentiss. that didn't work so I gave it a harder power-off/power-on cycle. ben's been trying to work out why KVM just stops working sometimes and hangs when you start new VMs.
15:48 MrCooper: so the LAVA gitlab runners run on packet-2?
15:49 daniels: MrCooper: yep
15:57 MrCooper: good to know
17:24 imirkin_: is NV_copy_image a strict subset of ARB_copy_image?
17:35 Sesse: imirkin_: the ARB_copy_image extension text says no
17:35 Sesse: 8) How is this extension different from NV_copy_image?
17:35 Sesse: RESOLVED: This extension does not include the WGL/GLX windowing-
17:35 Sesse: layer copy functions. This extension adds the ability to copy
17:35 Sesse: between images which have different formats where the formats
17:35 Sesse: are compatible for texture views. This extension adds the ability
17:35 Sesse: to copy between uncompressed and compressed images if the texel
17:35 Sesse: and block sizes are the same.
17:36 imirkin_: right, except the WGL/GLX bits
17:36 imirkin_: which nobody gives a .... about
17:36 Sesse: :-)
17:37 imirkin_: but i understand the rest of that to mean that ARB_copy_image adds things NV_copy_image doesn't have
17:37 imirkin_: without removing any
17:37 Sesse: imirkin_: I believe so, but I don't know them in detail
17:37 imirkin_: k
17:37 Sesse: the former is definitely based on the latter
17:38 kherbst: imirkin_: any reason to care about NV_copy_image?
17:40 imirkin_: karolherbst: it just got added to mesa
17:40 karolherbst: ohh, I see
17:40 imirkin_: wasn't too clear on why, or why a separate cap bit was added
19:53 mareko: imirkin_: what cap bit?
19:53 imirkin_: mareko: NV_copy_image
19:54 imirkin_: instead of just making it dependent on ARB_copy_image
19:54 mareko: there is no cap bit
19:55 imirkin_: mareko: https://cgit.freedesktop.org/mesa/mesa/diff/src/mesa/main/mtypes.h?id=18124d727865f1c53b0dac644560bce177b7d233
19:56 mareko: oh extension bit
19:57 mareko: because it's a subset of NV_copy_image
19:57 mareko: I mean ARB_copy_image
21:38 imirkin_: mareko: ok... seems a bit redundant but wtvr
23:03 imirkin_: mareko: would you be interested in supporting the non-ieee fp alu mode in radeonsi?
23:05 karolherbst: imirkin_: for what is that useful?
23:05 imirkin_: dx9
23:06 linkmauve: So Nine?
23:06 karolherbst: now that we have dx9 on vulkan.. nouveau is probably the only driver benefiting from nine
23:06 karolherbst: ohh, and r600
23:06 imirkin_: linkmauve: nine already uses it via the TGSI property MUL_ZERO_WINS
23:07 imirkin_: i'm hoping a GL ext can be made to enable wine to use it via the wined3d path as well
23:07 linkmauve: karolherbst, iris too?
23:07 karolherbst: linkmauve: they have anv
23:07 karolherbst: but oh well
23:07 imirkin_: i don't think vulkan presents such an hw option
23:07 karolherbst: I think all hw iris supports area also supported by anv
23:07 imirkin_: at least not without additional extensions
23:08 linkmauve: Yes, but is it better to use anv for this usecase?
23:08 karolherbst: dunno, it's easier to deploy
23:08 linkmauve: IIRC it was just a checkbox to check in a wine program to deploy Nine.
23:09 karolherbst: although nine already improved on that and you just need to replace your d3d or something
23:09 linkmauve: I haven’t tested dx9 yet.
23:09 karolherbst: linkmauve: it required a patched wine
23:09 karolherbst: but now it's kin of weir
23:09 karolherbst: d
23:09 linkmauve: Ah, not since I tested it.
23:09 linkmauve: Or if it did, it did it in the back without me having to do anything.
23:09 karolherbst: I am sure you had to install a patched wine
23:09 karolherbst: even if your distribution patched it for you
23:10 karolherbst: imirkin_: actually yes.. interesting to know how dxvk handles all of that now
23:13 linkmauve: Ah maybe, I have both wine and wine-nine installed from ArchLinux, the latter containing said program with a checkbox as well as an i686 and an amd64 version of its dll.
23:13 karolherbst: imirkin_: ohh, I think I actually spoke to somebody at fosdem about this and the plan was to whitelist application where it actually matters and the best approach would be to write a mesa ext to fix this for rela
23:14 linkmauve: /usr/lib/wine/fakedlls/d3d9-nine.dll and /usr/lib/wine/d3d9-nine.dll.so
23:14 linkmauve: Nothing else looks patched in wine.
23:14 karolherbst: yeah... still something which need to be done
23:19 imirkin_: it seems like this ext keeps getting killed, which is unfortunate
23:19 imirkin_: because it's always "well, you could do this other thing"
23:19 imirkin_: but i see it as pretty simple... hardware has some functionality, this ext is exposign that functionality
23:19 imirkin_: so you can do it another way ... big deal
23:20 linkmauve: Couldn’t that be an issue for Wine programs which do both d3d9 and gl calls in the same process?
23:20 imirkin_: they'd have different contexts
23:20 imirkin_: how would you mix dx9 with gl anyways ... dangers everywhere
23:21 linkmauve: Right, so not a whitelist per se, just a way to enable the other behaviour.
23:21 linkmauve: I’ve heard of applications doing that.
23:21 imirkin_: i.e. the thing i proposed on the list.
23:21 imirkin_: unfortunately without radeonsi signing up for this ext, it's fairly pointless
23:21 imirkin_: so i won't push it further without mareko's buy-in
23:22 mareko: what ext?
23:22 imirkin_: mareko: see ML
23:22 imirkin_: mareko: basically a way to expose non-IEEE multiplication
23:23 imirkin_: r600 and nouveau already implement what's needed for it, but that's like all of 3 users world-wide, so ...
23:23 imirkin_: the rest is intel and radeonsi ... idr already said that intel is unlikely to expose it given that the weird-alu mode hasn't really been validated
23:23 mareko: radeonsi doesn't use TGSI_MUL_ZERO_WINS
23:24 imirkin_: i know
23:24 imirkin_: would you have any interest in changing that?
23:24 mareko: imirkin_: if GL doesn't need it, then no
23:24 imirkin_: (or some other way to indicate that zero wins)
23:24 imirkin_: mareko: i'm trying to add a GL ext for this
23:24 karolherbst: imirkin_: I think the issue is not even limited to shaders
23:24 imirkin_: but if you're not interested, i'll just kill it
23:25 idr: imirkin_: I just sent a long reply to the list.
23:25 imirkin_: idr: thanks, i just saw it
23:25 imirkin_: [but have not read]
23:27 imirkin_: idr: the main point about nv50 is that it needs to be a single value across shaders. i think you got that at the end of your thought process, but just pointing it out.
23:28 imirkin_: (whereas for nvc0 and r600, it could easily be different per-shader-stage)
23:29 imirkin_: idr: the problem with doing something in shaders is ... what about e.g. fixed function shaders? i'm not sure that they wouldn't benefit from something like that.
23:29 karolherbst: imirkin_: do you know where it could matter outside of shaders? Maybe I remember what I've discussed on fosdem
23:30 imirkin_: but really if radeonsi doesn't want to pick up this ext, it's DOA and i won't pursue it further
23:30 karolherbst: I remember that we also talked that a context flag would be actually a better fit
23:30 idr: I know we stopped flipping the "non-IEEE" mode bit for assembly shaders and fixed-function ages ago, and we've never looked back.
23:30 imirkin_: karolherbst: shaders generated for fixed function stages
23:31 imirkin_: (oh, and ARB shaders, forgot about those too)
23:31 idr: Anyone counting on NaN in vertex data or fixed-function matrices doing anything other than explode is asking for trouble. :)
23:31 imirkin_: idr: usually it's like 0 * rsq(0) or something
23:31 karolherbst: imirkin_: no, it was something else.. dxvk has a "enableRtOutputNanFixup" option
23:32 imirkin_: i guess i dunno what all you can do with fixed function setups
23:32 imirkin_: karolherbst: that's for RT's, and separate
23:32 karolherbst: yeah
23:32 idr: I think the assembly-to-NIR code emits some fixups.
23:32 karolherbst: I think this was the workaround which works good enough, but not perfectly
23:33 imirkin_: the hw supports the thing that is actually needed, so why not expose it...
23:33 karolherbst: because people like to bikeshed
23:33 mareko: imirkin_: you can expose whatever you want for your hw
23:33 idr: For us, it added extra tracking, extra flushes, extra weird behavior that we didn't want, etc.
23:34 imirkin_: mareko: i know, but for mesa, radeonsi probably has the most users of wine by far
23:34 imirkin_: so if radeonsi doesn't get it, it's a bit irrelevant
23:34 imirkin_: and i don't like doing work when i know ahead of time that it won't be useful
23:35 karolherbst: idr: but from your answer it sounds like you very much prefer it to be a flag on context creation, because it gets rid of all the weird issues
23:35 idr: That's probably the global maxima. Not really great for anyone, but also not terrible for anyone.
23:36 karolherbst: yeah
23:36 idr: I still don't think we'd use the hardware flag for various reasons.
23:36 idr: I don't want to validate that all of our blorp shaders would still work correctly in all circumstances, for example.
23:38 karolherbst: that's fair, but I like the idea of being able to do different optimiztions and just lower the operations in the end or so
23:38 karolherbst: should allow the driver to come up with better code
23:38 imirkin_: mareko: so to confirm, you would not support an ext on radeonsi which exposes the non-ieee mul behavior?
23:41 anarsoul: tomeu: can we have your r-b for https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3884 ?
23:41 gitbot: Mesa issue (Merge request) 3884 in mesa "gitlab-ci: Fix skips and fails for lima" [Ci, Lima, Opened]
23:47 mareko: imirkin_: correct
23:47 imirkin_: k, thanks
23:56 craftyguy: robclark: I think something in your freedreno/computerator series broke the build test on the Intel CI:
23:56 craftyguy: ../src/freedreno/computerator/main.h:34:10: fatal error: registers/adreno_pm4.xml.h: No such file or directory
23:59 robclark: hmm