04:42 llyyr: could someone take a look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39218 ?
07:15 mareko: cwabbott: let's ignore driver_location because that's a driver-specific thing that the frontend doesn't deal with
07:17 mareko: driver locations are also redundant because it should be possible to compute driver locations from a prefix bitmask of inputs_read/outputs_written in most cases
07:19 mareko: pipe_stream_output_info is only set to keep all gallium drivers working, and it's mainly used with nir_unlower_io_to_vars
07:20 mareko: it's OK to keep using variables because the GLSL compiler will do nir_lower_io unconditionally -> nir_opt_varyings -> nir_unlower_io_to_vars (if needed)
07:31 mareko: lowering lowered IO to driver-specific IO intrinsics or buffer loads/stores or shared loads/stores is what AMD drivers have been doing; let the standard lowered IO be the canonical form of IO for analysis/reasoning and optimizations, and let driver-specific intrinsics be the driver-lowered form of IO that gets translated to ISA
07:35 mareko: high-level NIR (close to source semantics) -> canonical NIR (best for analysis/optimizations) -> driver NIR (closer to ISA and still optimized by generic passes)
13:07 alyssa: I really wish gitlab wouldn't change the UI for no reason every version
13:11 alyssa: mareko: +1 on the strategy in that last message
13:57 karolherbst: I'm using driver_location inside rusticl to place kernel inputs within the byte addressed cb0 space. Though I could use location instead and make binding behave like "it's the nth argument"
13:58 karolherbst: but for most drivers it doesn't matter because it's just a load_ubo which doesn't need any of the variable infos anymore...
14:06 eric_engestrom: mesa devs: in light of various things (including collabora ci's outage and now the gitlab partial outage, but also several MRs that need more time), I'm delaying the branchpoint by a week, so instead of happening tomorrow it will be on next wednesday, january 21
14:07 eric_engestrom: I'll post a calendar update in a minute
14:07 alyssa: eric_engestrom: saved by the bell!
14:35 robclark: eric_engestrom: thx
14:38 eric_engestrom: (the calendar update is, ironically, not happening because of the gitlab issues 😅)
14:38 eric_engestrom: but given mupuf's progress report, I expect the migration will be done in probably 15-20min
14:39 eric_engestrom: hopefully once that's over, gitlab will be stable again
17:05 HdkR: alyssa: The UI is required to change for every version because it "adds value" ;)
17:15 f_: I'm glad I'm not the only one tired of GitLab changing the UI every few months
17:35 karolherbst: though it's not that different isn't it
18:00 alyssa: the labels moved
18:06 glehmann: yes, and in large projects the labels are more important than the titles, so why are they now unordered on the side
18:08 alyssa: glehmann: shareholder value
18:08 mareko: don't we get it for free anyway?
18:10 Sachiel: that means we are the product!
18:11 HdkR: ...The more you buy, the more you save?
18:13 alyssa: I kinda wonder if any other forges support ingesting gitlab ci yaml. I doubt it though.
18:43 eric_engestrom: alyssa: I looked into that last summer and no (or at least not any of the big one that we could reasonably move to; there's probably some 1-person project somewhere that does)
18:50 alyssa: eric_engestrom: tracks :(
18:53 eric_engestrom: we have unfortunately sunken too much into gitlab to reasonably move to anything else (it would take months or years of work to rebuild everything, and we'd need all the stakeholders to agree to do it before anyone could start), as much as I'd love to (as long as it's not github)
18:54 anholt: Hey folks, anyone remember what do I need to do to get a CTS patch looked at? https://gerrit.khronos.org/c/vk-gl-cts/+/18869
18:55 alyssa: rg3igalia: ^
18:59 Sachiel: anholt: add the hashtag vulkan-review (for new tests) or vulkan-bug-review, and add the vulkancts-ihv-review group to reviewers
19:07 anholt: Sachiel: thanks. khronos gerrit is so punitive.
19:08 Sachiel: can't wait for the bot to say it failed the build because clang-format
19:08 anholt: I don't get to know how it failed, so ¯\_(ツ)_/¯
19:09 Sachiel: yeah, the logs last a few days only, that's why I retriggered it
19:28 Sachiel: anholt: yup, clang-format https://jenkins.khronos.org/blue/organizations/jenkins/vk-gl-cts-buld/detail/vk-gl-cts-buld/40334/pipeline/96
19:48 karolherbst: alyssa: okay sure, but you normally never need the label page anyway, so I guess that's fine?
19:49 karolherbst: or wait.. do you mean something else..
19:51 karolherbst: mhh was it possible to have the new design in the previous version because it kinda feels like to me that nothing changed?
20:21 mareko: i wonder if SCCP would be good to have mainly for the compile times or whether it does more than we already do
23:11 sghuge: any pointers on figuring out the cross queue sync issues? I was expecting validation layer to spit out issues around sempahores if any.