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!
ninolein has quit [Ping timeout: 264 seconds]
ninolein_ has joined #lima
<nerdboy> okay, apparently i should not have been using the latest mesa release...
<nerdboy> i finally noticed (in a libre-elec pull request) i needed newer mesa
<anarsoul> nerdboy: use mesa master
<anarsoul> using releases isn't a good idea
<nerdboy> although when it's working for egl/gl apps the xorg log still has some dri2/glamor issues...
<anarsoul> nerdboy: wait a day or two and retry, xorg won't have glamor issues after pp cf branch merges
<anarsoul> (it doesn't mean that it's bug-free though :))
<nerdboy> i did iv&v for a long time... nothing is bug free...
<anarsoul> :)
<nerdboy> anyway, right now i just needed a working X/gl env to verify the browser builds actually work
<anarsoul> browser probably won't work
<nerdboy> midori/epiphany/firefox all green now
<anarsoul> oh, OK
<anarsoul> I doubt that they use any GL though
<nerdboy> they didn't run correctly (or at all for firefox) until i sorted out the mesa/X stuff
<anarsoul> disabled glamor (and thus glx)?
<nerdboy> first round got built with opengl enabled, then i switched to gles2
<nerdboy> this is gentoo on arm64 (testing on meson gxbb and pinebook, building on kevin)
<anarsoul> cool
<nerdboy> also ff/webkit won't build for crap with less than 4 GBs ram anymore
<anarsoul> :)
<anarsoul> modern browsers
<anarsoul> *sigh*
<nerdboy> i didn't expect clang build of ff to be smoother than gcc either
<anarsoul> nerdboy: anyway, if you're using lima stick to latest mesa master
<nerdboy> that's what foo-9999 ebuilds are for
<anarsoul> I haven't used gentoo since 2009
yuq825 has joined #lima
<nerdboy> so far the meson board (mali 450) seems to work "better" if a blacklist the lima kernel module
<nerdboy> s/a/i/
<anarsoul> nerdboy: it means that you're not using lima :)
<nerdboy> it's using mesa lima
<anarsoul> yuq825: enunes: folks, please review
<nerdboy> afait anyway...
* nerdboy looks for the dangling "c"
<nerdboy> with meson/lima/panfrost all as kernel modules, X/mesa can't pick the right dri card without that snippet of config
<nerdboy> *meaning meson/lim/panfrost *drm* kernel modules...
<nerdboy> without the blacklist the meson drm module pulls in lima/gpu_sched
<yuq825> anarsoul: sorry, my review is always disturbed in the past few days, I can try again this evening
<nerdboy> modesetting/fbdev creates a different X config depending on whether lima drm gets loaded or not
Da_Coynul has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
jrmuizel has joined #lima
jrmuizel has quit [Ping timeout: 272 seconds]
dddddd has quit [Remote host closed the connection]
yuq8251 has joined #lima
yuq825 has quit [Remote host closed the connection]
<anarsoul> nerdboy: userspace driver needs its kernel space counterpart, so if you blacklist lima module userspace isn't able to talk to hardware
<nerdboy> are you saying i should blacklist meson drm instead?
<bshah|matrix> DRM driver and graphics driver are different thing
<bshah|matrix> So keep both meson and lima drivers
<nerdboy> that seems to be confusing xorg...
<bshah|matrix> It tries to use render node?
<nerdboy> without some config snippet modesetting chokes with a drmsetmaster error and X doesn't start
<nerdboy> lemme "free" the modules and get a log
<anarsoul> I have sun4i built-in so it's always first card
<nerdboy> this is the odroid clone
<nerdboy> er, nanopi-k2
<bshah|matrix> anarsoul: ahaa, that's neat trick
<nerdboy> <= default xorg config, mesa git
<nerdboy> this snippet sorts it out a bit:
<nerdboy> <= happy xorg log
<nerdboy> nanopi in a pitop ^^
yuq8251 has quit [Ping timeout: 244 seconds]
megi has quit [Ping timeout: 268 seconds]
smaeul has quit [Ping timeout: 252 seconds]
Barada has joined #lima
yuq825 has joined #lima
smaeul has joined #lima
<wens> [ Option "AutoAddGPU" "off" ] should be enough to prevent X from using lima as a display
<wens> (which of course it can't do)
Barada has quit [Quit: Barada]
minecrell has joined #lima
Da_Coynul has joined #lima
Barada has joined #lima
yuq825 has quit [Remote host closed the connection]
Da_Coynul has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
Da_Coynul has joined #lima
Da_Coynul has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
kaspter has quit [Quit: kaspter]
Barada has quit [Quit: Barada]
Barada has joined #lima
Barada has quit [Quit: Barada]
kaspter has joined #lima
enunes has quit [Ping timeout: 248 seconds]
dddddd has joined #lima
enunes has joined #lima
robher has quit [Ping timeout: 250 seconds]
lvrp16 has quit [Ping timeout: 250 seconds]
smaeul has quit [Ping timeout: 250 seconds]
MoeIcenowy has quit [Ping timeout: 250 seconds]
robher has joined #lima
lvrp16 has joined #lima
MoeIcenowy has joined #lima
smaeul has joined #lima
kaspter has quit [Ping timeout: 264 seconds]
megi has joined #lima
kaspter has joined #lima
kaspter has quit [Remote host closed the connection]
cwabbott has quit [Read error: Connection reset by peer]
kaspter has joined #lima
cwabbott has joined #lima
<nerdboy> yeah, the "good" log still has "(WW) modeset(0): Option "PrimaryGPU" is not used"
<nerdboy> hmm, without the second part i get a long string of "(EE) FBDEV(1): FBIOPUTCMAP: Device or resource busy" and then "AIGLX: Screen 1 is not DRI2 capable"
kaspter has quit [Ping timeout: 264 seconds]
<anarsoul> nerdboy: it's Xorg bug, not mesa or lima
kaspter has joined #lima
kaspter has quit [Quit: kaspter]
jernej has quit [Remote host closed the connection]
jernej has joined #lima
<anarsoul> enunes: any chance that you'll have some time today to review pp cf MR?
<enunes> anarsoul: ok I'll comment there today
<enunes> anarsoul: I think I see a bug in spilling which may or may not affect the reg pressure stuff or ideas, let me give it a try...
<anarsoul> enunes: I think you're overcomplicating
<anarsoul> just use u_upload and allocate spill stack per draw
<anarsoul> once we implement BO cache performance impact will be negligible
<enunes> anarsoul: I totally agree and I don't like that solution too much either
<enunes> at this point I just want to get something that fixes that bug so I'm just trying to get the proposed solution right
<enunes> I believe my initial solution which was to just allocate a buffer per fs would be much simpler, however I think yuq sees some way in which it wouldn't work
<anarsoul> so why not to allocate it with lima_ctx_buff_alloc()?
<enunes> I don't know either, I took it out of ppir_screen at first but yuq suggested to keep it there
<anarsoul> it's really part of context, not screen
<enunes> I don't want to refactor it once again in this same MR
<anarsoul> oh
<anarsoul> 5 min...
<enunes> and re-test of course
<enunes> lets see if a quick attempt goes somewhere...
<anarsoul> would that work?
<anarsoul> (not even compile tested, sorry)
<enunes> if I understand correctly no because if you add multiple shaders for 1 flush, every one may have a different ctx->fs->stack_size so we really need to record the largest one
<enunes> pp_buffer_size 0x400 per pp per core is something we got from the blob
<enunes> sorry, 0x400 per element in the stack per pp/core
<enunes> what is the effect of the last parameter to lima_ctx_buff_alloc ?
<enunes> or, the difference between u_upload_alloc and u_suballocator_alloc
<anarsoul> yes
<enunes> what is the difference?
<enunes> we don't have anything to upload, so suballocator?
<anarsoul> yeah, that'll work if u_suballocator_create() was called with large enough size
<anarsoul> currently it's 1mb
<anarsoul> that's 128 temporaries for mali450mp8
<anarsoul> I'd say it's reasonable size limit
<enunes> u_upload_create also seems to be default 1mb, but I think it resizes?
<anarsoul> yeah, u_upload resizes if object doesn't fit
<anarsoul> u_suballoc just fails
<anarsoul> (so don't forget to limit spill attempts if you're going to use suballocator)
<enunes> can you post a comment in that MR proposing this
<anarsoul> I already did half an hour ago
<enunes> yeah it's just in a thread that I'm about to 'mark as resolved' with the code change
<anarsoul> OK
Da_Coynul has joined #lima
Da_Coynul has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]