08:37 hakzsam: any ideas how it's possible to break s390x builds (https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/1825698) with https://gitlab.freedesktop.org/hakzsam/mesa/-/commit/e6050cd267bdf6a707bf61ccc1d41a20818afc1d ?
08:38 hakzsam: note that removing the libdrm cross build for i386 fixes it... but break i386 build of course
09:15 MrCooper: hakzsam: very weird, looks like it breaks with any 3 or more libraries in /usr/local/lib/i386-linux-gnu/ ...; anyway, this offers a possible workaround in the meson-s390x job: rm -rf /usr/local/lib/i386-linux-gnu; ldconfig
09:38 hakzsam: MrCooper: that workaround works
09:42 MrCooper: yay
11:06 daniels: narmstrong: i gave you Reporter-level access to Mesa, so you can add tags to your MRs
12:53 narmstrong: daniels: thx
13:20 MrCooper: tanty: FYI, "@mesa" in https://gitlab.freedesktop.org/gfx-ci/tracie/tracie/-/merge_requests/38#note_427730 caused all current members of the Mesa project to get notified of that comment and any further changes to that MR
13:21 tanty: Ouch!
13:21 tanty: Sorry about that :(
13:22 tanty: At least, it was a closing comment.
13:22 MrCooper: yeah, no worries, it's arguably a bit of a mis-feature
13:30 hakzsam: the new job stages are really nice!
14:05 hakzsam: MrCooper: mind to review the fossilize work?
15:18 daniels: MrCooper: just checked the 'disable group mentions' setting
15:18 MrCooper: excellent, thanks
16:18 karolherbst: .... now we got a @all issue, fun
16:20 MrCooper: karolherbst: daniels disabled that being treated specially?
16:20 daniels: goddamnit
16:20 daniels: MrCooper: no, I disabled the project-level mention hook
16:21 karolherbst: MrCooper: I wouldn't have mentioned it if I wouldn't have gotten an email about it :p
16:21 imirkin_: does that work on their hosted gitlab?
16:21 imirkin_: i.e. gitlab.com gilab
16:22 karolherbst: imirkin_: I think it still only includes the project members though
16:22 imirkin_: ah too bad
16:22 imirkin_: i thought it was global :)
16:23 karolherbst: they probably have a gentoo fan who implemented @world :p
19:13 Lyude: seanpaul: well, I just realized why avail_payload_bw_number seemed to act so weird, I had someone check the spec and realized it doesn't actually exist - the only pbn field that's supposed to be there is avail_payload_bw_number
19:15 seanpaul: Lyude: having a hard time grokking that msg
19:16 Lyude: seanpaul: I'm referring to the cablematters hub that you and I were debugging the other day, that would randomly indicate that there wasn't any available PBN sometimes when initially probing it
19:16 seanpaul: should that second avail_payload_bw_number be total pbn?
19:16 Lyude: seanpaul: there isn't a second number
19:16 Lyude: that's what I just realized :P
19:16 seanpaul: so is there just available or just total?
19:16 Lyude: that field shouldn't be there at all
19:16 Lyude: just total
19:16 seanpaul: ahh
19:16 seanpaul: that makes sense then
19:17 seanpaul:checks the spec
19:18 seanpaul: Lyude: you're talking about the ENUM_PATH_RESOURCES reply?
19:18 Lyude: seanpaul: yep
19:18 seanpaul: i see Full_Payload_Bandwidth_Number 16-bit value
19:18 seanpaul: and Available_Payload_Bandwidth_number 16-bit value
19:19 Lyude: seanpaul: what version of the spec is that?
19:19 seanpaul: 1.3
19:19 Lyude: seanpaul: mind checking if it got added in 1.3?
19:19 seanpaul: sure
19:20 seanpaul: IIRC the Available value was either = Total || 0
19:21 Lyude: ahhh, right, and then iirc it also had an sdp stream limit of 1
19:22 Lyude: jfyi though, I think I am going to switch us to using the full_payload_bw_number though. I think in general it might be more reliable, since we'll want to be able to query PBN capabilities without needing to clear existing payload allocations to get an accurate number to use for bandwidth checking
19:22 Lyude: since it seems like avail has a lot more to do with just the current allocation state as opposed to actual bw limitations
19:26 seanpaul: Lyude: might not be a bad idea to take available if it's non-zero, i think that's what i did in my first patch
19:27 Lyude: seanpaul: didn't we check a bunch of different hubs and they had the same behavior with available_pbn though?
19:27 Lyude: e.g. available_pbn goes to 0 if more streams can't be enabled on a branch
19:28 seanpaul: i think available_pbn == 0 is a signal it shouldn't be used
19:28 seanpaul: but everything else seems valid
19:31 seanpaul: i think all of this came about because putting a display in 1.1 compatbility mode (aka non-HBR2) wouldn't be reflected when allocating bandwidth
19:31 seanpaul: what i can't remember is whether avail_pbn ended up < full_pbn in this setup
19:32 seanpaul: i'll try to repro this afternoon and see what happens
19:32 Lyude: I guess I'm not really sure what the point of available_pbn is though if it's just going to reflect what's already allocated, I guess it might be useful when initially probing if we've cleared all bandwidth allocations and available_pbn is still != 0 && < full_pbn
19:33 Lyude: seanpaul: what does the 1.3 spec say about the available PBN anyway? does it mention that it's just supposed to reflect current payload allocations?
19:37 seanpaul: Lyude: no, it reflects the lowest trained bandwidth in a path
19:38 Lyude: seanpaul: ahhhh, ok, that makes a lot of sense
19:39 seanpaul: yeah, it's a terrible name... and it does make sense, except when it goes to zero
19:39 seanpaul: i still can't square that up
19:43 seanpaul: i guess maybe it goes to 0 when there are no trained sinks (ie in power-save mode)
19:43 hakzsam: arm flakes: https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/1834892
20:08 hakzsam: arm/panfrost failures: https://gitlab.freedesktop.org/hakzsam/mesa/pipelines/116328 (can't be related to that MR)
20:11 airlied: did a retry help?
20:11 hakzsam: nope
20:20 seanpaul: Lyude: fwiw, i just instrumented enum_path_resources and degraded my display's DP version
20:20 seanpaul: both full_pbn and avail_pbn when down
20:21 seanpaul: so.... ¯\_(ツ)_/¯
20:35 anholt_: hakzsam: that's an issue with the new gitlab-runner, you have to restart the whole pipeline unfortunately
20:37 hakzsam: ok, I assigned it to Marge
20:47 Lyude: seanpaul: pardon?
20:48 seanpaul: Lyude: i was testing the theory that given a hub with HBR2 and a display with HBR(SBR?) which had a lower bw potential full_pbn could differ from avail_pbn
20:49 seanpaul: turns out they seem to be locked to each other
20:49 Lyude: seanpaul: hm, did you check if avail_pbn changes after an allocation btw?
20:50 daniels: anholt_: I don't suppose you ever saw it there was an upstream issue for that? if there was one we could push them for resolution
20:51 Lyude: that's really what I'm most concerned about here, since if it's affected by payload allocations then we probably always should be referring to full_pbn for bandwidth constraints when checking the mst state
20:51 seanpaul: Lyude: no, going off memory i don't think it does, i think we need to do query_payload and a bit of subtraction to get that
20:51 seanpaul: let's just go with full_pbn since it's reasonably well understood
20:51 Lyude: yeah
20:51 seanpaul: (ie: ignore all seanpaul scrollback today)
20:52 anholt_: daniels: never went digging for that one
20:56 Lyude: seanpaul: any chance you managed to get it to generate any RSNs by the way?
20:56 Lyude: wondering what the pbn value in there corresponds to then (full_pbn, avail_pbn?)
20:56 daniels: anholt_: if you have time to either find or file one, please tag me, @nuritzi, and @dplanella
20:57 seanpaul: Lyude: hmm, no i didn't
20:57 seanpaul: can do now
20:57 Lyude: seanpaul: if you figure out a reliable way of generating those let me know btw
20:57 karolherbst: jekstrand: can we assert on a deref_cast with ptr_stride=0? No idea if that has implications for compute shaders
20:57 karolherbst: but for kernels it will indicate bugs
20:58 jekstrand: No
20:58 jekstrand: Not all deref_casts will have a stride
20:59 karolherbst: even for CL kernels?
20:59 jekstrand: I think they will in kernel but only because the explicit types pass sets them
20:59 karolherbst: right
20:59 karolherbst: I guess I could add an assert only for kernels
20:59 jekstrand: We can assert if we see deref_array of deref_cast with stride=0
21:00 karolherbst: mhhh
21:00 jekstrand: Where are you wanting that assert?
21:00 karolherbst: yeah.. I guess that makes sense
21:00 karolherbst: because I am hitting a bug caused by a 0 stride
21:00 seanpaul: Lyude: looking at the spec for RSN, it looks like it must not be used by sinks
21:01 karolherbst: vec1 64 ssa_16 = deref_struct &ssa_15->field1 (global uint) /* &(*(struct.Node *)ssa_1)[ssa_9].field1 */
21:01 karolherbst: but the stride is 0 for ssa_1
21:01 seanpaul: Lyude: instead if the bw changes they want a CSN for disconnect and then a whole new enum_path_resources
21:01 Lyude: seanpaul: oh? where do you see that
21:01 Lyude: seanpaul: that's, actually sensible wow
21:01 seanpaul: Lyude: yeah, looks like they regret adding it :)
21:01 seanpaul: this is in 1.4
21:01 jekstrand: karolherbst: :(
21:02 jekstrand: karolherbst: Is ssa_15 a deref_ptr_as_array?
21:02 karolherbst: yes
21:02 jekstrand: Right
21:02 jekstrand: Yeah, I think asserting on ptr_as_array of cast with stride == 0 would be fine. Maybe add that to nir_validate?
21:02 seanpaul: Lyude: btw, hows the VESA membership for X.org thing going?
21:03 karolherbst: jekstrand: ohh, good idea actually. Will do
21:03 Lyude: seanpaul: I need to poke vesa again but they haven't responded, I'm actually a little worried all my email is getting filtered out as spam since the last time I talked with them they didn't receive the list of interested users, so I sent them a new list then a separate email later to see if they got it without any response
21:03 karolherbst: jekstrand: we have a working structurizer now btw :)
21:03 Lyude: I only think this because recently, gmail decided that board minutes for xorg are spam
21:04 Lyude: so it wouldn't really surprise me if other emails are getting counted as spam somewhere as well
21:04 jekstrand: karolherbst: \o/
21:04 jekstrand: karolherbst: I should probably review that...
21:04 karolherbst: jekstrand: https://gitlab.freedesktop.org/karolherbst/mesa/-/merge_requests/1
21:05 karolherbst: I wouldn't say it's ready for a proper review yet.. but if you have some time and want to take a look, feel free
21:05 karolherbst: I insisted on proper documentation so that's already covered though :)
21:06 seanpaul: Lyude: i'm guessing DMARC/DKIM is enabled for redhat.com now
21:06 Lyude: seanpaul: what are those?
21:07 seanpaul: Lyude: email magic which adds a signature to your outgoing mail, it's then verified upon receipt... if a mailing list changes your mail (ie: adds a footer, changes the subject) the message is marked failed and can be binned (<- my incorrect understanding)
21:08 Lyude: oh! that might be it
21:08 Lyude: sigh, I will poke them directly then and see if they get this message
21:09 seanpaul: good luck!
21:11 Lyude: seanpaul: btw - one last question, what's the actual docs for full_pbn say
21:11 karolherbst: jekstrand: is a nir_deref_instr_ptr_as_array_stride(parent) != 0 check good as well? would handle a bit more and I think for a ptr_as_array we realy want the stride to never be 0
21:12 Lyude: oh-got an out of office email
21:12 Lyude: i think that may have worked :)
21:14 jekstrand: karolherbst: sounds good
21:29 karolherbst: ehhh.. those casts are not inserted through nir_build_deref_cast :(
21:32 anholt_: progress on non-lava x86 runner booting bare metal boards (with no traffic to fd.o other than the driver artifacts): https://gitlab.freedesktop.org/anholt/mesa/-/jobs/1837202
21:32 karolherbst: rematerialize_deref_in_block
21:32 karolherbst: uff
21:39 karolherbst: nice, fixed
23:00 karolherbst: quick review on those patches? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4068
23:01 karolherbst: actually wondering why it didn't cause issues before
23:37 Lyude: seanpaul: a-ha! finally got a response from vesa, thanks again~
23:44 airlied: Lyude: nice