07:25 wens: mripard: drm-misc/for-linux-next seems stuck on some old commit
07:35 mripard: wens: I *think* it should work now, let me know if it doesn't
09:09 simon-perretta-img: Making use of __attribute__((overloadable)) (in the context of clc shader gen) currently requires also appending an __asm__ to override the resulting mangled function name, which is a tad verbose; is there a less heavy-handed way to demangle strings from C than e.g. using libiberty which would mean adding a dependency to libnir?
09:27 simon-perretta-img: On second thoughts since we'd only ever really care about the function name, I guess it's simple enough to parse out without a library
09:38 wens: mripard: for me drm-misc/for-linux-next still points to '54d4f445517f drm/panfrost: Print RSS for tiler heap BO's in debugfs GEMS file', which was committed on August 12
10:54 karolherbst: simon-perretta-img: clang uses something for it internally.. wait a sec
10:57 karolherbst: simon-perretta-img: if you have the attribute on the declaration, then you could also use it on the consumer side if you link the spirvs together
11:43 simon-perretta-img: karolherbst: sorry I should've been more clear ahah, this was in the context of calling nir builtins from clc which goes down a different path when "linking", I've since raised !36873 to handle those cases
11:48 karolherbst: ahh, I see
11:56 tzimmermann: mlankhorst mripard, hi. is one of you taking care of drm-misc-fixes? it currently has 27 commits and appears to not have been sent out in a while
12:12 mripard: tzimmermann: yeah, I was on PTO, sorry. I will send it this week
12:13 mripard: (and the next, obviously)
12:14 tzimmermann: mripard, really no problem. i was just worried that we might somehow forget about it
14:05 mripard: wens: yeah, you're right, but I'm super confused now
14:06 mripard: my understanding was that the heuristic was that drm-misc-next should contain drm-misc-next-fixes to update for-linux-next
14:07 mripard: but it's the case now and it's still not updated
14:09 mripard: wens: ok, it wasn't drm-misc-next but drm-misc-fixes
14:09 mripard: it's done now
14:33 wens: thanks!
15:24 zmike: mareko: ping on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36634 and https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36296
19:06 anholt: Hey folks. If you're a mesa dev doing compiler work, we now have a common repo for closed-source fossils here (370 mostly steam apps, but also some benchmarks): gitlab.freedesktop.org/gfx-ci/private-access/shader-db-private/ . If you would like access and promise to just use it for compiler work stuff, hit me up. If you have fossils to contribute to increase coverage, I'd love to see MRs.
21:57 glynnc: how to figure out why mesa is using llvmpipe instead of i915?
22:00 anholt: if you're using xorg, make sure you're on the modesetting driver with glamor running in the Xorg log.
22:00 anholt: if that's working, then LIBGL_DEBUG=verbose may help.
22:01 glynnc: (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so
22:01 glynnc: So not that one?
22:01 anholt: that's your problem right there.
22:01 glynnc: modesetting_drv.so exists in that dir
22:01 anholt: delete the intel driver, it's loss.
22:02 glynnc: So change: Driver "intel" to Driver "modesetting" in the Device section of xorg.conf?
22:02 anholt: I'd just uninstall the driver, but you could use the config file probably, too.
22:04 glynnc: okay, thanks
22:05 karolherbst: zmike: I was wondering about "zink_get_query_result_resource" today. Why are timestamp queries read on the cpu? And.. if GL really needs this, then I might need different semantics for CL (maybe through a new query or something...)
22:06 zmike: probably due to the bits conversion
22:07 anholt: glynnc: you're also going to need the X server from main installed, unless your distro has pulled the recent (last couple months) fixes. Yes, this is silly for hardware from like 2 decades ago. But things effectively broke for some time and nobody (e.g. me) had hardware any more to fix it.
22:12 karolherbst: zmike: okay, so not because of the aggregate result thing that's mentioned below that?
22:12 zmike: karolherbst: I'm not looking at the code, just guessing
22:12 zmike: the comments are going to be way more acurate
22:13 zmike: qbos need a compute shader in order to remain on the gpu though, and since nothing in GL actually uses them I never bothered
22:14 karolherbst: ahh..
22:14 jenatali: Oh. I bothered :P
22:14 anholt: jnoorman: with the new fossils repo, I now have enough fossils that runtime is kind of a problem. found a new compiler bug, though. :)
22:14 karolherbst: zmike: anyway.. for timestamp query the zink_copy_buffer path sems to just work
22:14 karolherbst: though
22:14 karolherbst: I also do map the result...
22:14 karolherbst: at some point
22:14 karolherbst: later
22:15 zmike: for a single timestamp sure
22:15 karolherbst: you mean reusing the same query would be problematic?
22:15 zmike: but you can begin/end/begin/end/.../get_query_result_resource and then it's supposed to return all those results in the qbo
22:16 karolherbst: mhhhhh
22:16 karolherbst: and then you'd use an index to index them.. right...
22:17 karolherbst: annoying.. because I really only need a single value and I kinda prefer if the GPU would write it, because I don't want it to stall at all...
22:17 karolherbst: guess I'll have to dig a bit to see what the precise semantics are for timestamp
22:18 karolherbst: timestamp don't have a "begin" to begin with
22:18 zmike: it's possible that timestamp could be a special case in some scenarios? I never looked into it
22:18 zmike: but it gets special-cased when checking results
22:18 karolherbst: yeah dunno...
22:19 zmike: so maybe it could be the same here
22:19 karolherbst: I just now that you don't have to call begin_query for those
22:19 karolherbst: *know
22:19 zmike: I haven't done anything with queries in years
22:19 zmike: though also if you keep it on the gpu you won't get the valid timestamp bits adjustment
22:19 karolherbst: yeah... I need them to be quick for .. reasons
22:19 zmike: so you'll be getting invalid results
22:19 karolherbst: it's fine
22:20 zmike: not actually fine tho
22:20 karolherbst: the client never sees the buffer
22:20 zmike: since it means the qbo results would be different than the cpu results
22:20 karolherbst: so if there needs to be adjustments I can also do it in the frontend.
22:20 zmike: but this would affect GL too
22:20 zmike: you'd have to pass some kind of special CL flag for it maybe
22:21 karolherbst: it's already not consistent on iris
22:21 karolherbst: and apparently nothing cares
22:21 zmike: I care
22:22 karolherbst: it looked to me that zink relied on drivers doing it properly, or maybe I haven't found the spot where you do the adjustment
22:23 zmike: there's some timestamp_to_ns function or something
22:24 karolherbst: ohh found it
22:24 karolherbst: "timestamp_to_nanoseconds"
22:25 karolherbst: funky.. there is EXT_calibrated_timestamps
22:26 karolherbst: yeah, maybe I should take a deeper look and figure out what can be done there that isn't painful...
22:45 sghuge: Has anyone seen spirv-cross stripping out the OpEntryPoints?
23:32 airlied: karolherbst: I expect compute shader is the simplest answer
23:49 robclark: karolherbst: I think we talked about this before, needing to convert ticks to ms for qbo
23:50 robclark: s/ms/us/.. or whatever units
23:51 robclark: having gallium driver provide something equiv to vk timestampPeriod would be reasonable
23:52 robclark: karolherbst: btw, got any further with fixing rusticl stalls (ie. https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/52b4f218e6445ef024b24333c8fcfb9020af84b5).. we're going to need something along those lines for rusticl perf to be credible..