01:30 alyssa: I wish we had a way to filter for "MRs blocked on review" versus "MRs open for literally any other reason"
01:31 alyssa: It's not my job to shepherd other people's MRs to merge, but maybe it is??
01:31 alyssa: I'm not sure if GitLab has the right affordances for this
01:32 alyssa: of the 133 open NIR MRs
01:32 alyssa: I would be happy to review what it takes to get them merged or closed or whatever
01:33 alyssa: But I can't even tell what's pending review, versus "the original author doesn't care anymore" or "the original author is going to get back to this, there's active review"
01:48 HdkR: alyssa: Additional tags? :)
01:53 alyssa: HdkR: Hmm, yeah, that could maybe work
01:54 alyssa: It wouldn't help with triage of the 1000 already-open MRs
01:54 alyssa: but maybe for going forward
01:57 HdkR: MR not tagged with new labels, I guess people don't care enough to not be ignored ;)
01:57 alyssa: heh
01:57 alyssa: "so unfourtunately I confirm that we can't support shaderStorageImageWriteWithoutFormat"
01:57 alyssa: ubershader time? :-p
01:59 HdkR: Everyone loves an ubershader
02:06 jenatali: Nah, just shader variants
02:07 alyssa: jenatali: shader variants in your vulkan driver? likelier than I thought
02:07 jenatali: Oh, Vulkan. Uh... nevermind, good luck
02:07 alyssa: i'm shitposting about v3dv
02:07 jenatali: Ah I see
02:08 jenatali: We're running into format support issues with the 4444 formats, one of them is required but it's a different one than D3D has. We can get so close, but border color is wrong... unless we add shader code to fix it up D:
02:08 alyssa: oof.
02:08 alyssa: is this for glon12 or dozen?
02:09 alyssa: for glon12, the border colour quirk CAP will give you the format and then you can swizzle the format when packing the sampler
02:09 jenatali: Dozen
02:09 jenatali: For GL we'd just shader variant and not care
02:09 alyssa: for dozen, just don't set customBorderColorWithoutFormat and then you have the format at sampler create time and can swizzle in the sampler
02:09 alyssa: (does dozen need customBorderColor support at all?)
02:10 jenatali: It's not about custom, it's a problem with the builtin ones too
02:10 jenatali: The location of alpha changes
02:10 alyssa: ufffff
02:10 alyssa: right...
02:10 alyssa: (customBorderColor is mostly good for Zink, DXVK, and vkd3d and for some reason I don't think dozen cares about those 3 :-p)
02:11 jenatali: Yeah custom isn't a problem, well except for this format...
02:12 jenatali: Anyway, we'll probably just add it to D3D, as stupid a format as it is, was just commiserating about things that would require shader variants in a Vulkan driver and how they're impossible
02:15 alyssa: ah, yeah
02:15 alyssa: I mean
02:15 alyssa: some variants are possible
02:15 alyssa: if you're masochistic enoug
06:13 ishitatsuyuki: dumb question, what are the wider bool types in NIR (bool8, bool32) for?
06:17 airlied: some hw only has 32-bit booleans
08:35 dj-death: there is no way in NIR to tell whether a sampler variable points to a combined image/sampler binding or just a sampler binding right?
11:46 DottorLeo: @karolherbst, i've seen your brach about SPIRV on rusticl, i'm intrigued on the HIP support...could it work also on Blender, now that HIP is the only supported platform for it?
11:46 karolherbst: DottorLeo: potentially. It's just that HIP also relies on SVM being there
11:48 DottorLeo: but it will only support what is supported from HIP itself? I mean GFX6,7,8 are not supported by HIP so the shouldn't work on blender even if they are supported by Rusticl+Radeonsi branch
11:48 DottorLeo: ?
11:48 karolherbst: uhhh... dunno? I mean, why would rusticl be limited by what HIP supports?
11:50 DottorLeo: Uhm...interesting so "technically" Rusticl+radeonsi should help running HIP applications also on not officially supported cards...if i understand correctly your work on Radeonsi+Rusticl ^^"
11:50 karolherbst: yeah
11:50 karolherbst: but HIP is a bit of a mess
11:51 karolherbst: it kind of depends on how it all works out and what hipsycl is doing under the hood
11:51 karolherbst: _but_ in theory it just maps on top of CL
11:52 karolherbst: ehh wait
11:52 karolherbst: it was "chip-spv"
11:53 DottorLeo: you know that the entire old radeons (GFX < 9) community will test it in everything hasn't work in the past on official AMD drivers and you will unleash something unexpected? :D
11:53 karolherbst: probably
11:53 karolherbst: I mean, there are already people testing it
11:54 karolherbst: I just have to finally get it all merged
11:54 DottorLeo: i have a gfx 6,7,8 ready for testing ;D
11:54 karolherbst: that's all using radeonsi, right?
11:54 DottorLeo: yeah, but 6 and 7 have experimental support on radeonsi
11:54 DottorLeo: i have to force it
11:55 karolherbst: I see
11:55 karolherbst: one thing I'm not sure of is how it well it would work on GPUs which need relocations
11:55 DottorLeo: also Gerdie with r600 for computing :D
11:55 karolherbst: and I don't know which gens those are
11:57 DottorLeo: last thing...different subject. What will be the minimum GPU needed for using NVK when it will be ready?
11:57 DottorLeo: Fermi too old?
11:58 karolherbst: kepler+
11:58 karolherbst: Fermi might potentially work if somebody puts the effort into it, but quite a lot of stuff would need fermi specific paths
11:58 karolherbst: where atm a lot of things are just common code across all gens
11:58 karolherbst: with just a few arch specific paths
11:59 DottorLeo: nm, it's too old :D i have an old laptop with nvidia 610M that is Fermi 2.0, it might be fun to test it :D
12:00 karolherbst: uhhh
12:00 karolherbst: also very slow
12:01 DottorLeo: yeah ^^" the HD3000 paired with the Sandybridge i think might surpass it
12:02 karolherbst: yeah.. especially on nouveau without support for reclocking
13:16 jenatali: dj-death: The "sampler" types in NIR are generally combined image+sampler. The sampler types with no dimension info (called bare sampler) are just a sampler, while "texture" types are sampled images, with separate samplers
13:16 jenatali: I'm not sure how internally consistent all that is, but we have a lowering pass we use that generates that consistency for GL/VK/CL
13:24 dj-death: jenatali:
13:24 dj-death: jenatali: thanks, I was pointed out that mutable descriptors don't have to support combined image/sampler
13:24 dj-death: jenatali: that kind of solved my problem :)
13:30 jenatali: Oh ok
14:41 javierm: tzimmermann: hi, a Nvidia dev asked me about http://patchwork.ozlabs.org/project/linux-tegra/patch/20221117184039.2291937-8-thierry.reding@gmail.com/
14:41 sravn: tzimmermann: IT would be fine if you can land the crtc_helper.h cleanup sometime tomorrow - if this is not too early
14:41 javierm: I read that as Thierry sending a v4 where he drops the ARGB formats but maybe was waiting for a confirmation from you ?
14:42 javierm: tzimmermann: just making sure that you are not both waiting for each other :)
14:48 javierm: karolherbst: for your jetson nano boot issue, did you try booting with "clk_ignore_unused" ?
14:48 javierm: karolherbst: because you said tha the last printed message was about disabling clocks
14:50 tzimmermann: sravn, ok
14:50 tzimmermann: javierm, i'm waiting for thierry's next patch
14:51 javierm: tzimmermann: yes, I know but what I meant is that maybe he is waiting for your confirmation too and you two are in a deadlock
14:52 javierm: maybe you can answer and make it explicit?
14:55 tzimmermann: javerim, done
14:55 tzimmermann: javierm, done
14:57 javierm: tzimmermann: thanks!
16:11 karolherbst: javierm: good point, will try that out later
16:12 javierm: karolherbst: Ok
16:13 alyssa: /* fini without a prep is almost certainly a userspace error */
16:13 alyssa: WARN_ON(etnaviv_obj->last_cpu_prep_op == 0);
16:13 alyssa: bad, etnaviv, that's not WARN means!
16:16 zmike: implementation detail
20:17 jekstrand: dcbaker: So, rust proc macros....
20:17 jekstrand: dcbaker: I see you added support to meson which is great.
20:18 jekstrand: dcbaker: There's a bit of a problem, though. IDK how to write them without the syn crate from crates.io. :sob:
20:19 dcbaker: jekstrand: I know. I'm *trying* to get to the point of having crate support
20:19 dcbaker: I've just ended up rewriting half of the guts of the meson IR because the layering violations make the code awful, and that rewrites are of course, extremely complicated and hard to review :(
20:20 jekstrand: :-(
20:20 dcbaker: then we went and had a 1.0 release, so now I can't regress anything with proper deprecation, which makes the review even more difficult
20:20 jekstrand: Yeah
20:20 dcbaker: I think I can land the very first bit of those changes today
20:20 jekstrand: dcbaker: Do we at least have what we think is a viable path forward?
20:20 dcbaker: yes
20:20 jekstrand: \o/
20:21 dcbaker: I think I have buy in from everyone on what I want to do
20:21 jekstrand: dcbaker: Do you have a branch with crates working?
20:21 dcbaker: I have a branch with some very basic stuff working
20:21 jekstrand: dcbaker: I don't care if the syntax changes out from under me in the next couple months.
20:21 dcbaker: https://github.com/mesonbuild/meson/pull/10151
20:22 jekstrand: dcbaker: proc macros is listed as a to-do. Is this proc macros from crates or crates so I can get syn?
20:22 dcbaker: proc-macros from crates
20:22 jekstrand: Ok, that's fine
20:22 dcbaker: basically that's my checklist of "when all of this is done we can take this off drafts"
20:22 jekstrand: sure
20:24 dcbaker: oh, I should really send that first patch separately... that's a bug fix. lol
20:25 jekstrand: Pulled. Time to see if I can make this work. :D
20:25 jekstrand: dcbaker: Thanks for working on this! You may single-handedly become one of the most important contributors to the rust ecosystem as far as I'm concerned. :D
20:26 jekstrand: By contributing to meson....
20:26 dcbaker: lol
20:26 jekstrand: dcbaker: Ok, so here's the concerning thing.... That was published almost a year ago. :-/
20:26 jekstrand: Am I going to have crates in 6 months?
20:27 dcbaker: I hope so. the real blocker is getting the reworks for the core targets in...
20:27 jekstrand: kk
20:27 dcbaker: some of the gstreamer folks are interested in this as well
20:27 jekstrand: Worst case, I guess I can replace my proc macro with some horrible python.
20:27 dcbaker: maybe I can con one of them into speeding up the reviews...
20:28 dcbaker: worse case we could hand port the syn crate to meson...
20:28 jekstrand: I'm hoping to merge NVK and NAK into mesa/main in 6 months or so.
20:29 jekstrand: Of course, that assumes I get NAK written
20:29 jekstrand: Anyway, I'm going to see if I can get this up and going
20:29 dcbaker: \o/
20:30 jekstrand: dcbaker: Do you have an example .wrap file?
20:33 dcbaker: for a Rust project? no. It really won't be that much different than the wrap files that are already in the subprojects directory
20:33 FLHerne: what's NAK?
20:33 dcbaker: just that the meson overlays would live inthe mesa tree
20:33 dj-death: Not Another Kompiler?
20:33 jekstrand: Nvidia Awesome Kompiler
20:34 jekstrand: dcbaker: Ok, so maybe this works differently than I think.
20:34 dcbaker: Nir Assembly Kludge?
20:34 jekstrand: dcbaker: How do I pull in an external crate is the question, I guess.
20:34 jekstrand: I'm looking through your test cases and it's not jumping out at me as obvious.
20:34 ccr: will there be ACK too, to complement NAK? :P
20:35 kisak: Nvidia Awesome Community Kompiler ... all contributions are NACK:
20:35 FLHerne: ah, to replace the current nvc0 backend?
20:35 ccr: Advanced Compiler Kit?
20:35 FLHerne: and in Rust, I see having found the branch
20:35 FLHerne: very nice
20:35 jekstrand: dcbaker: I'm seeing a bunch or Cargo.toml files which I guess makes sense if you're invoking cargo.
20:36 dcbaker: my branch?
20:36 jekstrand: dcbaker: Your PR
20:36 jekstrand: Looking at the unit tests
20:36 dcbaker: Okay, it reads the Cargo.toml files, then converts that into Meson IR and generates a single unified ninja compile
20:37 dcbaker: to get the files you need you'd run cargo vendor syn, which will fetch the stuff the branch wants
20:37 dcbaker: eventually I'd liket o get rid of the cargo vendor step
20:37 dcbaker: but one thing at a time
20:38 dcbaker: syn has two dependencies, so we could probably just hand wrap that
20:38 dcbaker:-> lunch
20:51 airlied: anholt, robclark : can someone turnipy just ack the top commit in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20389 so I can land it
20:51 airlied: if you ever feel like vulkan video then someone can debug it :-P
20:52 DavidHeidelberg[m]: I just rerun the "magic LTO pipeline" today... yields so much nicer runtimes. around ~ 1 minute saving on llvmpipe & lavapipe; virgl-iris-traces ~ 5 minutes; venus-lavapipe ~2 minutes; panfrost t860 x/3 jobs: 10 10 7 -> 7 7 8 min; For CI, could we set some treshold how many times has to "full LTO" pipeline pass to switch it for real testing?
20:52 anholt: airlied: done
20:53 airlied: thx!
20:55 jekstrand: \o/
21:00 dj-death: jekstrand: do you remember if bounds checking works with nir_address_format_64bit_bounded_global and negative offsets?
21:01 jekstrand: dj-death: The offset is unsigned currently.
21:01 jekstrand: dj-death: why?
21:02 dj-death: because it doesn´t apparently
21:02 jekstrand: dj-death: I don't see how we could support negative offsets
21:02 jekstrand: dj-death: Uh, what?!?
21:02 dj-death: dEQP-VK.robustness.robustness2.bind.notemplate.r32i.unroll.volatile.storage_buffer_dynamic.readwrite.no_fmt_qual.len_256.samples_1.1d.comp I think is an example of that
21:02 jekstrand: dj-death: It should be doing an unsigned compare which, for negative offsets, should be treated as a very high offset which is OOB.
21:03 jekstrand: We don't need two comparisons if we treat the offset as unsigned.
21:04 dj-death: yeah true
21:04 dj-death: not quite sure how I end up with an address below the base address then :/
21:05 jekstrand: ¯\_(ツ)_/¯
21:31 dj-death: jekstrand: shouldn't we use nir_uge instead of nir_ige ?
21:35 jekstrand: dj-death: We should. Are we using ige?
21:36 dj-death: yep
21:36 dj-death: that's not the only problem it seems
21:37 dj-death: if you do a -4 offset access with a size of 4, the current comparison also doesn't work
21:37 jekstrand: right
21:38 jekstrand: We probably want `assert(size > 0)` and `nir_ult(nir_iadd_imm(addr.z, size - 1), addr.y)`
21:38 jekstrand: (where nir_channel is used to get .y and .z, of course)
21:39 jekstrand: dj-death: Hrm... We may want to take alignment into account somehow.
21:39 jekstrand: dj-death: You could have an offset of -2 and a size of 4
21:39 jekstrand: That's really annoying!
21:40 dj-death: yey passing
21:40 dj-death: trying to implement a different binding model, I keep finding all kind of corner cases in the anv_apply_pipeline_layout that don't really work
21:43 jekstrand: Yeah...
21:44 jekstrand: But, hey, we need all those things fixed for NVK anyway. :D
21:44 DavidHeidelberg[m]: How does changing a number of parallel jobs introduce new failure? :D What is that witchcraft?
21:46 jekstrand: It shards different which means different tests run back-to-back. If there are bugs where old data can end up in new contexts, that can mess with results.
21:47 jekstrand: DavidHeidelberg[m]: ^^
21:47 DavidHeidelberg[m]: jekstrand: right, so it's the test or driver issue
21:48 jekstrand: Likely, yeah.
21:48 jekstrand: And an annoying one at that
21:48 jekstrand: DavidHeidelberg[m]: It could also cuase a different set of tests to end up in parallel with each other which, if there are OOM issues can blow things up too.
21:49 jekstrand: Also, increasing parallel jobs increases liklihood of OOM
21:50 DavidHeidelberg[m]: jekstrand: we have ZRAM these days
21:50 DavidHeidelberg[m]: so that would lead more or less to the extreme slowdown of the job
21:52 jekstrand: dcbaker: Ok, so if I want to pull in syn and its deps, how do I go about that? Some Cargo.toml in mesa/subprojects/syn?
21:52 dcbaker: with my branch? yeah, you need to put the directories in mesa/subprojects
21:53 jekstrand: dcbaker: What would that look like?
21:54 jekstrand: Do I need a wrap to pull it?
21:56 jekstrand: All the examples I see in your PR are unit tests and they have the .rs files right there (which makes sense for unit tests)
21:58 dcbaker: with my branch you'd run cargo vendor --no-delete to pull in all of the dependencies initially, and then then you'd use sub = rust.cargo(...), and get a subproject() object. I just tried this out and cargo now does a much better job validating the Cargo.toml than it used to... which is annoying
22:00 jekstrand: Sure, those commands are great but what do I check into mesa to make it work?
22:01 DavidHeidelberg[m]: linkmauve: ping, you gave up on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18644 what do you think about integration with Rust, it is doable?
22:09 jekstrand: dcbaker: A little git repo (or even tarfile) with an example meson project that pulls something from crates.io would be really helpful.
22:10 jekstrand: dcbaker: I see stuff that lets you define a project with a Cargo.toml in subprojects/ and use it but I don't know how to get from there to crates.io.
22:10 jekstrand: I'm also a bit nervous about the "let's re-invent cargo" plan but as long as it works for the one dependency I need to pull in, I don't really care too much about the details.
22:11 jekstrand: Nor do I have a better plan. ¯\_(ツ)_/¯
22:11 jekstrand: But, yeah, an example of how to pull something from crates.io would be super useful.
22:16 dcbaker: jekstrand: okay. Here's a snipppet https://gitlab.freedesktop.org/-/snippets/7354, that has a fake Cargo.toml for syn, plus the necessary shell commands to run to put the necessary stuff in subprojects/
22:18 dcbaker: then you can run the normal rust = import('rust'); sub = rust.cargo('syn'); target = library(..., dependencies : sub.get_variable('sub') dance that the cargo subproject thing does
22:19 jekstrand: dcbaker: So the Cargo.toml goes in the main Mesa folder?
22:19 dcbaker: yes
22:22 jekstrand: It's complaining about the [[bin]] section
22:22 dcbaker: sigh, of course it is :/
22:22 dcbaker: let me see how hard it would be to just hand wrap these for the moment, and come back to the automatic wrapping...
22:23 jekstrand: I don't care about having to check in a file or two.
22:24 jekstrand: Uh oh... I just came up with an evil plan...
22:24 jekstrand: If I have to, I can do this without a proc macro. I can make a normal macro for declaring my structs. 🤔
22:24 Sachiel: rewrite meson in rust?
22:24 jekstrand: That's horrible
22:25 jekstrand: I'd much rather just have a proc macro. :)
22:25 dcbaker: Sachiel: why not? What's a 4th implementation of meson?
22:25 jekstrand: I think. Those are honestly pretty horrible so maybe not....
22:33 karolherbst: jekstrand: what do you want to pull in?
22:33 jekstrand: syn, for writing proc macros
22:34 jekstrand: Because I don't feel like parsing token streams myself
22:34 karolherbst: fair
22:34 karolherbst: but yeah.. meson needs to support this sooner or later
22:35 jekstrand: I think dcbaker probably has it mostly working if he can tell me how to use it. 😅
22:36 karolherbst: heh
22:37 dcbaker: jekstrand: It's been a year, I can't really remember what is and isn't working anymore...
22:37 dcbaker: As an interesting exercise I'll port syn over to meson by hand, which has already turned over some interesting bugs... sigh
23:16 jekstrand: heh
23:33 jekstrand: dcbaker: Also, that branch is pretty old. Any way you could update on 1.0? I need the dependencies field in rust.bindgen
23:38 jekstrand: s/field/argument