03:48 Company: and this is why GLSL is shit
03:48 Company:just learned the concept of a "dynamically uniform expression"
03:49 Company: and nothing anywhere ever even hinted that it exists
03:53 Company:goes sprinkling nonuniformEXT into his glsl hoping to catch all the places where it's needed
08:41 MrCooper: doras sima: re https://github.com/flathub/org.chromium.Chromium/pull/309#issuecomment-1674732328 note that a different file descriptor can still be problematic, if it references the same file description
12:19 penguin42: karolherbst: Can you remind me where your repo with that updated vectorise patch was?
12:20 karolherbst: https://gitlab.freedesktop.org/karolherbst/mesa/-/tree/si/vectorize
12:21 penguin42: karolherbst: Excellent; I'm going to try and get back to using the profiling I added to see where we're upto on my original test
12:22 karolherbst: cool
12:23 penguin42: ...after I recurse into getting myself a newer meson
12:24 karolherbst: just use pip or git clone it
12:27 sima: MrCooper, yeah I never know what's the right word that means "separate struct file in the kernel" :-/
12:28 sima: that's why I clarified with open() (but I guess should have mentioned that a dup() is not enough)
12:28 MrCooper: that's the file description, a file descriptor is essentially just a reference-counting identifier for a file description
12:41 koike: robclark hi o/ , I would like to check with you if you intent to pick the drm ci patch and do a pull request from drm-msm or if we should go with another workflow to get it merged
12:51 doras: MrCooper: can you clarify the relationship between file descriptor and file description in this context?
12:52 doras: Oh, you commented on it.
12:52 emersion: file descriptor = number for a process
12:52 emersion: file description = ref'counted kernel struct
12:52 emersion: file descriptors 42 and 43 can point to the same file description
12:52 MrCooper: doras: a file descriptor is essentially just a number to identify a file description; open() creates a new file description and returns a descriptor referencing it, dup() and friends create a new descriptor referencing the same description
12:54 doras: MrCooper, emersion: thanks.
12:56 doras: I agree that use of dup() or similar on the file descriptor would result in bad things, but I think (or rather hope) that Chromium's use of the handle/fd from GBM doesn't violate this.
12:57 doras: And as such, the solution implemented in nouveau is appropriate.
12:57 doras: Please let me know if you think I may be mistaken, I am not experienced in these areas.
12:58 MrCooper: descriptor/description thing mainly matters for DRM file descriptors (because GEM handles have a per-DRM-file-description namespace), not for dma-buf file descriptors
13:42 robclark: koike: send a MR pls.. that way I can merge it as well to run CI for msm-next
15:06 DavidHeidelberg[m]: anholt: you're the final reviewer, can you glaze eye and say if you like or dislike? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24646
15:18 koike: robclark you mean, MR for gitlab ?
15:51 robclark: koike: no, sorry, meant pull request
15:51 robclark: I assume it should land via drm-misc
17:42 karolherbst: I need that global var relocation stuff :') what a pain
18:03 alyssa:trying to figure out how to properly express this loop in NIR:
18:03 alyssa: for (int i = 0; i < 10; ++i) {
18:03 alyssa: foo(x + i, y + i)
18:03 alyssa: }
18:04 alyssa: where x and y are loop-constant but not known at compile-time
18:04 alyssa: I would like to reexpress as
18:04 alyssa: int diff = y - x;
18:04 alyssa: for (int i = x; i < (x + 10); ++i) {
18:04 alyssa: foo(i, diff + i)
18:04 alyssa: }
18:04 alyssa: saving the add inside the loop
18:04 alyssa: but when I do that, the loop fails to unroll
18:14 karolherbst: alyssa: did you check where find_trip_count bails on the trip count known thing?
18:16 karolherbst: I suspect you have to improve try_find_limit_of_alu a bit
18:16 alyssa: I didn't but ended up just special casing constant trip count entirely since I can do fun vector stuff that vectorize_load_store doesn't seem able to handle (?)
18:17 karolherbst: heh
18:17 karolherbst: but yeah, it kinda looks like that loop_analyze can't look behind code like that
18:18 karolherbst: so there might be some optimization opportunities there even
18:54 gfxstrand: jenatali: You around?
18:55 jenatali: I'm on parental leave, so, not really. What's up?
18:59 jenatali: gfxstrand: ?
18:59 gfxstrand: Oh, there's a DXIL patch in !24668 which, IMO, leaves a bit of a mess but it probably needs someone who knows the DXIL stuff to clean it up.
18:59 gfxstrand: It's fine as-is, it just leaves you with a couple weirdly similarly named helpers.
18:59 gfxstrand: It can probably be cleaned up later
19:00 gfxstrand: jenatali: ^^
19:01 jenatali: Yeah, feel free to @ me in a comment on it, or file an issue, I can clean it up when I get back since it's not urgent
19:03 gfxstrand: Okay, I'll file a quick issue.
19:06 gfxstrand: jenatali: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9566
19:06 jenatali: 👍
19:43 airlied: konstantin: you got XPass by zink-lvp
19:48 zmike: I updated and marged again for him
21:53 alyssa: nir_opt_cse is misbehaving wtf
21:53 alyssa: how is it CSE'ing from a block that never executes this is not ok
21:54 alyssa: Ooooooooooh
21:54 alyssa: ok I deserved that
22:10 zmike: ok, let it be said that while all this nir refactoring is cool the pacing of constantly landing MRs which cause every other compiler-related patch to conflict needs more thought
22:13 alyssa: zmike: we're almost done https://gitlab.freedesktop.org/mesa/mesa/-/issues/9396
22:14 zmike: okay, so then how about take the rest of the week off so people can actually land stuff
22:15 airlied: https://imgflip.com/i/7vrigb for zmike
22:15 zmike: every week is a bad week for it
22:15 zmike: eating fresh chocolate chip cookies to temper the 🤕
22:18 alyssa: for the record I am currently debugging regressions from 76725452239 ("gallium: move vertex stride to CSO") so.. nobody is innocent \shrug/
22:18 koike: robclark PR sent
22:18 robclark: ok, thx
22:25 gfxstrand:is rebasing NAK. It's "fun"...
22:26 gfxstrand: Not every commit conflicts...
22:26 alyssa: gfxstrand: :crab_dancing:
22:27 alyssa: (FWIW -- https://gitlab.freedesktop.org/asahi/mesa/-/commit/8ec4b6a58c02469116fa2721d6cce2ac7c3ef076 )
22:27 gfxstrand: It's not like the branch is 200 patches or anything
22:28 alyssa: >:D
22:43 gfxstrand: zmike: We probably should rename nir_src::ssa to nir_src::def but that's the last one.
22:43 gfxstrand: Or at least the last one with this level of impact
22:44 gfxstrand: zmike: The pacing was "try to do it all over the week-end so we conflict with people as little as possible".
22:44 gfxstrand: Since I don't like working 40h week-ends, it leaked into Monday a bit.
22:46 zmike: the pacing I'm referring to is how all these were landed with no lead-up, communication, or timetable so people could try to avoid being conflicted or even know when it would happen / how long it would last
22:48 gfxstrand: Yeah, I thought about sending a mail with like 2 weeks notice and trying to declare a NIR flag week.
22:49 gfxstrand: But that would have just caused people to freak and try to shove stuff as fast as they could and a half-dozen people would have asked for extensions and....
22:49 zmike: even sending something last week saying everyone would be conflicted over the weekend would've been something
22:49 gfxstrand: As for how long it would take: There's no way to know that until you try to do it at which point you've got a commit that touches 300 files that you really don't want to re-do and everything conflicts with it.
22:50 gfxstrand: Yeah, sending an e-mail might have been good
22:54 jenatali: Apparently I picked a good time to be on vacation
23:04 emonmeena: Hey Amazing Community! 🚀 I'm Emon Meena, proud IIT Roorkee alum and currently making waves as an A.I. engineer at IHC in the dazzling city of Dubai. Remember GSoC'21? Yep, I had the honor of being a fellow developer with Scorelab. Here's the BIG news: Along with a team of brilliant minds as passionate about tech as you are, we're forging a groundbreaking developer platform powered by ChatGPT. 🛠️✨ Curiosity piqued? T
23:07 gfxstrand: How many of those minds are just ChatGPT? (-:
23:07 HdkR: I like that IRC has message size limits so the spam couldn't quite make it through
23:08 Company: https://www.instagram.com/emon_meena/
23:11 Company: question: GL 4.6 has SPIRV support - can I share spirv between Vulkan and GL or do they need different ones?
23:11 gfxstrand: They have to be a bit different. Descriptor binding isn't quite the same.
23:12 Company: so it's not really worth it to do SPIRV on GL yet I guess
23:12 gfxstrand: IDK. IDK how people work around that
23:13 Company: is it worth doing spirv if I also have to support regular text GLSL?
23:13 Company: does it produce better code? faster startup? something like that?
23:13 gfxstrand: Really, SPIR-V for GL is really only useful if it lets you use HLSL
23:13 gfxstrand: That's the big feature
23:14 zmike: that and not having to go through mesa's painfully slow non-rust-based glsl compiler
23:14 HdkR: rusty before rust was a thing
23:15 zmike: have to imagine it'd be at least 6-8x faster in rust
23:15 airlied: we could have a slow rust-based glsl compiler instead? :-)
23:15 zmike: nah pretty sure just being rust would make it faster
23:15 Company: you could do an llvm target that produces GLSL
23:15 karolherbst: pls stop
23:16 zmike: exactly
23:16 zmike: stop writing non-rust glsl compilers
23:16 Company: how does Unity do this?
23:16 Company: they use HLSL, and they need to support GLSL
23:17 Company: do they feed spirv-cross output to Mesa?
23:17 gfxstrand: I'm not sure about Unity. Unreal embeds an entire copy of the Mesa compiler stack circa 2015. (They may have updated it. I don't know.)
23:17 karolherbst: oof
23:18 zmike: I can't even meme about that
23:18 Company: now I wonder what GL versions UE5 and Unity even require
23:18 airlied: we should just write a hlsl frontend in rust
23:19 airlied:goes to review zmike so he can screw up the nir refactors
23:19 HdkR: GL_EXT_HLSL
23:20 Company: HdkR: as long as it works on GLES2, everyone will be happy!
23:31 Company: I've been googling for 10 minutes and I still have no idea what GL version UE5 needs
23:32 Company: only that the newest features require Vulkan or DX12