ChanServ changed the topic of #lima to: Development channel for open source lima driver for ARM Mali4** GPUs - Kernel has landed in mainline, userspace driver is part of mesa - Logs at https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=lima and https://freenode.irclog.whitequark.org/lima - Contact ARM for binary driver support!
Net147 has quit [Quit: Quit]
Net147 has joined #lima
buzzmarshall has quit [Remote host closed the connection]
chewitt has quit [Quit: Zzz..]
chewitt has joined #lima
cwabbott has quit [Quit: cwabbott]
cwabbott has joined #lima
Barada has joined #lima
Barada has quit [Quit: Barada]
<rellla> anarsoul, enunes: i don't have such a script, but i don't have that much errors, too.
<rellla> iirc http://imkreisrum.de/deqp/lima_master..e61a988.master..e61a988.head/ this is one of my most recent results
<rellla> 80 fails + the 5 that have to be skipped
<rellla> and at least the 12 shaders.indexing tests are caused by a GP bug, that leads to hitting the 512 instructions limit.
<rellla> many of the rest overlap with mali fails iirc
chewitt has quit [Quit: Adios!]
<daniels> narmstrong: right - we dealt with that by prioritising Mesa jobs above KernelCI jobs, since KCI is non-time-critical post-merge, and Mesa is time-critical pre-merge
<daniels> narmstrong: we did quite a lot of work on LAVA kernel/rootfs/image generation to make it more efficient, but I think maximal efficiency would probably want a local cache, so that's probably more infrastructure than you'd want
<rellla> another userspace question: why does glReadPixels work, but mapping the bo doesn't ? https://github.com/rellla/softhddevice-openglosd/blob/opiplus-gles_surface/openglosd.cpp#L998
<daniels> rellla: missing glFinish()
<rellla> daniels: doesn't eglSwapBuffers implement that?
<daniels> rellla: no
<daniels> eglSwapBuffers simply places an 'implicit sync' point
<daniels> (and explicit sync if you ask for a fence)
<daniels> when you do that and submit the BO to KMS, KMS will want on that sync point to complete
<daniels> gbm_bo_map will not
psydread has joined #lima
<rellla> daniels: ok, so when i don't gbm_bo_map but submit the BO to KMS (which should be my next step) eglSwapBuffers is enough?
<narmstrong> anarsoul: for lima we have 2xsun50i-h5-libretech-all-h3-cc 3xmeson-gxl-s905x-libretech-cc and 2xmeson-gxm-khadas-vim2
<daniels> rellla: yep!
<narmstrong> daniels: seems it's not enough, the lava slaves still gets overflowed, the best would be to have some dedicated MESA lava slaves at some point
<daniels> narmstrong: fair enough
<rellla> i feel, i'm missing something still...
monstr has joined #lima
Barada has joined #lima
<rellla> i think i solved it ...
Barada has quit [Quit: Barada]
_whitelogger has joined #lima
kaspter has quit [Ping timeout: 265 seconds]
kaspter has joined #lima
<rellla> what is wrong, if gbm_bo_map returns EBUSY ?
<rellla> .. as errno
<rellla> guess it was a duplicate eglSwapBuffers ...
<anarsoul> rellla: guess you need to wait for a fence?
monstr has quit [Remote host closed the connection]
<rellla> anarsoul: guess you are right, though i don't do drm atomic commits yet
<anarsoul> then glFinish()? :)
<anarsoul> I think you need some explicit sync, otherwise there's no guarantee that BO is not used by some job atm
<rellla> yeah, but i don't think thats an issue atm. lets see if it occurs again. though next will be drm/kms and therefore i need it ...
<rellla> ...maybe i will fix the drawing issues before :/
<rellla> anarsoul: btw, i have a regression with deqp and current mesa. will bisect tomorrow to see if its a real regression or a hidden lima bug...
<anarsoul> sounds good
gcl_ has joined #lima
gcl has quit [Ping timeout: 240 seconds]
buzzmarshall has joined #lima
Elpaulo has quit [Quit: Elpaulo]
cwabbott_ has joined #lima
cwabbott has quit [Ping timeout: 272 seconds]
cwabbott_ is now known as cwabbott