03:02 airlied:is being lazy, ctz in NIR is?
03:04 airlied: ah find_lsb + 1 probably
06:48 mareko: zmike: are you sure?
06:49 mareko: the will be a little bit of fps boost from the follow-up series that hasn't been published yet
06:49 mareko: but I don't expect much difference from the current series
07:18 airlied: daniels: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/5437994 is that a dead machine in lava lab?
07:19 airlied: I cancelled a job that was 10 minutes on that screen with no info
07:22 airlied: tomeu: ^?
07:22 tomeu:looks
07:24 tomeu: some kernelci jobs seem to have taken both machines hostage: one with a deadlock and the other after breaking eth and thus NFS
07:25 tomeu: will check and cancel
07:25 tomeu: then mesa ci jobs should flow again
07:25 airlied: tomeu: nice thanks!
07:38 airlied: tomeu: was there a large backlog, still not executing here
07:39 tomeu: airlied: yes, but jobs are being canceled as we speak
07:39 tomeu: give me a couple of minutes more, please
07:39 airlied: no worries, was just wondering if I should come back after dinner :-P
07:42 tomeu: airlied: ok, https://gitlab.freedesktop.org/mesa/mesa/-/jobs/5437994 is starting to run now
07:42 tomeu: not sure why it doesn't show up in the gitlab ci logs, though
07:44 airlied: yay thanks!
07:46 tomeu: np, sorry about that, though the blame should go to those kernel hackers that keep adding bugs! :p
12:33 zmike: mareko: well I just rebased for the first time in a week or so, and I think that's the only thing I picked up which would account for the difference
12:33 zmike: I haven't done a deep analysis though, so I might be wrong
13:32 zmike: itoral: heya, thanks for the quick turnaround on that issue. I've recently rebased zmike/zink-wip onto master (though it doesn't yet include your latest patch) if you want to check out the perf there on v3dv
13:33 itoral: zmike: great, thanks, will do and let you know if I see any improvements
13:33 zmike: 👍
13:49 itoral: zmike: the build fails to link for me on rpi4 with: zink_draw.c:1087: undefined reference to `vkCmdDrawIndexedIndirectCount'
13:50 zmike: huh
13:50 itoral: pretty sure that is not available in Vulkan 1.0
13:50 zmike: yes, zink-wip is 1.2
13:50 zmike: and I haven't done any version checking
13:50 itoral: ah, ok
13:51 zmike: I've been meaning to go back and do that at some point, but it hasn't really been an issue yet
13:52 zmike: we're getting some versioning MRs in the pipe now, so maybe it'll happen naturally in the course of that
13:52 Venemo: jekstrand: can you help me out with the new deref modes? I now have a deref whose modes field is 32767, which doesn't make any sense to me.
13:56 itoral: zmike: actually, I said the build failed for me on rpi4, but nope, it fails on my laptop
13:56 zmike: huh
13:56 itoral: it builds correctly from mesa master though
13:56 itoral: so something's off
13:56 zmike: that's bizarre
13:57 zmike: failing in the same place?
13:57 itoral: I was not building on rpi4 at all, I was building it on my laptop only
13:57 zmike: ah
13:57 zmike: hm
13:57 zmike: I guess you don't have 1.2 installed then?
13:58 itoral: I should, I can build anvil
13:58 itoral: form master
13:58 itoral: *from
13:58 zmike: super huh.
13:59 zmike: I've never heard of anyone having this issue before when building my branch...
14:01 zmike:builds it again just to double check
14:02 zmike: yup, still builds fine here
14:03 itoral: zmike: I also get some warnings with that branch: st_atom_shader.c:222:7: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
14:03 itoral: which sound suspicious
14:03 zmike: that's just gallium code, nothing to do with me haha
14:03 zmike: well
14:03 zmike: I say that, but I do have gallium patches, so it could be me...
14:04 zmike: ah, yeah, there's some hacks in there to adjust pending MRs
14:04 itoral: I don't get those warnings from gallium when building from master
14:04 zmike: you can ignore them
14:04 itoral: ok
14:05 itoral: I have to go now, if you find a solution to the build problem I'll be happy to try again
14:06 zmike: sure, though I don't really have any way to repro it :/
14:06 zmike: thanks for trying
14:08 Venemo: jekstrand: never mind, I think I was doing something stupid there
14:35 agd5f: any idea how to get this merged? margebot doesn't seem to have picked it up. https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/96
14:35 gitbot: Mesa issue (Merge request) 96 in drm "tests/amdgpu/vcn: update to not use asic_id for Renoir" [Amd, Tests, Opened]
14:36 bnieuwenhuizen: agd5f: you actually have to set the assignee to marge-bot
14:36 agd5f: is that new?
14:37 bnieuwenhuizen: marge has always worked that way, at least for mesa
14:37 bnieuwenhuizen: the approval bit you used is new and effectively does nothing at the moment
14:37 pendingchaos: I don't think marge is set up for that repo
14:37 bnieuwenhuizen: yeah looks like it
14:38 agd5f: but I mean, I committed some changes to mesa/drm last week and I just clicked the merge button and it was done
14:38 daniels: agd5f: 'approve' != 'merge'
14:38 bnieuwenhuizen: that is still posible
14:38 agd5f: daniels, i know
14:38 bnieuwenhuizen: just not using marge
14:38 bnieuwenhuizen: you have to rebase first though using the rebase button
14:38 daniels: right, if you want to use marge then assign to marge - if you don't then press 'merge'
14:39 daniels: I forget which DRM is
14:39 bnieuwenhuizen: marge-bot seems to not have permissions for the repo
14:39 agd5f: I guess the issue is there is no merge button for that MR
14:39 bnieuwenhuizen: yeah you need to do the rebase first
14:39 bnieuwenhuizen: then the green "rebase" button will turn into the merge button
14:41 bnieuwenhuizen: agd5f: you don't need to have the developer rebase btw, you can just use the rebase button from the UI
14:42 agd5f: thanks
14:44 daniels: bnieuwenhuizen: blue rebase button -> green merge button
14:46 bnieuwenhuizen: daniels: eh, the button showed up green for me. Maybe by the time time I typed it it was already switched or something ..
14:47 bnieuwenhuizen: yep, green: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/65
14:47 gitbot: Mesa issue (Merge request) 65 in drm "Some pushbuf_dump fixes" [Nvidia, Opened]
14:57 pendingchaos: jekstrand, cmarcelo: ok to marge https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6231 ?
14:57 gitbot: Mesa issue (Merge request) 6231 in mesa "spirv: fix GLSLstd450Modf when the destination is function/private vector" [Spir-V, Opened]
14:59 jekstrand: pendingchaos: I think you can just use vtn_local_store
15:00 pendingchaos: jekstrand: that would be incorrect for ssbo/global derefs
15:01 jekstrand: pendingchaos: Ugh... Yeah, you're right.
16:35 orbea: airlied: was there any efforts/plans to upstream this to glslang? https://src.fedoraproject.org/rpms/glslang/blob/master/f/0001-pkg-config-compatibility.patch
16:52 jekstrand: orbea: Good luck!
16:53 jekstrand: orbea: Generally, the people who run the Khronos repos don't really understand software packaging on Linux.
16:54 orbea: heh...
16:56 jekstrand: Everything is done via python scripts that are effectiveliy hand-rolled git submodule to fetch the dependencies and then tying things together with CMake subprojects.
16:57 orbea: yea, i'm familiar with the problem. Also everything else in the vulkan-sdk seems to test arbitrary git revisions from the known_good.json files than release tags.
16:57 jekstrand: It works but it's much more the way you'd expect SW development to happen on Windows where people expect one monolithic install.
16:57 jekstrand: orbea: Yeah. There are reasons for that, sort-of.
16:57 jekstrand: orbea: At least now, the SDK comes with a machine-readable file which contains the git SHAs of everything
16:59 jekstrand: So that's better than nothing.
17:00 orbea: yea, true enough
17:00 jekstrand: Part of the problem there is that the sdk contains components like DXSC for HLSL -> SPIR-V and that's controlled by Microsoft not anyone in Khronos so they can't really tag releases.
17:01 jekstrand: But also, everything is very ad-hock and most of the people maintaining the individual projects that make up the SDK don't really understand a concept of stable releases. It's all master all the time in their world.
17:08 Venemo: jekstrand or Kayden can you take a look at MR 7473 if your time allows?
17:27 karolherbst: jekstrand, airlied: I think I need a name for an OpenCL frontend written in rust :D Although I am not sure _how_ we want to do this. Do we want to implement OpenCL on top of L0 and have a L0 frontend instead or...
17:29 mripard: RaCLette?
17:29 mripard: (https://en.wikipedia.org/wiki/Raclette)
17:30 jenatali: Or is that too cheesy? :P
17:30 mripard: haha :)
17:31 mripard: there's no such thing as a raclette with too much cheese though :)
17:31 jenatali: Heh, I was just being punny, I actually like that name
17:33 karolherbst: but oh boy is Rust nice
17:33 MrCooper: if you can't see any potatos or veggies, there might be a bit too much cheese
17:33 karolherbst: it makes look C++ look like overcomplicated garbage nobody should use
17:37 jekstrand: karolherbst: You could call it bleach
17:37 karolherbst: mhhh
17:37 karolherbst: too many associations
17:37 jekstrand: karolherbst: It's a bit of a stretch but Rust is Iron Oxide and CL is the chemical symbol for chlorine and one of the first bleaches was chlorine oxide.
17:38 jekstrand: Yeah, it takes a lot of steps to get there. :P
17:38 karolherbst: I kind of like the idea of implementing l0 instead and put CL just on top of it
17:39 karolherbst: if we implement l0 as a frontend we could call it r0 :D
17:39 karolherbst: or m0
17:39 jekstrand: heh
17:39 bnieuwenhuizen: cl0
17:39 karolherbst: bnieuwenhuizen: that would be for the cl over l0 frontend, yes
17:40 karolherbst: I just don't know how well it matches, but I am sure it matches a lot
17:40 karolherbst: I mean.. l0 was kind of designed to you can put CL on top
17:40 karolherbst: I thnk
17:41 karolherbst: *so
17:41 dcbaker[m]: Intel's level0?
17:41 karolherbst: yeah
17:41 karolherbst: but I kind of don't like to depend on a vendor API
17:41 karolherbst: so...
17:41 karolherbst: tough call
17:42 dcbaker[m]: If it were me I would not build on top of level0
17:42 dcbaker[m]: Intel has a tendency to get bored and wander off
17:42 karolherbst: maybe we could do one implementation for both as there is a lot of overlap
17:42 karolherbst: and it's mostly just a different API
17:42 bnieuwenhuizen: I think if you write CL->l0 and l0->gallium I'm not sure what the point of the intermediate is
17:42 bnieuwenhuizen: another intel driver?
17:43 karolherbst: :p
17:43 karolherbst: well
17:43 bnieuwenhuizen: or do you want to enable the intel frontend that is built on l0? (i.e. the DPC++ stuff?)
17:43 jekstrand: I don't think l0->gallium is a good idea any more than vulkan->gallium
17:43 karolherbst: other drivers could also expose it
17:43 jekstrand: but cl->gallium works ok.
17:43 karolherbst: jekstrand: yeah... maybe
17:43 bnieuwenhuizen: I think dave had ideas about coopting some of the vulkan stuff for l0 drivers
17:43 karolherbst: yep
17:43 karolherbst: don't mind targeting gallium directly
17:44 karolherbst: was mainly wondering about thoughts on this
17:44 bnieuwenhuizen: I think the main thing enabled by interop with l0 is that DPc++ is AFAIU a reasonably complete sycl implementation as well
17:45 bnieuwenhuizen: and AFAIU there are no great SYCL->CL options?
17:45 dcbaker[m]: speaking of rust karolherbst, I've been working on making rust + meson play nicer, so if you run into things that are lacking let me know. I've got support for rust editions into what will be 0.57.0, and hopefully I'll get cargo integration as well
17:45 bnieuwenhuizen: so if you want something in the single source area that might be a shortcut
17:46 karolherbst: dcbaker[m]: yeah.. I didn't target mesa yet as I was aware that something like that is going on
17:46 karolherbst: I think at this point it's mostly just wiring up the C libs we already have
17:46 karolherbst: like libnir
17:46 karolherbst: and libmesa
17:46 karolherbst: and being able to generate bindings
17:46 karolherbst: not looking forward in writing the bindings myself
17:47 karolherbst: kind of like swig where you just include the header and are done with bindings
17:47 karolherbst: doesn't support rust though
17:47 karolherbst: and I don't know how hard it is to write rust bindings for C stuff
17:48 jekstrand:wishes it was easier to figure out which opt from nir_opt_algebraic was causing a thing....
17:48 jcline: karolherbst, https://crates.io/crates/bindgen makes it super easy (for some value of easy I suppose)
17:49 karolherbst: jcline: any idea what other projects are using?
17:49 karolherbst: like how the llvm bindings are generated?
17:49 pendingchaos: jekstrand: maybe an env var like NIR_PRINT which prints which opts happen on what ssa defs?
17:49 pendingchaos: then you can search for the ssa def in the output
17:49 jcline: Not tons, buy I do know the convention is to generate bindings in a tiny -sys crate and then write safe rust-y APIs on that
17:50 karolherbst: mhhh
17:50 jcline: So you could search crates.io for -sys packages and see what most are using, I do know bindgen is quite popular though.
17:50 jekstrand: pendingchaos: Yeah....
17:51 karolherbst: jekstrand: maybe we want to have runtime breakpoint support and a list one can add patterns into so gdb auto breaks on it?
17:51 karolherbst: that would be fun
17:51 linkmauve: karolherbst, you can list the reverse dependencies here: https://crates.io/crates/bindgen/reverse_dependencies
17:52 karolherbst: linkmauve: how does that help? :p
17:52 karolherbst: not even searchable
17:52 karolherbst: at least it's sorted :D
17:52 karolherbst: but yeah. I kind of agree that the safe API thing is a problem
17:53 karolherbst: atm I am more interested in doing something similiar to the deps we are using
17:53 karolherbst: mainly llvm/clang
17:53 karolherbst: and probably libz
17:54 karolherbst: but I guess it also doesn't matter all that much
17:54 karolherbst: I think knowing what complicated APIs are doing would be helpful, which llvm is really one of
18:00 daniels: I look forward to seeing how bindgen deals with embedded lists
18:03 karolherbst: mhhh
18:03 karolherbst: good point
18:03 karolherbst: unsafe? :D
18:11 linkmauve: bindgen is all unsafe, you’re on your own afterwards to wrap stuff around.
18:16 karolherbst: ahh yeah, then it doens't matter
18:16 karolherbst: we just get our API and that's it
18:59 airlied: orbea: pretty sure that patxh is from a glslang MR, should be in the spec
19:01 orbea: airlied: I think its from here, not sure why it was closed though. https://github.com/KhronosGroup/glslang/pull/1722
19:01 gitbot: KhronosGroup issue (Pull request) 1722 in glslang "Pkg config compat" [Closed]
19:01 orbea: thre is also this which is not closed and not merged https://github.com/KhronosGroup/glslang/pull/1621
19:01 gitbot: KhronosGroup issue (Pull request) 1621 in glslang "CMake: Allow linking against system-installed SPIRV-Tools" [Open]
19:01 orbea: i only tested the latter which seems to at least build
19:02 anholt: HEADS UP: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7434 should land unless the final marge run flakes. Things are looking more stable than before in all my runs pre marge, but keep an eye out for new deqp CI failures to report on https://gitlab.freedesktop.org/mesa/mesa/-/issues/3437
19:02 gitbot: Mesa issue (Merge request) 7434 in mesa "ci: New dEQP runner" [Ci, Panfrost, Turnip, Opened]
19:02 gitbot: Mesa issue 3437 in mesa "Tracker for CI failures" [Ci, Opened]
19:02 daniels: anholt: super exciting!
19:04 anholt: there's still stuff I'd like to do to it (like folding in testlog-to-xml, and adding failures-only junit output to report to gitlab), but I'm honestly really pleased with the code in a way I haven't been of writing software in a long time.
19:05 airlied: karolherbst: l0 doesn makenaense as a layer really
19:05 airlied: too lowlevel like vk
19:05 karolherbst: ahh, okay
19:06 karolherbst: although the API we'd use from gallium is also quite small though, but yeah.. maybe it would be a too high overhead
19:06 airlied: it would either be a driver per vendor, a vk layer, or a second interface to a vk driver
19:06 airlied: its cojtwxt vs command queue
19:06 airlied: context
19:06 karolherbst: right
19:07 airlied: the mismatch is too messy
19:11 karolherbst: airlied: but how would that work as a layer? I guess you'd need some extensions in order to being able to implement it?
19:25 airlied: ueah i just have a super mesa specific ext
19:25 airlied: it kinda works but has some bad bits esp around kernel inputs
20:07 ajax: so who has an opinion about what to do about the fixed-function classic drivers
20:09 dcbaker[m]: I still vote for the glvnd thing I proposed last time this came up, but also 123 not it.
20:09 ajax: have them be their own glvnd vendor is definitely a viable strategy
20:12 airlied: yeah classic mesa glvnd package, fork and forget
20:12 dcbaker[m]: we
20:13 dcbaker[m]: 'll probably have to backport glvnd/winsys stuff on occasion but..
20:14 ajax: what do we pick for the vendor name?
20:14 dcbaker[m]: mesa-legacy
20:14 airlied:isn't entirely sure I'd want a copy of the glsl compiler in two placse, but meh
20:15 ajax: airlied: why would you care tho. not like glsl does shit on dx8 hardware
20:15 ajax: you're not getting gl 2.1 on an r200
20:15 airlied: ajax: it's the one place we get "security" bugs
20:15 airlied: I supoose if we don't need it we can rip it out
20:15 ajax: right, it's unreachable code, we can make it not exist
20:15 dcbaker[m]: I'd assume we'd at least rip out build support for that kind of stuff
20:16 airlied: though we are so close to dropping classic as well I wonder if we should just wait
20:16 airlied: it really is just gen4-8
20:17 ajax: let's go crocus (clap clap clapclapclap)
22:42 jekstrand: kusma, jenatali: Wow, 17 commits. That's about +1500 lines per commit.
22:42 jenatali: jekstrand: With the vast majority of code confined to 3 of those commits
22:43 kusma: jekstrand: yeah, that's heavily squashed ;)
22:44 jekstrand: kusma: You don't say?
22:44 kusma: for instance: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7477/diffs?commit_id=655a2314cd52f851c09c7ae620ff59eec08d80a0
22:44 gitbot: Mesa issue (Merge request) 7477 in mesa "WIP: add d3d12 gallium driver" [D3D12, Opened]
22:45 kusma: "This is the combination of more than 230 commits from our development branch"
22:45 kusma: For the rest of the big commits, I kinda gave up on counting ;)
22:46 jekstrand: kusma: That's no way to get your commit count up!
22:47 kusma: jekstrand: Well, at least it assigns all the git blame to me instead of coworkers! ;)
22:47 kusma: I dunno which one of those two metrics I'm less interested in gaming ;)
22:48 jekstrand: kusma: True.
22:49 kusma: I just couldn't find a reasonable way of carring all of that back-and-forth development into master without flattening things a bit...
22:49 kusma: Things had kinda gone a bit too crazy, especially since we have lots of winsys stuff that touches the wgl state-tracker in the same branch
22:51 jekstrand: Yeah, I gotcha
22:51 jekstrand: I'm just making fun because I can. :)
22:52 kusma: How dare you
22:53 jenatali: I'm just happy it's there :)
22:53 kusma: I'm really happy to be close to merging this stuff though. It's been a long time in the making, and even though there's some awful hacks here and there, I think we can fix that stuff upstream.
22:54 kusma: who knows, maybe jekstrand fixes some of it for me by making that nir_sort_variables thing he TOTALLY PROMISED!
22:54 kusma: That's how it works, right?
22:55 jenatali: That's my experience, jekstrand's fixed a bunch of stuff for me already :P
22:55 airlied: jenatali: so clover on d3d12 gallium for cl3.0? :-p
22:55 kusma: jenatali: I was joking, but you're not at all wrong!
22:56 jenatali: airlied: I mean, we could hook up clover to d3d12 gallium I guess, it'd probably mostly work?
22:56 kusma: jenatali: There's a bunch of stuff to hook up for that, but yeah, I guess it should work.
22:57 jekstrand: kusma: Do you need to sort variables? It'd take me all of 5 minutes to write the patch.
22:58 kusma: jekstrand: we are sorting them.
22:59 kusma: jekstrand: we, like, talked about this yesterday ;)
22:59 kusma: it was that code I mentioned that blew up when rebasing on top of the variable-list merging
23:00 jekstrand: kusma: Right. I just couldn't quite tell if you really want a sort function.
23:00 kusma: It's OK, it all works now. I just did a bunch of small mistakes (plus there were an ugly case of mismatching variable-mode and list-insertion), but that was all relatively easy to fix once I didn't do everything in one big go.
23:02 kusma: jekstrand: I think we should really sort this stuff on the DXIL level instead. But there might be some difficulties with that due to some shader-variant details etc. Anyway, if someone made a standard sort-function, I'd be happy to switch. But I'm not going to write that right now.
23:04 kusma: I'll head back to the sofa now, have a great weekend ;)
23:21 jekstrand: kusma: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7492
23:21 gitbot: Mesa issue (Merge request) 7492 in mesa "nir: Add a function for sorting variables" [Nir, Opened]
23:21 jekstrand: Ok, took more than 5. More like 15. :-P