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