01:02DavidHeidelberg[m]: robclark: too late for R-b on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24050 ;-) ?
01:06robclark: DavidHeidelberg[m]: I've not had a chance to go thru what we are dropping in terms of a630 coverage.. I guess in theory a618 coverage should make up for it but still if we aren't getting a bunch of non-marge related jobs it didn't seem like a630 was the bottleneck last time I looked, and I don't think we've taken a630 things offline recently
01:07DavidHeidelberg[m]: robclark: when we fire the testing, 4 a630 are usually "pending" and waiting for others to finish
01:08DavidHeidelberg[m]: 6 runners vs 10 jobs
01:10robclark: sure, but some jobs finish quicker than others.. the question is whether a630 jobs are the last to finish.. they weren't last time I'd been using the CI farm heavily in off-hours.. but I've not had a chance to check in last week
01:10robclark: they show up pending longer than lava runners simply because lava vs baremetal differences in queuing
01:11robclark: anyways, I've not had a chance to look into it yet which is why I haven't commented yet
01:11DavidHeidelberg[m]: what about compromise, fraction 2 and keep the skqp for now?
01:12DavidHeidelberg[m]: at least we will not spend extra time by firing more jobs than we can run in paralel
01:12DavidHeidelberg[m]: *can't
01:13robclark: do we have any breakdown of % of overhead per job (ie how much time is spent booting/etc vs running tests)?
01:14robclark: keeping same # of tests but reducing parallelism is helpful if there is a lot of overhead but not if there isn't
01:17robclark: anyways, if the overhead is not insignificant then I agree that fewer longer running jobs makes sense, but I've no idea if it is or isn't significant without doing some digging
01:17DavidHeidelberg[m]: ok, let's for now just push a530 + x11 -> wayland (which should give us a bit of extra speedup)
01:18DavidHeidelberg[m]: what do u say?
01:18robclark: yeah, I think that is not controvertial
01:19DavidHeidelberg[m]: commit dropped, rest remain unchanged
02:24Hazematman1: trying to understand this CI failure https://gitlab.freedesktop.org/Hazematman/mesa/-/jobs/45120083
02:24Hazematman1: is it failing from unexpected passes?
10:36austriancoder: Hazematman1: it is - 5x UnexpectedPass. Just update panfrost-g52-fails.txt in your commit and CI will be happy.
12:04DavidHeidelberg[m]: narmstrong: Hey, do you still have T820 running somewhere? I noticed they are disabled in Mesa3D CI for very long time
12:06austriancoder:is looking for someone with spec knowledge about "Linking of Vertex Outputs and Fragment Inputs" in glsl
12:59Hazematman1: <austriancoder> "Hazematman: it is - 5x Unexpecte..." <- Thank you :)
19:15dottedmag: What happens if an application tries to enumerate DRM objects on a leased DRM master? Will it get a full list and needs to filter it by the results of DRM_IOCTL_GET_LEASE? Will it get a filtered list (and why DRM_IOCTL_GET_LEASE exists then?)?
19:30emersion: it gets a filtered list
22:08tnt: Not sure if this is an appropriate channel (feel free to suggest a better one). I have an issue with inte iGPU using modesetting driver. If I connect a 2nd display via usb-c (and a usb-c -> hdmi dock) and configure it with xrandr, all is fine. But then if I just yank the usb-c cable, that usb-c port becomes basically "dead" until I use xrandr to disable the corresponding DP-n output (which is in 'disconnected' state now). I
22:11tnt: (oh and by "dead" I mean even pure USB devices won't work)