01:15 jenatali: Phoronix forums continue to be an endless source of entertainment
01:18 FLHerne: They've seen through your evil MS conspiracy again?
01:35 jenatali: Yep, again
01:44 zmike: how do they do it
02:41 alyssa: zmike: they've got a guy on the inside
02:41 alyssa: his name is Jesse and he's a sleeper agent stationed in Redmond
02:42 alyssa: but he's on the payroll of Linyos Torovoltos
02:42 zmike: sensible chuckle.gif
02:52 jenatali: Darn, I've been found out
02:57 karolherbst: you should put some EEE stickers on your laptop, just in case
02:58 karolherbst: but we all know, this is all just prep work to replace NT with Linux anyway
03:02 alyssa: how long until jenatali replaces every native DX12 driver with Dozen
03:02 alyssa: ("you're thinking of vkd3d you dink")
03:08 zmike: vkd3d-proton*
03:10 jenatali: karolherbst: I ordered my first laptop in 15 years this weekend. We'll see what stickers it gets
03:12 zmike: I didn't know you made Xboxes that small
03:12 jenatali: zmike: https://cdn.vox-cdn.com/thumbor/ZqKNL-8vbtWBRtR8-8v1Sv7JdBk=/0x0:2640x1749/1400x1400/filters:focal(1320x875:1321x876)/cdn.vox-cdn.com/uploads/chorus_asset/file/23312724/tomwarren_VLS_4561.jpg
03:13 zmike: ngl I didn't expect that but actually p cool
03:13 kisak: so ... AAA esports game on VKD3D-Proton on Dozen on WSL2 on ARM64? What could possibly go wrong?
03:16 jenatali: That's not a deep enough cycle. Needs more layers
03:16 kisak: I know, but it's a plausable future
03:17 zmike: surely we could fit zink and lavapipe in there
03:18 jenatali: Yeah for sure
03:22 kisak: slip in virtio and a linux kernel running on vscript inside of Team Fortess 2 and you've got a profoundly evil thought experiment.
03:24 kisak: it's late here, I don't see how that could actually work now that I wrote that.
03:25 zmike: you've put the idea out there, so I'm sure we'll get a bug report about it in a year or two
03:54 alyssa: gfxstrand: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20836 is blocking a bunch of asahi stuff
03:54 alyssa: It's strictly better for asahi and panfrost
03:55 alyssa: It breaks blending on panvk in main but given what we talked about internally I think that's ok right now, the fix will come as part of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20906
03:56 alyssa: supposing !20906 were merged first panvk won't care whether lower_blend happens in early or not, currently
03:57 alyssa: although if we ever did eds3 with dynamic blending, that would require generating blend shaders on the fly for certain blend modes, and it would be cheaper to do that with late blend lowering instead of early lowering (no nir_variables are ever created this way at all!)
03:57 alyssa: so it's strictly better for panvk long term too
08:52 MrCooper: jenatali: looks like ci-fairy s3cp failed?
09:09 mripard: danvet: I'm really not a fan of doing cherry-picks when we can easily avoid it, it's just super confusing
12:18 tzimmermann: javierm, hi. may i ask you for a review of https://patchwork.freedesktop.org/series/113840/ ?
13:06 javierm: tzimmermann: sure, I'll try to do it later today
13:53 tzimmermann: thanks, javierm
14:06 Lynne: is there any hardware out there which has optimizations for vulkan's immutable samplers?
14:21 jani: tzimmermann: ack for merging https://lore.kernel.org/r/20230214093459.3617293-2-arun.r.murthy@intel.com via drm-intel?
14:47 alyssa: Venemo: Thanks for the review on lower_blend, will fix the stuff you mentioned :-)
14:47 pendingchaos: Lynne: RADV can replace a sampler descriptor load with constant copies
14:47 alyssa: except the double sign-off, that was deliberate actually
14:48 alyssa: the panfrost was Collabora billable, the agx was not
14:48 alyssa: (Ordinarily wouldn't mix those up but there was no way to avoid doing so while preserving bisectability and sanity)
14:49 Venemo: alyssa: I would have assumed that Collabora's vast fortunes would pay for the 10 minutes it probably took to adjust agx
14:50 alyssa: Venemo: more to the point, the NIR was not
14:50 Venemo: not what?
14:50 alyssa: billable
14:50 Venemo: :O
14:50 alyssa: the patch was for Asahi's benefit, panfrost doesn't care right now
14:51 Venemo: okay, you can keep the double sign off if that helps keep you sane
14:51 alyssa: heh
14:51 alyssa: "sane" is not a word usually used in connection to my Mesa exploits :~P
14:52 Venemo: c'mon, don't undersell yourself
14:52 Venemo: didn't you have the highest number of commits?
14:52 alyssa: dEQP-VK.sanity.*
14:52 alyssa: NotSupported: 10/10
14:52 Venemo: ha ha ha
14:52 tzimmermann: jani, sure, go ahead
14:52 Venemo: nice one
14:52 alyssa: and I did until zmike came and decided we should stop writing GL drivers
14:53 alyssa: and I've been #2 ever since
14:53 Venemo: who is the first now?
14:53 alyssa: it's good, takes off the pressure
14:53 alyssa: zmike: all the pressure is on you, man
14:53 alyssa: :-p
14:53 Venemo: wow
14:53 alyssa: (joking)
14:54 Venemo: alyssa: regarding the case when the number of components has to be adjusted, I don't even see how it could work in the previous code without triggering validation errors
14:55 alyssa: IIRC the previous code asserted that it didn't need to be adjusted, and that assertion failed when opt_undef was run first
14:55 alyssa: but without the assertion it seems to work, maybe
14:55 Venemo: you can't just change the num components of an ssa def and call it a day
14:56 Venemo: need to either shrink the vector with nir_extract_bits or enlarge it by appending undefs
14:56 alyssa: one line up we shrink the vector with nir_trim_vectors
14:57 alyssa: though er why the heck does the store have a dest
14:57 alyssa: what is even happening on the old code
14:57 Venemo: haha
14:57 alyssa: why the hell are we touching store->dest at all
14:57 alyssa: that's
14:57 Venemo: good question
14:57 alyssa: ok, I think the real answer is that adjusting num_components manually isn't required (since it's already adjusted by nir_trim_vector)
14:58 alyssa: and the assignment in the old code is a no-op because store->dest logically doesn't exist and physically gets ignored
14:58 Venemo: right, the store doesn't have a dest so it was just a trap for me to fall into then
14:58 alyssa: let me split that off
14:58 alyssa: gotta catch up to zmike's commit count somehow
14:58 alyssa: i did not become #2 by squashing
14:59 zmike: make more spaghetti
15:00 Venemo: zmike: if I ever blog about cpu overhead perf, I'm gonna argue that pasta arrabbiata beats spaghetti any time
15:01 zmike: brave
15:05 jenatali: Is there a current chart of top committers somewhere?
15:05 psykose: yeah you hold the top 10 spots
15:06 alyssa: all 10 of them
15:06 alyssa: except for the first 9 which are held by mike
15:06 jenatali: 🥳
15:06 alyssa: and the last of the 10th which is also held by mike
15:06 psykose: shucks
15:07 jenatali: Yeah sounds plausible
15:07 alyssa: it's because we only count GL driver contributions
15:07 alyssa: but nobody writes GL drivers anymore because we all write VK drivers
15:07 alyssa: leaving Mike as the only qualifying Mesa contributor
15:08 zmike:checks the calendar
15:08 zmike: does anyone else realize it's not friday
15:08 jenatali: 🤯
15:15 jani: tzimmermann: thanks!
15:52 gfxstrand: alyssa: Yeah, that looks like a pass I could review, given that I rewrote 70% of it a while ago. 😂
15:52 alyssa: gfxstrand: and I'm deleting that 70% of it! :~P
16:22 gfxstrand: alyssa: Awesome!
16:25 alyssa: :-D
17:16 alyssa: gfxstrand: what's the right Gallium driver to look at as a reference for doing explicit sync?
17:16 alyssa: Iris? Iris + the Xe patches that havent' merged yet? something else?
17:16 gfxstrand: alyssa: Probably that or radeonsi
17:16 gfxstrand: But radeonsi is weird
17:19 daniels: radeonsi is 'weird' in the same way that Antarctica is 'cold'
17:20 zmike: Z I N K
17:21 daniels: (in the same way that Zink is 'good on tilers')
17:21 gfxstrand: :P
17:22 gfxstrand: Actually, Zink might not be a bad thing to look at there
17:22 zmike: tilers shmilers
17:26 alyssa: ..in the same way that Zink is 'especially good at WSI on tilers'
17:34 gfxstrand: alyssa: Are any of us good at WSI?
17:36 alyssa:points to gfxstrand
17:38 gfxstrand: Not me
17:47 daniels: define 'good'
17:49 gfxstrand: alyssa: Ok, dropped you a handful of simple comments on lower_blend. Looks pretty good. I'm mostly just trusting you on the panfrost and AGX bits. Glad to see all that horrible code I wrote go away. :D
17:55 alyssa: :D
17:56 alyssa: only thing I like more than deleting my code is deleting other people's code ;~P
18:03 gfxstrand: Goodness knows there's plenty of my code to be deleted.
18:03 gfxstrand: I'm like the anti-ajax
18:35 daniels: ~/mesa/mesa upstream % wc -l src/vulkan/wsi/*.[ch] | tail -1 && (for i in src/vulkan/wsi/*.[ch]; do git blame $i 2>/dev/null; done) | grep Ekstrand | wc -l
18:35 daniels: 11520 total
18:35 daniels: 3165
19:01 gfxstrand: Really? I'm not nearly as to blame for WSI as I once was.
19:01 gfxstrand: *phew*
19:04 alyssa: Lol
20:28 anholt_: hmm. Is the "pull present queue" in x11_manage_fifo_queues supposed to be quick? I'm seeing the GPU go idle during it.
20:43 ngcortes: seems like a recent mesa change caused a bunch of failures on hsw: https://mesa-ci.01.org/vulkancts/builds/29536/group/63a9f0ea7bb98050796b649e85481845
20:43 ngcortes: looks like it's somewhere in 9ac192d79dbe..6ac830ccb1a5
20:43 ngcortes: whoops sorry wrong channel
20:45 anholt_: ngcortes: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21349
21:00 MrCooper: anholt_: in some cases it waits for idle before presenting the image, see x11_needs_wait_for_fences
21:09 anholt_: would that show up as a massive stall here every 10ish (with high variance) frames?
21:11 anholt_: The needs_wait_for_fences waits show up at a nice pace, it's the pull that really idles us.
21:13 anholt_: (plug people.freedesktop.org/~anholt/zink-csgo.trace into ui.perfetto.dev to see what I'm looking at)
22:07 alyssa: gfxstrand: Weee looks like lower_blend changes hosed Midgard
22:07 alyssa: Days like this make begrudgingly grateful for CI
22:07 alyssa: (I tested only on Bifrost)
22:15 gfxstrand: alyssa: :(
22:15 gfxstrand: alyssa: Any idea why yet?
22:17 alyssa: Haven't looked
22:17 gfxstrand: kk
22:17 gfxstrand: Well, I'm pretty sure it's not my fault. :P
22:17 alyssa: 50/50 coin between "forgetting to update some Midgard-only code path somewhere" and "pre-existing Midgard compiler bug this uncovered"
22:18 alyssa: my last set of lower_blend changes uncovered a buggy Bifrost opt pass, wee
22:18 alyssa: I think, I think I work on too many instruction sets
22:18 alyssa: is 4 not the normal number of ISAs to maintain support for
22:19 alyssa: what do you guys do? only 3?
22:21 gfxstrand: Intel is 2 with different rules at every hardware version.
22:59 Lynne: finally got all my code rewritten to use descriptor buffers, then I got a gpu crash running it
22:59 Lynne: life on the bleeding edge
23:05 zmike: welcome to hell because there's no way to debug it
23:07 karolherbst: I think we have 5 ISAs already 🙃
23:07 karolherbst: nv30/tesla/fermi+kepler1/kepler2/maxwell+pascal/volta+ ohh, I guess 6 it is
23:08 karolherbst: (that look on gfxstrand's face once I submit support for all of those to NAK I want to see)
23:09 glehmann: just ignore that old hw exists
23:15 anarsoul: glehmann: but how old is old?
23:42 alyssa: karolherbst: are those actually different ISAs? not just different encodings?
23:42 karolherbst: heh.. fair question, depends on what you consider to be a different encoding and what you consider a different ISA
23:43 karolherbst: they do change stuff in weird ways, so it's not just the encoding being different
23:43 karolherbst: but things are still close enough that's not really all that different?
23:46 Lynne: for multi-element descriptor bindings, vkGetDescriptorSetLayoutSizeEXT returns the total size, right?
23:47 zmike: yeah it's the size of the layout
23:51 alyssa: karolherbst: yeah, still sounds like one ISA roughly
23:52 alyssa: when I talk about 4 ISAs I mean 4 radically different architectures spanning 3 NIR backends
23:52 karolherbst: mhhh
23:52 karolherbst: guess then we have.. 2.5
23:52 alyssa: 1 vector VLIW, 1 scalar VLIW with completely different VLIW structure and completely different instructions, 1 superscalar with similar instructions, 1 multi-issue from another vendor
23:53 karolherbst: nv30 is a vec4 ISA, nv50+ is scalar, but volta+ is so different
23:53 alyssa: yeah that counts as 3 probably
23:53 alyssa: but isn't nv30 from like
23:53 alyssa: very old?
23:53 karolherbst: yes
23:53 karolherbst: it's not part of codegen
23:53 karolherbst: :D
23:53 alyssa: 2003, yeah ok
23:53 alyssa: 3 ISAs in 20 years is a nice pace
23:53 karolherbst: everybody makes mistakes and has a vec4 isa
23:54 alyssa: Arm goes through 3 ISAs in like 6 years tops
23:54 karolherbst: yeah...
23:54 karolherbst: they do change the encoding quite often and make like changes, but usually things are staying more or less the same
23:54 karolherbst: it's just different
23:55 alyssa: and it looks like there will be another mali architecture dropping soon (per developer.arm.com resources)
23:55 Lynne: zmike: there's my problem, I thought vkGetDescriptorSetLayoutBindingOffsetEXT returned per-descriptor sizes
23:55 Lynne: err, it does, I misread again
23:55 alyssa: tbd if that's a new ISA (ugh) or just a remarketed tweak on their current gen
23:56 zmike: Lynne: it's the offset from the start of the set in the buffer
23:56 zmike: not sure if helpful, but the zink usage is all in one file and may give some ideas