ChanServ changed the topic of #lima to: Development channel for open source lima driver for ARM Mali4** GPUs - Kernel driver has landed in mainline, userspace driver is part of mesa - Logs at https://oftc.irclog.whitequark.org/lima/
camus has joined #lima
camus has quit [Remote host closed the connection]
camus1 has quit [Ping timeout: 480 seconds]
camus has joined #lima
camus has quit [Remote host closed the connection]
camus has joined #lima
camus1 has joined #lima
camus has quit [Ping timeout: 480 seconds]
camus1 has quit [Remote host closed the connection]
camus has joined #lima
camus1 has joined #lima
camus has quit [Ping timeout: 480 seconds]
camus has joined #lima
camus1 has quit [Ping timeout: 480 seconds]
camus1 has joined #lima
camus has quit [Ping timeout: 480 seconds]
camus1 has quit [Remote host closed the connection]
camus1 has joined #lima
camus1 has quit [Remote host closed the connection]
camus has joined #lima
camus has quit [Remote host closed the connection]
camus has joined #lima
tlwoerner has quit [Read error: No route to host]
camus has quit [Read error: Connection reset by peer]
camus has joined #lima
tlwoerner has joined #lima
camus1 has joined #lima
camus has quit [Remote host closed the connection]
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
jernej has joined #lima
jernej has quit [Remote host closed the connection]
jernej has joined #lima
<enunes> CI getting in good shape again, finally getting some passing results https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11789
<anarsoul> great!
<anarsoul> actually I'm pretty surprised that lima didn't regress even without CI for over a year :)
<anarsoul> btw, do you think it makes sense to split the job across 4 runners?
<enunes> I have 3 boards that can run in parallel, I was suggested to make it parallel: 4 so that other lava setup can run in parallel even if 3 boards are busy
<anarsoul> does it reduce job runtime though?
<enunes> but I'm thinking just parallel: 3 might be better, the board setup takes quite a while of that time and it probably doesnt pay off the time to add more deqp tests to each job
<anarsoul> IIRC deqp run on a single machine is under 4 mins
<enunes> right now it is taking around 3:50 which seems pretty good
<enunes> I can give it a try with no parallel or 3 to get a better idea
<anarsoul> yeah, I wonder if it's better to have more runners available than keeping them busy with a single job that is split across all the runners