<SolidHal>
Is there a way to set a priority of sorts so mesa gets used instead of llvm? Simply building, running `sudo ninja install` and rebooting doesn't result in mesa/panfrost getting used over llvm. For reference, this is a debian based system and here is the script I am using
<warpme_>
dears: fyi: current master (99f0feb) works for me H6 (t720) with perfect results. Fully working GL UI, playback with OpenGL & yv12 renderers + all GLSL based shader deinterlacers (OneFileld. LinearBlend & Kernel). Just FYI.....
<alyssa>
tomeu: Cool, therew's your answer then :)
<alyssa>
tomeu: If you have to ask, vec8/16 swizzles are usually weird
yann|work has joined #panfrost
<warpme_>
i wish have the same for t820.....
<warpme_>
(hw I have to play with amlogic statefull v4l2 m2m decoder and DRM prime rendering)
<warpme_>
btw: is EGL_LINUX_DMA_BUF_EXT supported on mali450/t720/t820 ?
<warpme_>
i mean mesa on mali450/t720/t820 of course :-)
<alyssa>
Not sure..
<alyssa>
I would assume so, but?
<warpme_>
isn't that this extension is part of gles3.2 (or >3.0 - i dont remember actually)
<tomeu>
I think our winsys code should support that, barring modifiers
<warpme_>
answer to this Q is quite important for me as if EGL_LINUX_DMA_BUF_EXT will be not supported in GLES target level of mesa - then we (mythtv team) will need to realize video rendering by DRM prime - not by EGL dambuf exports...
<tomeu>
warpme_: it's not clear to me if you have tried master on the t820 yet
<alyssa>
Obviously that will break T760/T860/etc, I just want to know if that particular workaround is what's needed.
<robmur01>
tomeu: same hilarious 40MHz MP1 with tiny caches as always
<alyssa>
T820 has the following 'features' that T760 does not: warping, interpipe register aliasing, "brndout" kill (?), next instruction type (?)
<alyssa>
T720 also has "interpipe register aliasing" which strongly suggests to me that that is what kbase calls the texture register workaround we have
<tomeu>
robmur01: I meant what soc/board
<robmur01>
IIRC 820 was already working reasonably well, but colours were sometimes off (e.g. RGBA kmscube was very brown)
<alyssa>
Or rather ... that feature -- the aliasing -- is why T720/T820 worked at all, even sometimes/occassionally, without the workaround.. since the registers were aliased, so even though our code was wrong, the hw patched over some of the wrongness and hid the bug
<alyssa>
T720 also has warping
<tomeu>
robmur01: hmm, probably it broke at the time that alyssa REd the tiling stuff
<robmur01>
tomeu: Juno with a Virtex-7 LogicTile FPGA ;)
<robmur01>
just need to load a new bitfile...
<alyssa>
I recall reading that T720/T820 have a modified ALU pipeline, closer to how Bifrost works than other Midgards ... so warping it is I guess.
<tomeu>
robmur01: ah, that completely common piece of hw...
<tomeu>
urjaman: no, can you check what line is dma_fence_default_wait+0xf8 ?
<robmur01>
urgh, 32-bit kernels... so much harder to tell whether a pointer looks sensible or not :P
<urjaman>
hmm how would i do that? (also, i think i already built rc8 in that tree so if i'd need that stuff then it might not correlate 100% ...)
* robmur01
wonders if someone can manage to free the fence while someone else is still waiting on it
<tomeu>
urjaman: with gdb or some script in scripts/
<urjaman>
ok i'll figure it out once i'm done with my food :P
<robmur01>
urjaman: if you built your own kernel, `scripts/faddr2line vmlinux dma_fence_default_wait+0xf8/0x1d0`
<robmur01>
heh, in fact the second thread appears to be dying at "/* Failed to signal before release, likely a refcounting issue. */"
<robmur01>
although AFAICS you should have gone through a WARN() to get there :/
<robmur01>
derp, it's right there, I can't read...
<urjaman>
"dma_fence_default_wait at .tmp_kallsyms2.o:?" is not super helpful ...
camus has joined #panfrost
kaspter has quit [Ping timeout: 276 seconds]
camus is now known as kaspter
<robmur01>
oh, is it in a module?
<narmstrong>
tomeu: reverted skip/fails like t860 to evaluate the state on t820
<tomeu>
narmstrong: ok, I'm planning to ask for t720 to be whitelisted in master only once it's at the same level of support as t760
<tomeu>
maybe we should do the same for t820
<tomeu>
narmstrong: we're setting up two h64s in our lava lab, expected to be online for next week
<narmstrong>
tomeu: good news
<tomeu>
do you have two boards with t820 that can be used for mesa ci?
<narmstrong>
tomeu: yes, I'm fixing the CI to make it more reliable
<narmstrong>
I already move the lava runner to a standalone vm
<tomeu>
awesome!
karolherbst has joined #panfrost
<tomeu>
narmstrong: and thanks a lot for letting me use your h64 board!
<narmstrong>
tomeu: np, it's there to be used anyway !
robmur01 has quit [Ping timeout: 240 seconds]
karolherbst has quit [Client Quit]
<urjaman>
ah this kernel is not built with debug info (i think that's what would be needed to resolve the address)
karolherbst has joined #panfrost
<urjaman>
i'ma try and just switch it on and rebuild and see where it points to (same compiler, same function (atleast i dont think rc8 touched that area at all) so i guess it could work)
<tomeu>
some of them could be superseded by improving our understanding of the tiling unit on the t720
karolherbst has quit [Ping timeout: 252 seconds]
<urjaman>
tomeu: okay after getting some debug info, it pointed me at drivers/dma-buf/dma-fence.c:498 (and a bunch of detail on how the list_add is inlined...)
<urjaman>
oh and __list_add at include/linux/list.h:63
<urjaman>
but yeah to me it sounds like the fence pointer pointing to something that's gone (or, something like that)
<alyssa>
tomeu: oken
karolherbst has joined #panfrost
<robmur01>
urjaman: cool, thanks for digging
<robmur01>
not immediately obvious how fence->cb_list could be nonsense if the rest looked real enough to get that far through, but at least it's a data point
<robmur01>
shame KASAN for 32-bit is still a WIP
<warpme_>
alysa: i gave try for 99f0feb + https://people.collabora.com/~alyssa/enable-t820-hax.patch on t820 and....this works perfectly (GL UI, playback with OpenGL & yv12 renderers + all GLSL based shader deinterlacers (OneFileld. LinearBlend & Kernel). not tested any regressions on t720/450...
<warpme_>
also briefly tested on t720 & mali450: no regression
karolherbst has quit [Ping timeout: 246 seconds]
karolherbst has joined #panfrost
yann|work has quit [Ping timeout: 265 seconds]
maccraft123 has quit [Quit: WeeChat 2.6]
maccraft123 has joined #panfrost
maccraft123 has quit [Client Quit]
maccraft123 has joined #panfrost
guillaume_g has quit [Quit: Konversation terminated!]
pH5 has quit [Quit: bye]
yann|work has joined #panfrost
pH5 has joined #panfrost
<alyssa>
warpme_: \o/
<alyssa>
Mystery solved then :-)
* alyssa
will spin that into a proper patch when she gets a moment (probably not today)
<alyssa>
tomeu: ^^ unless you'd like to
<warpme_>
alyssa: yeah. INCREDIBLE work i must say!
<alyssa>
<3
<alyssa>
The t-20 GPUs are always fun :p
<alyssa>
warpme_: Or you'd like to? ;P
<alyssa>
GPUs T720, T820, and T830 should get that workaround
<warpme_>
indeed: t820 white screen was show stopper for last month or so....
<alyssa>
check the kernel for IDs
<warpme_>
now I can start to play wit amlogic hw video decode by v4l2 m2m. So far getting black screen and in EGL dmabuf mode. So critical Q for me is: is current mesa supporting and have working ok EGL_LINUX_DMA_BUF_EXT?
<robmur01>
yup yup, t820 and t830 may be spewing translation faults left right and centre for most of their glmark2 runs, but they are at least now showing textures and correct colours while they do :D
<robmur01>
ooh, and the kmscube-triggered "unhandled" has transformed into a nicely descriptive "mesa: st_get_external_sampler_key: unhandled pipe format", hooray!
<robmur01>
still haven't figured out whose problem that is, though
<robmur01>
bisecting only led to... the patch that added the print for that case :(
davidlt has quit [Ping timeout: 250 seconds]
cowsay_ has joined #panfrost
Elpaulo has quit [Ping timeout: 276 seconds]
jernej_ has joined #panfrost
jernej_ has quit [Remote host closed the connection]
jernej_ has joined #panfrost
jernej has quit [Ping timeout: 276 seconds]
jernej_ is now known as jernej
NeuroScr has joined #panfrost
maccraft123 has quit [Ping timeout: 252 seconds]
camus has joined #panfrost
kaspter has quit [Ping timeout: 240 seconds]
camus is now known as kaspter
NeuroScr has quit [Quit: NeuroScr]
NeuroScr has joined #panfrost
pH5 has quit [Remote host closed the connection]
stikonas_ has joined #panfrost
stikonas has quit [Quit: Konversation terminated!]
stikonas_ has quit [Remote host closed the connection]
stikonas has joined #panfrost
stikonas has quit [Client Quit]
stikonas has joined #panfrost
stikonas has quit [Remote host closed the connection]