adjtm has quit [Quit: Leaving]
_whitelogger has joined #lima
_whitelogger has joined #lima
megi has quit [Ping timeout: 268 seconds]
buzzmarshall has quit [Quit: Leaving]
dddddd has quit [Ping timeout: 268 seconds]
zhangn1985 has joined #lima
adjtm has joined #lima
zhangn1985 has quit [Quit: Lost terminal]
gcl has quit [Quit: leaving]
yuq825 has joined #lima
_whitelogger has joined #lima
Net147_ has joined #lima
Net147 has quit [Ping timeout: 260 seconds]
warpme_ has joined #lima
megi has joined #lima
MoeIcenowy has joined #lima
MoeIcenowy has joined #lima
Elpaulo has quit [Read error: Connection reset by peer]
Elpaulo has joined #lima
dddddd has joined #lima
chewitt has quit [Quit: Zzz..]
chewitt has joined #lima
<
enunes>
anarsoul: cool, thanks for reviewing it again
_whitelogger has joined #lima
<
jernej>
anarsoul: I just noticed this in RK DRM driver. Does AW DRM driver need same thing?
yuq825 has quit [Quit: Leaving.]
cp- has quit [Quit: Disappeared in a puff of smoke]
cp- has joined #lima
buzzmarshall has joined #lima
<
anarsoul|c>
jernej: doesn't it already have it?
<
jernej>
which doesn't align to 64
<
jernej>
I noticed meson driver also aligns to 64
<
jernej>
I'm just wondering if this is really needed
<
anarsoul|c>
IIRC it has to be aligned to tile boundaries, i.e.to 16 pixels
<
anarsoul|c>
So 64 bytes
<
jernej>
well, maybe it would help to some test
<
anarsoul>
I doubt it, IIRC surfaceless doesn't use display driver
<
anarsoul>
also we don't get any ppmmu faults in deqp
yann has joined #lima
<
anarsoul>
*sigh* 'valgrind --tool=exp-sgcheck' is not available on arm yet :(
<
anarsoul>
let's see if it's compiler issue
<
anarsoul>
with standalone lima compiler on x86
<
anarsoul>
==500872== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 17)
<
anarsoul>
darn it was from mesa-19.3
<
anarsoul>
LD_LIBRARY_PATH wasn't set
<
anarsoul>
so we have:
<
anarsoul>
==17076== Invalid read of size 4
<
anarsoul>
==17076== at 0x5EFEB20: ppir_node_print_src (node.c:543)
<
anarsoul>
that's when replaying the trace from the issue above
<
anarsoul>
==17076== Invalid read of size 1
<
anarsoul>
==17076== at 0x5F02E48: ppir_liveness_instr_srcs (liveness.c:127)
<
anarsoul>
==17076== Invalid read of size 4
<
anarsoul>
==17076== at 0x5F02E54: ppir_liveness_instr_srcs (liveness.c:134)
<
anarsoul>
==17076== Invalid read of size 8
<
anarsoul>
==17076== at 0x5F02E60: ppir_liveness_instr_srcs (liveness.c:134)
<
anarsoul>
==17076== Invalid read of size 4
<
anarsoul>
==17076== at 0x5F02EAC: ppir_liveness_instr_srcs (liveness.c:147)
<
anarsoul>
==17076== Invalid read of size 4
<
anarsoul>
==17076== at 0x5F029E0: ppir_liveness_set_clone (liveness.c:62)
<
anarsoul>
OK, I found a bug
<
anarsoul>
we still reference old (orphan) node in src->node for ld_tex
<
anarsoul>
it's not old
<
anarsoul>
but we delete it!
<
jernej>
anarsoul: I found bug in kernel and/or Kodi (depends how you look at it), so Lima works on H3 with Kodi now
<
jernej>
but for some reason, Lima doesn't want to start on H5
<
jernej>
has anyone tried recently H5?
<
anarsoul>
I don't think so
<
anarsoul>
I don't have H5
<
jernej>
let me check my configuration again, maybe I missed something
<
anarsoul>
sh*t ppir is totally broken :\
<
anarsoul>
we lost ld_tex node after lowering!
<
anarsoul>
no wonder there's no rounded corners for UBtouch guys
<
anarsoul>
aha, found it!
buzzmarshall has quit [Quit: Leaving]
buzzmarshall has joined #lima
<
anarsoul>
it reads shape texture in $2 and then overwrites it almost right away
<
anarsoul>
yeah, so ssa_9 is written in block_0 (it's load_tex)
<
anarsoul>
it's not referenced in block_1 which is a successor of block 0
<
anarsoul>
it's actually read in block 4 which is successor of block 3 which is a successor of block 1
<
rellla>
jernej: i have H5 here. no problem so far :)
<
rellla>
didn't try kodi though
<
jernej>
rellla: for some reason, gbm_create_device() fails...
<
jernej>
I have to put more debug output around it
<
anarsoul>
jernej: likely you're trying to use RGBA on plane that can do only RGBX
<
jernej>
not likely, because whole stack works on H3 and H3 and H5 shares same DRM driver configuration
<
anarsoul>
OK, I think I know what's the issue
<
anarsoul>
liveness analysis is OK
<
anarsoul>
but we don't update node in ppir_src for mov that was created for ld_tex
<
anarsoul>
because ppir_node_insert_mov() assumes that successors are in the same block
yann has quit [Ping timeout: 272 seconds]
<
jernej>
rellla: which H5 board you are using? which kernel?
<
rellla>
Orange Pi PC 2
<
rellla>
Linux opipc2 5.5.0-rc7-next-20200121-00005-gf772fa529730
<
rellla>
jernej: it's an recent drm-next with yuq's heap patches on top. but it worked with older versions, too.
<
rellla>
*linux-next, not drm-next iirc
<
jernej>
strange, it's unstable for me
<
jernej>
using 5.4.7
<
rellla>
i just added nfs server in the defconfig and use the default dtb
<
jernej>
meh, build system didn't pick config change
<
jernej>
after manual clean and rebuild, it works nicely
<
jernej>
sorry for the noise
<
anarsoul>
rellla: please send your Tested-by for kernel patches if they work fine for you
<
anarsoul>
I'll probably test them tomorrow
<
anarsoul>
I already spent ~4h today debugging 2 lima issues, need some time to rest
<
rellla>
anarsoul: will do.
<
rellla>
i spent many hours the last days for depth/stencil/blend/whatever and need some break :p
<
rellla>
unsolved btw :)
<
rellla>
i guess it's an issue not related to the cmd streams
<
anarsoul>
rellla: try looking into something else? :)
<
rellla>
that's what i will do :)
<
anarsoul>
want something easy?
<
anarsoul>
feel free to reassign it to yourself
<
rellla>
easy sounds good, but i think next week is full with $work$ so lima probably has to go and make holidays for a while
<
anarsoul>
yeah, understandable
deesix_ has joined #lima
dddddd_ has joined #lima
deesix has quit [Ping timeout: 268 seconds]
dddddd has quit [Ping timeout: 272 seconds]
dddddd_ is now known as dddddd
deesix_ is now known as deesix