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 and - Contact ARM for binary driver support!
Elpaulo1 has joined #lima
Elpaulo has quit [Ping timeout: 264 seconds]
Elpaulo1 is now known as Elpaulo
megi has quit [Ping timeout: 265 seconds]
camus has joined #lima
kaspter has quit [Ping timeout: 246 seconds]
camus is now known as kaspter
<anarsoul> enunes: sh_varying should be added to gp_submit with LIMA_SUBMIT_BO_WRITE flag since GP write into this buffer
<Danct12[m]> good morning limas
<Danct12[m]> or devs
BenG83 has quit [Ping timeout: 268 seconds]
<anarsoul> hi Danct12[m]
<Danct12[m]> how's development going?
<Danct12[m]> currently talking on a phone with a keyboard/mouse attached, with weechat running in a arch linux chroot :)
<anarsoul> slowly
<anarsoul> enunes: I see that number of BOs in bucket #8 is growing when I run refract
<Danct12[m]> about that mastermart guy, i guess that's the same guy who spammed the chat few weeks ago, right?
<anarsoul> debugging it now
<anarsoul> Danct12[m]: yes
<Danct12[m]> i wonder when freenode will be able to do something about that
<anarsoul> enunes: I think lima_bo_wait() is broken
<anarsoul> we often end up with up to 100 BOs in a single bucket
<anarsoul> and lima_bo_wait() says that BO is busy
<anarsoul> that's not right.
<anarsoul> or we don't add some BO to submit so it's never signalled
<anarsoul> :\
<anarsoul> yeah, I added lima_submit_wait(ctx->pp_submit, PIPE_TIMEOUT_INFINITE) at the end of _lima_flush() and I still see number of BOs in cache increasing
<anarsoul> but BOs are supposed to be ready.
dddddd has quit [Remote host closed the connection]
<anarsoul> oh, I think I found a bug
<anarsoul> well, couple bugs
<anarsoul> it doesn't leak anymore
<anarsoul> enunes: that should fix BO leaks:
<anarsoul> at least BO cache related :)
tlwoerner has quit [Excess Flood]
tlwoerner has joined #lima
<anarsoul> refract still dies though due to OOM but BO cache size is fixed
<anarsoul> yeah, it leaks for me with LIMA_DEBUG=nobocache
jonkerj has quit [Read error: Connection reset by peer]
<yann> anarsoul: when you say "without lima" I guess you mean still using video-modesetting on X side, but which kms driver would that be on kernel side ?
<yann> things did work with mali and armsoc btw, though it probably does not help much :)
jonkerj has joined #lima
<yann> hm, i meant fbturbo not armsoc, i'm confusing platforms :)
tlwoerner has quit [Ping timeout: 240 seconds]
tlwoerner has joined #lima
yann has quit [Ping timeout: 245 seconds]
<enunes> yann: what is your platform/soc?
<enunes> you dont need anything special on X, just the modesetting driver, whether you use lima or not
<enunes> I think what anarsoul meant is that you can use X with your display driver (sun4i-drm assuming you're on allwinner?) with software rendering
<enunes> but overall it's not hard: you enable lima and kmsro in mesa, enable lima and the display driver in the kernel, and that works
<enunes> no ddx drivers or xorg configuration, if you did any of that, I guess just remove it as it might just make it worse
yann has joined #lima
<yann> enunes: I'm on Orange Pi PC (Allwinner H3) - I didn't do any config additions myself, although there may be some lingering from the original mali-based setup
<yann> I'll review the whole meta-sunxi layer for this, and have a try with kernel 5.3
BenG83 has joined #lima
BenG83 has quit [Ping timeout: 246 seconds]
monstr has joined #lima
megi has joined #lima
<yann> testing with kernel 5.3.7, and mali module blacklisted - I still get this "AddScreen/ScreenInit failed for driver 0"
<enunes> do you have card0 and card1 and is card0 sun4i-drm
<enunes> does kmscube work
<yann> with mali loaded the cards seem to be OK - I see /sys/devices/platform/display-engine/drm/card0/ and /sys/devices/platform/soc/1c40000.gpu/drm/card1/
<yann> s/mali/lima/
<yann> in last 2 messages :}
<yann> with lima blacklisted obviously I only have card0, and that error message - currently rebuilting X with added error traces to track down the problem
<enunes> yann: sorry that just makes it more confusing, can you just not have any mali blob related things at all
<yann> yes, I have purged everything blob-related
<enunes> I think it's unlikely that tracking X with debug messages is going to be helpful in the end
<enunes> please ensure kmscube works first
<yann> well, for now I have no clue why it ends with "AddScreen/ScreenInit failed for driver 0"
<yann> even without lima
<yann> I'm following anarsoul's suggestion to make Xorg work without lima - but that does not preclude to test kmscube with another hand :)
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #lima
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #lima
<yann> on the Xorg debugging side: it's the call to drmmode_create_initial_bos() from video-modesetting's ScreenInit() that fails
camus has joined #lima
kaspter has quit [Ping timeout: 240 seconds]
camus is now known as kaspter
kaspter has quit [Ping timeout: 268 seconds]
<rellla> hi all, is a pimped version of mali_syscall_tracker and somewhat functional
<rellla> it parses vs and plbu cmd stream and also handles it, if the stream is continued at another memory address.
kaspter has joined #lima
<rellla> ideas.dump.0008 from is a good example where the stream jumps between memory blocks.
<enunes> rellla: nice, seems useful. is the goal to be possible to diff the output with the dump from lima?
<rellla> enunes: the main goal was, to make the hex dumps better to read
<rellla> imho it should be no problem to get this also into lima_dump and sync both...
<rellla> if you find this useful, i can try make a MR for mali_syscall_tracker first to get a review and then implement sth comparable for lima ...
<enunes> I'm not working on anything that needs dumps at the moment, but next time we need it it might save time to decode the dumps
<rellla> but be aware, there may be some errors or wrong assumptions in the code still... and it should probably be refactored and rebased :)
<rellla> enunes: is there any other hexdump that should/can be parsed besides vs and plbu?
<yann> enunes: right now on the 1080p screens I have at hand (not the 4K TV on which I had the linux console working yesterday) during kernel boot the HDMI output goes off and I could not get it on again - even with X disabled and lima blacklisted
<yann> in this situation, lima loaded, kmscube fails with "DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory", which seems consistent with the Xorg error
<enunes> yann: sorry I don't know how to help, I suggest you try with a working distribution to see if the overall setup works and then try to figure out differences from that
<yann> yes, probably I changed too much
<enunes> rellla: maybe pp frame regs
<enunes> rellla: but like... I don't have anything in mind for which I would need the pretty decoder for it right now, working on that would be just in case we want to take a look again in the future
monstr has quit [Remote host closed the connection]
dddddd has joined #lima
camus has joined #lima
kaspter has quit [Ping timeout: 240 seconds]
camus is now known as kaspter
kaspter has quit [Ping timeout: 265 seconds]
<enunes> anarsoul: I haven't tested the bo patches yet but hope to do it later today
<anarsoul> OK, sounds good
<rellla> the lima counterpart, we'll see fwiw ...
yann has quit [Ping timeout: 264 seconds]
<anarsoul> rellla: that's definitely useful, please send an MR for mali-syscall-tracker
dllud has quit [Read error: Connection reset by peer]
yann has joined #lima
dllud has joined #lima
<rellla> anarsoul: i will clean it up a bit and send a MR
ecloud is now known as ecloud_away
<MoeIcenowy> yann: maybe your CMA is too small
<MoeIcenowy> and you have a big FB?
<anarsoul> MoeIcenowy: yeah, likely
<anarsoul> 3840x2160 requires 66mb for 2 framebuffers
<anarsoul> I don't think that it's reasonable resolution for H3
<anarsoul> or for mali4x0
<jernej> 4k HDMI resolution works on H3 just fine, but yes, I doubt mali400 is capable of producing so big image
BenG83 has joined #lima
<anarsoul> jernej: it can do up to 4096x4096 but performance won't be good
<anarsoul> technically mali400mp2 can do 1gpix/s
<anarsoul> so up to 62fps if your program is *very* efficient
<anarsoul> but that's unrealistic target to reach
<anarsoul> MoeIcenowy: are you still working on support for 3D textures?