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!
drod has quit [Remote host closed the connection]
dddddd has quit [Remote host closed the connection]
jrmuizel has quit [Remote host closed the connection]
jrmuizel has joined #lima
jrmuizel_ has joined #lima
jrmuizel has quit [Read error: Connection reset by peer]
jrmuizel_ has quit [Remote host closed the connection]
jrmuizel has joined #lima
jrmuizel has quit [Remote host closed the connection]
jrmuizel has joined #lima
_whitelogger has joined #lima
jrmuizel has quit [Remote host closed the connection]
Barada has joined #lima
Elpaulo has quit [Quit: Elpaulo]
anarsoul has quit [Read error: Connection reset by peer]
anarsoul has joined #lima
dddddd has joined #lima
<rellla> hi, me again.
<rellla> what do i need besides to set up mali in parallel to lima?
<rellla> i'm running piglit with platform gbm btw.
<rellla> jumped over to #linux-sunxi ... :)
dddddd has quit [Quit: Hasta otra..]
<enunes> rellla: I never bothered to do that, I just flashed a very old distribution that has it to a separate card and run it on a separate board when I need
<enunes> you would need a different kernel module anyway
<rellla> i have the kernel module loaded... maybe i should do that aswal
<rellla> aswell
jrmuizel has joined #lima
jrmuizel has quit [Ping timeout: 265 seconds]
niceplace has quit [Quit: ZNC 1.7.3 -]
niceplace has joined #lima
jrmuizel has joined #lima
jrmuizel has quit [Remote host closed the connection]
dddddd has joined #lima
<rellla> enunes: which "old distribution" do you use?
<bshah|matrix> rellla: xenial should do it I think. (If that doesn't work there's always stretch xD)
<enunes> rellla: just one of the manufacturer images which is some debian I assume
<enunes> I have no idea about debian/ubuntu names
* rellla looks at armbian ...
<bshah|matrix> armbian is kinda new :P
<bshah|matrix> Go for Debian stretch
<rellla> enunes: do i need r4p0, r6p1 or r7p0 because of
<enunes> it is indeed terrible
<enunes> it has r4p0
<rellla> enunes: but i have no nanopi :)
<enunes> I guess you could hack other revisions by getting the headers from arm's kernel module, but it might also require tweaking the dump tool to account for the updated structs
<rellla> i check the web for some orange pi plus (H3) ...
<enunes> since that does have r4p0 I never bothered to try to do that either...
jrmuizel has joined #lima
Barada has quit [Quit: Barada]
adjtm_ has joined #lima
adjtm has quit [Ping timeout: 276 seconds]
<MoeIcenowy> anarsoul: looks like the colorful rendering is a timing issue
<MoeIcenowy> I added call to lima_flush() to the end of lima_draw_vbo()
<MoeIcenowy> and applied your serialization patch
<MoeIcenowy> it gets fixed
<MoeIcenowy> w/o the serialization patch it also works.
<rellla> will try that one later. dealing with blob is indeed terrible ...
<anarsoul> MoeIcenowy: then it's something that enunes was working on
<MoeIcenowy> anarsoul: what's this?
<anarsoul> rellla: just grab blobs at
<anarsoul> and use LD_LIBRARY_PATH
<anarsoul> that's what I do
<rellla> i tried that, but ...
<anarsoul> rellla: but what? works fine for me
<rellla> anarsoul: which one do you use? what platform?
<rellla> fbdev, wayland, x11?
<anarsoul> wayland
<anarsoul> wayland has libgbm and works fine with drm-only
<anarsoul> i.e. kmscube or glmark2-es-drm work fine
<anarsoul> MoeIcenowy: lima_flush() for each lima_draw_vbo() is not an option. So far sounds like multiple draws are broken
<MoeIcenowy> anarsoul: maybe it's some dependency issue?
<rellla> anarsoul: thanks, i'll give it another try. r6p2/arm64/wayland with the corrensponding kernel module ...
<rellla> anarsoul: do you also have the issue, that lima module loads when you modprobe mali?
<rellla> i have to unload it once afterwards...
<anarsoul> MoeIcenowy: no idea
<anarsoul> rellla: yes, but it's not an issue :)
<anarsoul> it fails to grab necessary resources
<anarsoul> and probe fails
<rellla> then i may call it feature :)
<anarsoul> I mean lima won't interfere with mali
<MoeIcenowy> anarsoul: but strangely add wait in a flush doesn't help at all...
<anarsoul> you mean wait for submit to complete?
<MoeIcenowy> yes
<anarsoul> I think I have a theory
<rellla> anarsoul: does piglit also work?
<anarsoul> rellla: nope.
<anarsoul> mali is gles2 only
<anarsoul> MoeIcenowy: try adding traces to u_uploader to the place when it allocates new BO
<anarsoul> I wonder several draws get split between multiple BOs
<anarsoul> maybe hw doesn't like that
<rellla> anarsoul: hm. so then there is no way to dump a piglit test atm?
<anarsoul> rewrite it in gles? :)
<enunes> MoeIcenowy: I think different issues might be fixed with the hack of adding lima_flush to the end of draw_vbo
<enunes> for example one where the gp heap is too large, adding the fix breaks it into smaller flushes and "fixes" it
jrmuizel has quit [Remote host closed the connection]
<rellla> anarsoul:; how is this one meant then :p ?
<enunes> in the case I'm debugging it seems to be a specific command that gets bugged when bundled and works when broken, but I also broke it to just a specific frame, not all frames have to be flushed
<rellla> i think i should translate that to: "write a little test program, which does the same on the GL side and see what the blob does"
<enunes> rellla: anarsoul: btw, it seems that deqp works fine for me, following what mesa CI does
<enunes> and it has a pure gles2 set of tests
<rellla> enunes: do you run it wihtin piglit or separate?
<enunes> separate, following exactly what mesa CI does
<rellla> ci source?
<enunes> I hit some pp mmu faults with it
<enunes> some infinite loops
<enunes> some assert fails that make it abort
<rellla> enunes, anarsoul: so if i succeed in setting up deqp, i can run that one with the blob?
<enunes> I didn't try that, I just thought you might have better success with it as it is actually GLES
<enunes> if what you intend to do is a full comparison lima x blob
<enunes> I did succeed running single piglit tests with the blob but I had to manually tweak the shader_test files to comply with GLES
<enunes> so it only worked for checking a single test, not for a full comparison
jrmuizel has joined #lima
jrmuizel has quit [Remote host closed the connection]
<MoeIcenowy> anarsoul: the bo change happened several flushes ago before the buggy draw
<rellla> intention is to compare them (at best a full test-set) but preferably to dump the blob
jrmuizel has joined #lima
<anarsoul> MoeIcenowy: I see
<MoeIcenowy> is clearing every vbo really not acceptable?
<anarsoul> no
<anarsoul> it's very expensive
<anarsoul> and we have to reload buffer back everytime
<MoeIcenowy> do a "flush w/o reload buffer" ?
<enunes> indeed, it is extremely expensive and will drop applications to 1fps
<anarsoul> MoeIcenowy: you can't, since whole framebuffer will be cleared
<MoeIcenowy> ah I'm trying to glmark it
<anarsoul> glmark likely doesn't make multiple draw calls
<MoeIcenowy> ah...
<MoeIcenowy> seems so
<MoeIcenowy> anarsoul: a strange thing is that the final buggy flush is not a multiple one
<MoeIcenowy> instead, the -2 flush is a stacked one with 2 draws
<MoeIcenowy> however when trying to qapitrace dump state, before the last draw the buffers are normal
<MoeIcenowy> but in the last draw, both the rendered framebuffer and the texture become abnormal
<enunes> MoeIcenowy: yeah so it sounds similar to
megi has joined #lima
<MoeIcenowy> anarsoul: oh strange... when I query the state of the call before the last draw, the flush is not stacked with 2 draws
<MoeIcenowy> instead both draw has its flush
<MoeIcenowy> maybe these two draws are problematic ones
<MoeIcenowy> oops my network connection to gitlab.fd.o is quite poor
<MoeIcenowy> that I cannot load issue 122
<MoeIcenowy> I hate gitlab's overuse of AJAX
<Tofe> piggz: so, here comes the straces
<Tofe> piggz: first, strace with working kmscube:
<Tofe> piggz: second, strace with NOT working kmscube because it appears that sometimes card0 and card1 are swapped:
<Tofe> (that's mainly FYI, because it won't help you with the blank screen issue)
<MoeIcenowy> Tofe: I think you can try to specify card manually?
<MoeIcenowy> (in fact good display server should be able to find KMS-capable card automatically and bind to the KMS-capable one)
<Tofe> MoeIcenowy: yes with -D it works well, that's the first strace
<Tofe> and my qtwayland compositor works fine
<piggz> Tofe: thx ... im gonna do a bisecting exercise on master to try and pin it down
<Tofe> good luck...
<piggz> :(
drod has joined #lima
armessia has joined #lima
<MoeIcenowy> anarsoul: I cannot find any abnormal in this stacked draw
<MoeIcenowy> anarsoul: considering lowering PP CF solves this problem, maybe the draw jobs in one flush may overlap?
<anarsoul|c> piggz: make sure you compile sun4i in kernel and lima as module to guarantee card order
<piggz> anarsoul|c: k .... but even if the order is not right, i can just specify the card eh?
<enunes> or have something like this in a modprobe config file like /etc/modprobe.d/lima.conf
<enunes> softdep lima pre: sun4i_drm sun4i_drm_hdmi sun4i_frontend sun4i_tcon sun8i_tcon_top sun4i_backend
<enunes> it ensures the module loading order
<enunes> works on other platforms too like meson, just change the module names
drod has quit [Ping timeout: 240 seconds]
drod has joined #lima
<piggz> into 4th bisect build now
embed-3d_ has joined #lima
embed-3d has quit [Ping timeout: 240 seconds]
armessia has quit [Quit: Leaving]
jrmuizel has quit [Remote host closed the connection]
jbrown has quit [Ping timeout: 246 seconds]
jbrown has joined #lima
drod has quit [Remote host closed the connection]
jrmuizel has joined #lima