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!
jrmuizel has quit [Remote host closed the connection]
jrmuizel has joined #lima
jrmuizel has quit [Remote host closed the connection]
jrmuizel has joined #lima
jrmuizel has quit [Remote host closed the connection]
dddddd has quit [Remote host closed the connection]
megi has quit [Ping timeout: 240 seconds]
Barada has joined #lima
jailbox has quit [Remote host closed the connection]
yuq825 has joined #lima
libv has quit [Ping timeout: 240 seconds]
libv has joined #lima
yuq825 has quit [Quit: Leaving.]
jailbox has joined #lima
kaspter has joined #lima
adjtm_ has quit [Ping timeout: 240 seconds]
deesix has quit [Ping timeout: 240 seconds]
deesix has joined #lima
robertfoss has joined #lima
<robertfoss> are there any good kernel dts files to have a look at how lima should be exposed?
<bshah|matrix> a64.dtsi might be good place ^^
<robertfoss> bshah|matrix: in linux/master?
<robertfoss> bshah|matrix: excellent, thanks for the pointer
adjtm_ has joined #lima
<bbrezillon> anarsoul: not sure you've been following the discussion around https://gitlab.freedesktop.org/mesa/mesa/commit/19546108d3dd5541a189e36df4ea83b3f519e48f (only yuq was Cc-ed, and he's apparently not on this chan)
<bbrezillon> anarsoul: looks like the core implem of partial_update() is buggy, and I was wondering if we could revert the change until we find a solution for the problem
<bbrezillon> the other option would be to only disable it for panfrost, but if it's buggy for us, it also is for lima
monstr has joined #lima
yuq825 has joined #lima
deesix has quit [Ping timeout: 265 seconds]
deesix has joined #lima
adjtm_ has quit [Quit: Leaving]
adjtm has joined #lima
dddddd has joined #lima
yuq825 has quit [Quit: Leaving.]
megi has joined #lima
warpme_ has joined #lima
adjtm has quit [Ping timeout: 240 seconds]
jrmuizel has joined #lima
jrmuizel has quit [Remote host closed the connection]
adjtm has joined #lima
jrmuizel has joined #lima
kaspter has quit [Quit: kaspter]
mardikene193 has joined #lima
<mardikene193> I have somewhat defended my theorem! I simulated three days very small but highly strategical part of the chip! There are many funky appareances i expect you not being able to read it yet, until i fix the looks a bit, it is just i am so tired at the moment.
<mardikene193> I need to take a break, but there is too much work to do yet, hardware is so complex, that i am not as big genius and i am throuhgly astonished that men/women like that have lived to design something like that.
<mardikene193> I feel very delighted to have enough of some GODs powers to have identified the method to run the queues on GPUs, however it may seem I am not the first one to conclude that still But such a show off is very rare still. So I am somewhat special guy still.
<mardikene193> But indeed I am aware that there are bigger talents even, and a great pile of them working every day to do similar magic.
<mardikene193> connor i mean cwabbott i really like your touch and documents , i would also though want to make additions to them, but techinically you are a genius, but still reading hw should blow your mind yet :)
<mardikene193> well in the output you see toggling on the next_hungry marked timeline, that it only passess through the second instructions in consequently in program order, to make a column switch in the queues
<mardikene193> i can make it more readable, but i was being lazy and drinked yestirday a bit, that should include making top testbench wrappers for other modules too to get rid of some X's
<mardikene193> but it is to me allready concludably readable as it is at the moment too
Barada has quit [Quit: Barada]
<mardikene193> I actually have helped you in mad amounts every time you get into troubles in undertandings, it would be the time for some appreciations from clownes and memes but they as totally stupid pranksters won't ever get there even.
<mardikene193> And yeah there are some ranty ramblings inside all of us, especially under pressure things boil up in such way. You just concentrate to those occations where i have been spot on, where there are many of those accurate talks too, I am going more accurate with every day, my eyes get painful too.
<mardikene193> as a matter of fact i am visiting a doctor to control my eye and sight and vision.
<mardikene193> I am aware of the importance in computing of that rediscovery, no matter what you try to say to me, i know I carry one of the most important roles those days.
<mardikene193> rawly said as those people who humiliated in the past during those fiasco days, their interaction is way too weak, so you have not gathered much respect in doing so, as you may have noticed.
<mardikene193> if you have not scored in legal events in the past heavy, all of the sudden and or out of the blue, you can not show up as someone else like a master in legal events either, such things just won't happen oftenly.
<mardikene193> Shaun Murphy had bad seosons after his first world championship award/medal there was bigger chanche seen by me that he gets back on form on another day in life again, but out of the blue heros only based of humiliation events do not really appear.
<MoeIcenowy> anarsoul: BTW I confirmed that the light source of glmark2 ideas is misrender as the same as my situation
<mardikene193> those who have had internal content are marked and known.
<MoeIcenowy> flush each time draw fixes it, but makes ideas very very slow
monstr has quit [Remote host closed the connection]
<anarsoul> bbrezillon: I've just got home yesterday night, and haven't seen it yet
<anarsoul> thanks for pinging me
<anarsoul> MoeIcenowy: maybe
mardikene193 has quit [Quit: Leaving]
kaspter has joined #lima
<MoeIcenowy> anarsoul: from the log of apitrace
<MoeIcenowy> looks like that only the failing shader is spilling
<MoeIcenowy> `80 inst, 1 loops, 10:28 spills:fills`
<MoeIcenowy> when trying ideas
<MoeIcenowy> and it's a sampler-less shader
<MoeIcenowy> so it should not be texture issue
<anarsoul> yeah
Kwiboo has quit [Ping timeout: 240 seconds]
<anarsoul> it's likely a shader issue
<anarsoul> we discussed it a lot during XDC
<anarsoul> but so far we've got no solution yet
<anarsoul> MoeIcenowy: it can also be CF issue
<MoeIcenowy> CF is inside shader
<anarsoul> I mean it's either CF or spilling
<MoeIcenowy> yes
<MoeIcenowy> let me try my lowering
<MoeIcenowy> ah to be honest I think my commit to move CF lowering code should be merged, although it's not needed now on lima
<MoeIcenowy> oh the shader of ideas is complex enough that lowered version leads to regalloc failure
<MoeIcenowy> anarsoul: BTW we didn't specify a valid number for PIPE_SHADER_CAP_MAX_CONTROL_FLOW_DEPTH
<MoeIcenowy> so we works just because NIR shaders are not properly preprocessed
<MoeIcenowy> anarsoul: this kills both loops and spills
<MoeIcenowy> although it works
<MoeIcenowy> (works on ideas
adjtm has quit [Ping timeout: 264 seconds]
<MoeIcenowy> (the CF of glamor is if(), so not affected
<MoeIcenowy> anarsoul: looks like spill is the issue -- there's still if() in fixed ideas shader
<MoeIcenowy> but spills are removed at all
<MoeIcenowy> however there're still spills in lowered glamor shader, and lowering CF fixes the misrendering
<anarsoul> MoeIcenowy: but there's no loops
<MoeIcenowy> anarsoul: not only loops
<MoeIcenowy> conditional is enough to trigger the issue
<MoeIcenowy> in the situation of glamor, it's conditional that triggers
<MoeIcenowy> it has totally no loops at all
<anarsoul> I'm pretty sure that regular ifs are fine
<anarsoul> loops should also be fine though, but I haven't walked the disassembly yet to confirm that
<MoeIcenowy> what's non-regular?
<MoeIcenowy> you can try to analyze the GL trace at https://gitlab.freedesktop.org/lima/mesa/issues/125
<anarsoul> in theory nothing unusual
<MoeIcenowy> it really triggers the bug with only if
<anarsoul> we're reusing nir information on control flow to do liveness analysis
<anarsoul> so I expect it to be correct
adjtm has joined #lima
<MoeIcenowy> anarsoul: but we're meeting issues
<MoeIcenowy> so there must be sth wrong
Kwiboo has joined #lima
<anarsoul> yes
<anarsoul> we need to come up with a simple example with 2 draws that spills
<anarsoul> and run it through the blob to see what it does
drod has joined #lima
<MoeIcenowy> anarsoul: maybe we should first come up with an example that really fails?
<anarsoul> MoeIcenowy: I expect two draws with different shaders with at least one spilling to result in incorrect rendering
<MoeIcenowy> anarsoul: is different shaders a must?
<anarsoul> yes
<MoeIcenowy> I'm thinking whether the ideas situation uses different shader
drod has quit [Read error: Connection reset by peer]
<MoeIcenowy> 5 continous glDrawElements calls are used to draw the ball
<anarsoul> maybe it's not
<MoeIcenowy> let me try to flush when binding shader
<anarsoul> MoeIcenowy: it makes no sense to play with flushes
<anarsoul> we're not going to add more flushes to the driver
<anarsoul> we need to figure out why it doesn't work without a flush
<MoeIcenowy> anarsoul: this can be used to verify whether different shaders are critical
<anarsoul> even if it does, it doesn't bring us anyhow closer to solving the issue
<anarsoul> we need a simpler reproducer to run with blob
<anarsoul> to see what blob does
<MoeIcenowy> anarsoul: are you going to add a version with X11 blob to syscall dumper?
<anarsoul> nope
<MoeIcenowy> I think we can now reproduce nearly anything by running things on X11 via gl4es
<anarsoul> feel free to add it
<anarsoul> I'm not planning to run blob with x11 though
<anarsoul> there's too many moving parts with X11, so it's probably not a good idea anyway
<MoeIcenowy> strange
<MoeIcenowy> flushing between the last two calls in my glamor situation fixes nothing
drod has joined #lima
<MoeIcenowy> interesting... gbm-surface-render-two has the same shader with the problematic shader in glamor
<anarsoul> try running it with blob?
<MoeIcenowy> gbm-surface-render-two itself is not enough to trigger bug, I think
<MoeIcenowy> by changing a texture and re-draw, it fails to reproduce the issue...
<anarsoul> second draw has to be partial draw
<MoeIcenowy> I used a full draw with GL_BLEND
<MoeIcenowy> I think this should work...
<anarsoul> probably
<MoeIcenowy> yes, it's the same with glamor case
<MoeIcenowy> although glamor case in fact stacks two different shaders
<anarsoul> so likely having two different shaders is essential
kaspter has quit [Ping timeout: 246 seconds]
<MoeIcenowy> anarsoul: I switched fragment shader
<MoeIcenowy> and the bug is still not triggered
<anarsoul> :(
<anarsoul> looks like it's tricky one
<MoeIcenowy> BTW, consider my flush when switching shader doesn't solve it
<MoeIcenowy> I think it's possible that stacked draw is not the issue...
<MoeIcenowy> but this will make it more mysterious
<anarsoul> it is happening with multiple draws in a single submit and with quite complex fragment shader (with control flow and spilling)
<MoeIcenowy> yes, we got these two now
jrmuizel has quit [Read error: Connection reset by peer]
jrmuizel has joined #lima
jrmuizel has quit [Ping timeout: 265 seconds]
jrmuizel has joined #lima
adjtm_ has joined #lima
adjtm has quit [Quit: Leaving]
jailbox has quit [Ping timeout: 240 seconds]
jailbox has joined #lima
jrmuizel has quit [Remote host closed the connection]
drod has quit [Remote host closed the connection]
mrfixit2001 has joined #lima
<mrfixit2001> hello world :)
<anarsoul> hi mrfixit2001
<mrfixit2001> I have finally compiled lima in my buildroot environment to test out if it can do GBM/GLES/EGL. Sadly, no go. I've now tried compiling as arm (32bit) as well as aarch64. For both, when I try and start kmscube, I get "drmModeGetResources failed: Operation not supported" followed by "failed to initialize legacy DRM".
<mrfixit2001> So clearly I have missed something along the way in terms of dependencies or configuration.
<anarsoul> add yourself to 'render' and/or 'video' groups
<mrfixit2001> Here's my mesa config: https://pastebin.com/mLtAByCv
<mrfixit2001> anarsoul: thank you for your quick reply! I wish it was that easy... buildroot works differently that most distros, there's not the typical group add/remove options, and I'm using the root user. Just to be sure, I have edited /etc/group manually and added root to the video group (there's no render group), but I receive the same error.
<anarsoul> also make sure that card0 is display and card1 is render (lima)
<mrfixit2001> I see both card0 and card1 under /dev/dri. I just tried a chmod 777 to both, no luck yet. but... oooo that was closer! I tried kmscube -D /dev/dri/card1 and it initialized, but seg faulted immediately. I saw a milisecond of rendering
<mrfixit2001> Here's the error in dmesg that I believe is associated with the segfault: https://pastebin.com/wLhBXaeu
<anarsoul> mrfixit2001: again, make sure that card0 is display, card1 is lima.
<anarsoul> running 5.4-rc?
<mrfixit2001> anarsoul I'm not sure how to check that, this is my first exposure to lima. And yes, 5.4-rc1. Using the latest commits of torvalds and mesa from 2 days ago
<mrfixit2001> setting export DISPLAY=1 allowed kmscube to load :D
<mrfixit2001> looking at a beautifully rendered cube
<anarsoul> mrfixit2001: anyway, it's not a good idea to use environments that are unfriendly for debugging