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!
mardikene193 has joined #lima
<mardikene193> you are kind of wondering how is that golden sometimes hated boy still going in the big stuff, the answer is fathers love, i have exceptionally supporting and strong father.
<mardikene193> i would had fallen, but this way as he supports me to the last minute than it is much more difficult to fall off the cliff, we have had our arguments but he is my biggest fan.
<mardikene193> Me myself i had a privilege to study hardwares code, which is so elegant that it may even bring tears to the eyes, I see very smart people participating in technology, even though it may seem different, i give more credit back to human knowledge rather than this being my personal skill only
<mardikene193> Maybe someone requests the mathematical expression, So i leave the link here as well, which I talked about.
<mardikene193> one of many, but this is still among the best links that i have seen, being shorter and more expressive version, they actually have libraries for cuda doing very interesting show off about the queues
yuq825 has joined #lima
kaspter has joined #lima
<mardikene193> And i do get respect as computer scientist daily basis, rather small field of research inside the all science and research done by others though
<mardikene193> it is quite so that on the net if we adjust to current situation, everything can be easily researched
<mardikene193> science has all gathered to the network internet those days
<mardikene193> just to mention I have big expectations about allready something new and superior chips in many ways, the old transistor based chips have been also designed in best possible way
<mardikene193> i have done some reasearch in mixed signal analog digital in logic mram memristor based circuits
kaspter has quit [Quit: kaspter]
<mardikene193> and how much sense i have suprisingly made under hugest pressure, I comment on also, there is not so much pressure involved when daddy have guided me all the time, that is why i have managed to hang or cling on
<mardikene193> I have not faced issues where i risk as much as you or those who do not have supporting family, hope to not alienate though and start doing big things my own also
kaspter has joined #lima
<mardikene193> I hold my index finger up, that i have made it, you can confirm my theories with simulators and via the link i provided
<mardikene193> what i have been talking about is very accurate information actually
<mardikene193> losses are part of competition and life, plaes would just have to tolerate me playing on more important way and better for time being, i have not much against him, but maybe he just feels a little knocked down , it is how it is, i showed pretty strong hand in a debate in technology
marcodiego has quit [Quit: Leaving]
<mardikene193> I never will be put to institution of mental kind anymore, cause to those morans i delivered everything when it mattered, showing that i am not mentally ill personality
<mardikene193> if those blokes see hallucinations i can only tell they do, but i do not
jrmuizel has quit [Remote host closed the connection]
<mardikene193> in the interest of my home nation and people, I leave the situation as is, that morans who doubted about me and doing big statements about my mental illness got owned
<mardikene193> and morans like that need to be
<mardikene193> in human evolution i am so much in front that it seemed to be overkill such morans talking about my issues of thinking, cause i outpowered them always, as youngester as now and in the future
<mardikene193> so lets agree on it: so clueless people just can not anymore make statements about me, ok?
<mardikene193> people who do not share any common sense
mardikene193 has quit [Quit: Leaving]
dddddd has quit [Remote host closed the connection]
<anarsoul> yuq825: hi
<yuq825> anarsoul: hi
<anarsoul> looks like we're allocating a lot of buffers in lima with lima_resource_create_scanout()
<anarsoul> and these are contiguous and are allocated from CMA pool
<anarsoul> I think it's redundant in many cases since only compositor or X11 needs a scanout that has to be passed to display driver
<anarsoul> do you have any ideas how it can be optimized?
<yuq825> window buffer maybe scanout (full screen), so it's created like this
<yuq825> this is mostly depend on display server implementation
<yuq825> I think to solve this display server should be aware two dri devices instead of mesa fake
<anarsoul> I guess we should cache BOs created by kmsro as well
Barada has joined #lima
<yuq825> kmsro BOs should be much stable than lima BOs
<yuq825> so cache may not help
<anarsoul> but fixing all the compositors to be aware of render-only GPUs is not feasible
<bshah> what kind of fixes compositors would require?
<MoeIcenowy> anarsoul: the problem is that we do not have cross-process cache
<anarsoul> that should be done in kernel driver
<anarsoul> but I don't think it's necessary
<MoeIcenowy> but I don't think the scanout buffers a severe problem now
<MoeIcenowy> for me the bigger problem is lima non-contigous memory allocation failure
<yuq825> so you meet lima bo alloc fail, not kmsro?
<MoeIcenowy> yes
<MoeIcenowy> shmem_alloc_page failure
<MoeIcenowy> not CMA failure
<yuq825> is system out of or short of memory at that time?
<MoeIcenowy> also it might be possible that I have a too big CMA -- 200MiB
<MoeIcenowy> yuq825: no, around a half memory is free
<yuq825> how to reproduce?
<MoeIcenowy> just start GNOME session
<yuq825> wayland or x11?
<MoeIcenowy> X11
<MoeIcenowy> both GDM and final session are X11
<MoeIcenowy> yuq825: and it sometimes lead the process to signal 6
<MoeIcenowy> I will attach a dmesg snippet to pastebin
<MoeIcenowy> yuq825: https://pastebin.aosc.io/paste/T14F30h-v1gDLeTgh8Qg9g here's the log currently
<anarsoul> it ran out of GFP_DMA32
<MoeIcenowy> anarsoul: then why it says `DMA32 free:206236kB`
<anarsoul> hm
<MoeIcenowy> also, don't forget I'm on Allwinner
<anarsoul> no idea
<anarsoul> yeah, I'm on allwinner as well
<MoeIcenowy> every memory byte has a 32-bit address ;-)
<MoeIcenowy> except for the ones that are totally not accessible
<anarsoul> I know
<anarsoul> MoeIcenowy: that's weird
<MoeIcenowy> by checking zoneinfo, Normal and Movable zones are totally empty
<yuq825> you may try adding some flags here
<yuq825> like other drm drivers
<anarsoul> latter improves picture quality for HD videos in mpv
<yuq825> ok
<anarsoul> since it allows to use varying directly as sampler coords and it doesn't lose precision
<MoeIcenowy> anarsoul: oh you made some new thing
<MoeIcenowy> oh interesting partial update is merged
<yuq825> MoeIcenowy: how about GFP_USER | __GFP_DMA32 | __GFP_RETRY_MAYFAIL | __GFP_NOWARN ?
hoijui has joined #lima
<bshah> yuq825: about partial update, do you have link to weston patch?
<bshah> nvm found it
hoijui has quit [Ping timeout: 264 seconds]
hoijui has joined #lima
mardikene193 has joined #lima
hoijui has quit [Quit: Leaving]
megi has joined #lima
yuq825 has quit [Quit: Leaving.]
yuq825 has joined #lima
mardikene193 has quit [Quit: Leaving]
<MoeIcenowy> yuq825: why changed to USER?
<yuq825> just mean can map to user, see the comments about GFP_USER
<MoeIcenowy> oh^
<MoeIcenowy> looks like using GFP_KERNEL is totally wrong here?
<MoeIcenowy> (because BO is meant to be used by Mesa
<MoeIcenowy> yuq825: BTW what's the difference between GFP_DMA32 and __GFP_DMA32
<yuq825> same thing
<yuq825> you can see other drm driver like use GFP_HIGHUSER
<yuq825> it's GFP_USER | __GFP_HIGHMEM
<MoeIcenowy> yuq825: it helps
<MoeIcenowy> yuq825: make a patch for it?
<MoeIcenowy> but maybe we shouldn't place NOWARN?
<yuq825> yes please, NOWARN comes from etnaviv and gem_helpers, I don't know why but better follow them
dddddd has joined #lima
<yuq825> MoeIcenowy: remember to add fixes tag and cc stable kernel, this fix can be backported to 5.2 and 5.3
jrmuizel has joined #lima
jrmuizel has quit [Remote host closed the connection]
yuq825 has quit [Quit: Leaving.]
yuq825 has joined #lima
Barada has quit [Quit: Barada]
jrmuizel has joined #lima
yuq825 has quit [Quit: Leaving.]
megi has quit [Ping timeout: 265 seconds]
<MoeIcenowy> anarsoul: for the PP mmu fault, by replaying apitrace, I found a trace and the glDrawArrays call that triggers the fault
<anarsoul> cool
<anarsoul> is it reproduceable?
<MoeIcenowy> do you want the trace?
<MoeIcenowy> I can try to share it somewhere
<MoeIcenowy> is a few megabytes
<anarsoul> please open an issue on https://gitlab.freedesktop.org/lima/mesa/issues and attach it there
<anarsoul> I wonder if it's the same issue as https://gitlab.freedesktop.org/lima/mesa/issues/122
<MoeIcenowy> I assume it's reproducible, because I replayed the bad frame for 3 times
<MoeIcenowy> anarsoul: in my case it's GPU crash
<anarsoul> you mean ppmmu fault?
<MoeIcenowy> yes
<MoeIcenowy> and the GPU can no longer render further images
<anarsoul> that's not a crash :)
<MoeIcenowy> it's stuck to a few frames
<anarsoul> it just ignores subsequent jobs for this context
<MoeIcenowy> context crash ;-)
<anarsoul> so your app flips its buffers back and forth
<MoeIcenowy> ah, it's not my app
<MoeIcenowy> it's GNOME
<anarsoul> I mean the app that you're running
drod has joined #lima
<rellla> \o/ forget it :)
anarsoul has quit [Remote host closed the connection]
anarsoul has joined #lima
drod has quit [Read error: Connection reset by peer]
drod has joined #lima
<Tofe> oh, nice, so far with latest lima I get near perfect rendering
<Tofe> I'll do a little video, let's not always point the bad news :)
<anarsoul> rellla: nice catch!
<bshah|matrix> Oh now that you mention it, https://youtu.be/NylQggIDk-w something Lima devs would also like :)
<bshah|matrix> Plasma mobile running on pinetab using lima-next branch
<Tofe> bshah|matrix: nice :)
<rellla> anarsoul: no, no nice catch. swap_args is totally right as is.
<anarsoul> so what issue you tried to fix?
<rellla> my head burned because i was trying to fix several piglit tests which seem to be caused by wrong abs handling.
<anarsoul> actually your fix looks correct to me
<rellla> i tried fixing them by lowering the modifier to mov or sqrt(x * x)
<anarsoul> oh, it's not
<rellla> the latter is what the blob does
<anarsoul> a < b is equivalent of b > a
<anarsoul> so yeah, lt => gt
<anarsoul> le => ge
<rellla> yeah, as i said :)
<rellla> and because the shader code looked correct to me, i search for another possible issue ...
<rellla> will continue tomorrow.
<rellla> btw, we should use atan directly
<anarsoul> rellla: I don't think that nir has an op for that
<anarsoul> but we can add it
<anarsoul> that's a bit more work and I don't think that a lot of shaders use atan :)
<rellla> it's not top priority imho
jrmuizel has quit [Remote host closed the connection]
<anarsoul> MoeIcenowy: I have strong suspicion that your bug can be fixed with https://gist.github.com/anarsoul/c8be602efa72542e5cae121048679d80
<anarsoul> can you try it?
niceplace has quit [Quit: ZNC 1.7.3 - https://znc.in]
niceplace has joined #lima
megi has joined #lima
jrmuizel has joined #lima
jrmuizel has quit [Remote host closed the connection]
jrmuizel has joined #lima
<rellla> cwabbott: iirc a time ago you told me, that in pp some ops can't deal with abs/neg modifiers. do you have more detailed info on that?
<rellla> i'm about to sort out some failing piglit tests and think in some cases this could be the issue.
armessia has joined #lima
<anarsoul> rellla: try to feed simple shader with these to mali offline compiler and see what it does?
<anarsoul> (you can use standalone disassembler that was recently added to analyze mbs binaries)
jrmuizel has quit [Remote host closed the connection]
armessia has quit [Quit: Leaving]
drod has quit [Remote host closed the connection]
niceplace has quit [Read error: Connection reset by peer]
niceplace has joined #lima
jrmuizel has joined #lima
jrmuizel has quit [Remote host closed the connection]