02:29jenatali: Without DEVICE_LOCAL, yeah
03:12Lynne: nice
05:59glehmann: > D3D12 actually does better at this because they simply advertise upload vs. download vs. device
05:59glehmann: gfxstrand: but d3d12 didn't allow upload+device until very recently, so you have a ton of heuristics in drivers that give you bar memory for upload anyway (and terrible vendor dll extensions to give the app control over it)
07:29MrCooper: gfxstrand: FWIW, uncached system RAM likely uses write-combining as well; reads should perform more or less the same either way, writes can be much faster with write-combining though
08:26jani: tzimmermann: mlankhorst: I think this impacts drm-misc the most, could you review this documentation redirect change please: https://gitlab.freedesktop.org/drm/maintainer-tools/-/merge_requests/64
08:27jani: MAINTAINERS has a link to https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html which 404's after I restructured the documentation. the above should fix that
08:31tzimmermann: tzimmermann, i dont know anything about that
08:35jani: anyone else then, who knows a little bit about sphinx?
08:36sima: tzimmermann, btw merged the old -next yesterday evening, but airlied waited intentionally because of the amdgpu uapi that will be reverted in the next pull
08:36sima: so pls send the new pull soon and ping me, so that the window of "bad uapi in drm-next" is as small as possible
08:36tzimmermann: sima, i've sent out the new PR this morning. the revert is included
08:36sima: ah, will get to merging asap then
08:36sima: and thanks a lot
08:36dolphin: answred to the double S-o-b question, hopefully I did not get baited by a troll
08:51jani:grabs popcorn
09:00sima: airlied, tzimmermann ok merged the new pull with the uapi reverts
09:00tzimmermann: sima, great. thanks
09:34jani: sima: ping about the above MR. sorry, I'm just a bit anxious to fix my mistake and do away with the 404's
09:36sima: jani, sorry forgot, will do now
09:40sima: jani, I pushed the approve button
09:42jani: sima: thanks, much appreciated!
09:43jani: and the links work again \o/
11:59zmike: jenatali: I just got https://gitlab.freedesktop.org/mesa/mesa/-/jobs/62075916 random fail in a windows build
11:59zmike: looks like some dependency ordering issue?
12:31zmike: Hazematman: re: that trace thing from yesterday, maybe I'm missing something super obvious in e.g., https://mesa.pages.freedesktop.org/-/mesa/-/jobs/61954240/artifacts/results/summary/results/trace@broadcom-rpi4@0ad@0ad-v2.trace.html
12:31zmike: but how/why is it printing glXSwapBuffers calls if it's using eglretrace?
12:32zmike: that seems...impossible?
12:33Hazematman: Yeah that's really bizarre, unless there is some common code in retrace that in happens to call into...
12:34zmike: I mean, doing it locally that function is never called
12:34zmike: so clearly ci must be doing something very different or just lying about what command is being run
12:34Hazematman: One sec I'm going to check the apitrace code
12:34Hazematman: maybe some aliased glretrace as eglretrace :P
12:34zmike: unless this is one of those weird cases where I have distro apitrace without waffle and ci uses waffle and waffle uses glx for egl ? 😬
12:41Hazematman: zmike so something interesting here. In the common apitrace code if it fails to get a proc address for `eglGetCurrentContext` it will eventually call `glXGetCurrentDisplay`
12:41Hazematman: https://github.com/apitrace/apitrace/blob/master/retrace/glstate_images.cpp#L978
12:41Hazematman: https://github.com/apitrace/apitrace/blob/master/retrace/glstate_images.cpp#L1049
12:42zmike: hmmmmmm
12:42zmike: interesting
12:42Hazematman: I suspect this is the code thats being triggered because its the only place in retrace that calls `glXGetCurrentDisplay`
12:57zmike: I'm trying to bisect it through ci since I still get get it to repro
12:59Hazematman: I tried building apitrace with `-DENABLE_WAFFLE=on` and I can't reproduce the same crash :/
12:59zmike: same
13:00Hazematman: I get this new error though
13:00Hazematman: error: drawable failed to resize: expected 1920x1080, got 32x1080
13:10jenatali: zmike: yeah looks like a dependency ordering problem
13:10zmike: hm I haven't seen that either
13:10zmike: oh yeah I have
13:10zmike: but it's harmless
13:39Company: zmike: why does zink dislike apps that display text with more than 100 different glyphs?
13:39zmike: ?
13:39Company: we display log messages in GTK and https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/zink/zink_resource.c#L2943 triggers when we fill the atlas at startup
13:40zmike: ah
13:40zmike: yes, this is just a perf warning to indicate that some resource tracking is being disabled
13:40zmike: it's harmless
13:41Company: do you need to print that twice?
13:41zmike: it prints per resource
13:41zmike: so if it happens twice it happens in 2 buffers
13:41Company: no, I mean once as perf_debug() and once as logw()
13:41zmike: ah
13:42zmike: I don't remember why it's both
13:42Company: I had hoped to convince you to get rid of the logw() so I don't get bug reports from zink users
13:43zmike: hm
13:47zmike: I could see disabling it for release builds
13:49zmike: Hazematman: ok so I figured out what's causing it but I don't know htf it could possibly be causing it
13:49zmike: it appears to be https://gitlab.freedesktop.org/zmike/mesa/-/commit/5174de57b0a85dd0661a94dc0052a3949bafe8f6#7f64c03d67073cec4ab15b95a45de7c0ad80436d_79_60
13:51zmike: so...somehow on these systems libGL.so.1 is not in the process map?
13:51zmike: literally what are you doing linux
13:52Company: zmike: I think it's disabled for release builds already (I'd need to check) - the tricky people are the ones who run debug builds of everything, because those are the ones trying zink and filing bugs
13:52zmike: ah
13:52zmike: well
13:52Company: but those can be educated, so if you want to keep it, I'll do that
13:52zmike: in that case oh well
13:53DemiMarie: Lynne: device → host transfers must use DMA for acceptable perfoance.
13:54Lynne: no objections
13:54Hazematman: zmike: this is so bizarre...
13:54zmike: ajax is trying to remove the dlopen in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30417 and I suspect it will have the same issue
13:54DemiMarie: Otherwise the CPU is stalled for too long waiting for the device.
13:54Company: zmike: what could help is a run over the rects to merge adjacent ones that fit together - ie 0,0,10,10 ∪ 10,0,10,10 to 0,0,20,10
14:04zmike: Hazematman: yep, that's the issue
14:20zmike: this is so monumentally stupid
14:20zmike: I hate computers
15:18gfxstrand: MrCooper: Yes, but uncached system ram is not nearly as far away as VRAM. :)
15:21MrCooper: indeed
15:22gfxstrand: And then there's the Intel drivers where we used to do "real" uncached for the Atom parts and CLFLUSH all the things.
15:23gfxstrand: I guess that's not really uncached. It's cached but in the worst possible way.
15:23gfxstrand: We eventually gave up on it because we were tired of hunting bugs and we discovered that snooping only cost us like 3% or something
15:30Lynne: EXT_memory_host makes this irrelevant though, the best copy is having less copy
15:31gfxstrand: yes
15:31gfxstrand: We really need to get that working on NVK.
15:31gfxstrand: dakr or skeggsb need to wire up a UAPI for me first, though.
15:31gfxstrand: or airlied if he's feeling so inclined
15:32gfxstrand: But I think there's probably a braoder discussion about how we want to do that in the memory manager so it'll likely be a while
17:42gfxstrand: Is there a bug in spirv-as that's causing piglit to hang up on it?
17:53jenatali: gfxstrand: I had to fix one for Windows but I would've expected Linux to just work
17:54jenatali: My problem was using stdout for binary instead of text was causing weirdness with line endings ('cause Windows is bad at line endings)
17:54jenatali: Maybe there's a problem with nulls?
18:28gfxstrand: jenatali: Yeah, nulls were a theory. It's like spirv-as isn't detecting EOF and kicking off its compile. Maybe it's looking for a NULL or something? IDK. It's weird.
18:28gfxstrand: For now, I'm running with -x spirv
21:03nerdopolis: I checked some archives of #dri-devel, and I just want to say 2 things about Plymouth is that IIRC there was a recent change to make it no longer wait for the next driver to load, and that it handles the transition from simpledrm to the main driver without an issue
21:04nerdopolis: It handles the transition better than all the display servers I tested