ChanServ changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs https://oftc.irclog.whitequark.org/panfrost - <macc24> i have been here before it was popular
JulianGro has joined #panfrost
camus has joined #panfrost
abc123bac has joined #panfrost
camus1 has joined #panfrost
JulianGro has quit [Remote host closed the connection]
camus has quit [Ping timeout: 480 seconds]
nlhowell has joined #panfrost
nlhowell is now known as Guest374
nlhowell has joined #panfrost
Guest374 has quit [Ping timeout: 480 seconds]
nlhowell has quit [Quit: WeeChat 3.1]
camus1 has quit [Remote host closed the connection]
warpme_ has quit [Quit: Connection closed for inactivity]
<alyssa>
hum?
warpme_ has joined #panfrost
ids1024 has quit [Quit: WeeChat 2.9]
ids1024 has joined #panfrost
abc123bac1 has joined #panfrost
abc123bac has quit []
abc123bac1 has left #panfrost [#panfrost]
abc123bac has joined #panfrost
<abc123bac>
Hi. Love the work done by the devs to get these GPUs supported. I have an lenovo duet (mt8183) running debian sid. I'm experiencing some blue and yellow artifacts during video playback. Happens with youtube videos on both browsers (firefox, chromium) and mpv. Is this the right place to discuss this?
<alyssa>
Possibly, needs more information
<alyssa>
Are you using hw video decoding?
<alyssa>
Also, does the same problem happen with llvmpipe? (set `LIBGL_ALWAYS_SOFTWARE=1` assuming you're using a normal distro mesa)
<abc123bac>
I'm running debian sid without any additional configuration. The videos are VP9 and I don't think the mt8183 has a hw decoder for that.
<abc123bac>
I did try with that env variable. @macc24 suggested that. The issue was still there
<ndufresne>
abc123bac: as you have debian sid, can you test, gst-play-1.0 --videosink=glimagesink file.vp9 ?
<ndufresne>
and then GST_GL_API=gles2 gst-play-1.0 ....
<ndufresne>
(this is the only stack I know that let you test both big GL and gles2 APIs)
<abc123bac>
Let me try this
<ndufresne>
I have been experimenting issues with big GL (though on G52) recently
<ndufresne>
still need to get around to reporting (e.g. retesting with tip of mesa master first)
<alyssa>
abc123bac: just to confirm, could you paste the output of ` LIBGL_ALWAYS_SOFTWARE=1 es2_info | grep -i renderer`
<alyssa>
ndufresne: Please file mesa issues for big GL on G52 issues
<alyssa>
big GL isn't officially supported but you can, uh, flash your company badge or something 😋
<abc123bac>
Lots of dropped frames with gst-play-1.0 (the video is a 1440p vp9 video). both with and without the GST_GL_API=gles2 flag. Both methods still have the yellow artifacting
<robclark>
fwiw, videotestsrc is a useful thing to try to take decoder out of the picture and see if it is mesa issue with rendering yuv
nlhowell has quit [Ping timeout: 480 seconds]
<abc123bac>
Uh, which package is es2 supposed to be in. having a bit of difficulty finding that
<robclark>
ie. something roughly like (assuming my gst-launch fu is not too rusty) `gst-launch-1.0 videotestsrc ! video/x-raw,format=NV12 ! glimagesink
<alyssa>
abc123bac: distro?
<abc123bac>
debian sid
<abc123bac>
i can find something for ubuntu online, but that package isn't in debian
<alyssa>
mesa-utils-extra
<abc123bac>
thanks. give me a minute
<alyssa>
(I ran `apt-cache search es2_info`)
<abc123bac>
Uh, no command es2 after installing it
<abc123bac>
Ah sorry, missed the underscore. My IRC client is not displaying it properly
<robclark>
I suppose also check: `gst-launch-1.0 videotestsrc ! video/x-raw,width=X,height=Y,format=NV12 ! glimagesink`.. replacing X and Y with resolution of the stream where you were seeing corruption
nlhowell has joined #panfrost
cedric has quit [Read error: No route to host]
cedric has joined #panfrost
Danct12 has joined #panfrost
WoC has joined #panfrost
cedric is now known as bluebugs
megi has quit [Quit: WeeChat 3.2]
megi has joined #panfrost
JulianGro has quit [Remote host closed the connection]
<abc123bac>
robclark: that also works fine. the black/white noise part of the image isn't smooth though
<ndufresne>
alyssa: if it's not yet stable, we should perhaps figure-out a way so that gstreamer does not use it ? or perhaps I miss-interpret the "not officially supported"
<alyssa>
ndufresne: it ought to be stable. just not something I want to commit to supporting :-p
<ndufresne>
yeah, but I'm sure the kernel page fault are something we'll want fixed ;-D
<ndufresne>
"just need" to find time and make a decent report
<ndufresne>
abc123bac: interesting, have you tried I420 instead of NV12
<ndufresne>
software decoders will produce that most of the time, instead of NV12 which is produces by nearly all HW decoders
<ndufresne>
alyssa: we also notice that rendering NV12 from two different DMABuf didn't work, that one is not panforst fault, that's broken for all drivers that supports dmabuf ;-D
<ndufresne>
just sometimes, some video stream trigger some very niche and unexpected code path
<alyssa>
😇
<abc123bac>
tried running I420 instead. Looks pretty much the same. the black/white noise part is like at 1 frame every 5 seconds. Mind you that the width/height is 2560x1440
<ndufresne>
yeah, don't worry about that, gst goes 1fps is it's not behaving real-time
<ndufresne>
we only care about the color pattern to actually be right
<abc123bac>
the colour pattern is totally fine
<ndufresne>
just to make sure I'm not mixing thread, this is software decode right ?
<abc123bac>
sorry, this is without LIBGL_ALWAYS_SOFTWARE set. do you want me to run it with that?
<ndufresne>
can you try, gst-launch-1.0 filesrc location=my.vp9 ! parsebin ! vp9dec ! videoconvert ! pngenc ! multifilesink location="%05d.png"
<ndufresne>
and instead the files ?
<ndufresne>
abc123bac: I meant software VP9 decoder ^
<ndufresne>
e.g. libvpx decoder
<ndufresne>
chromium/firefox/mpv and gstreamer will decode using the same library if its software decoder, that raises libvpx are potentially the issue
<abc123bac>
this chip doesn't have a hardware vp9 decoder, so it must be software. Also, I downloaded the h264 version of this same video from youtube and that exhibited the same issue too.
<abc123bac>
(let me actually double check the h264 thing once. I remember doing don't. don't want to make wrong claims here)
<abc123bac>
Yup. h264 also has it. with both the llvmpipe and the panfrost methods
<abc123bac>
ndufresne: The png files generated by your command seem to have extremely tiny artifacts that are almost non-visible. These appear very very rarely. The ones while playing the video are much larger and frequent
<ndufresne>
abc123bac: the mainline h264 HW decoder does not work, it output only in Mediatek compressed format, there is no generic userspace known to handle that
<ndufresne>
abc123bac: but any artifact is a decode failure
<ndufresne>
use vpxdec command line to confirm
<abc123bac>
Ok, I guess that the h264 video would have used a software decoder then, and that too exhibited the issue.
<ndufresne>
and update libvpx to the most recent version
<ndufresne>
something is strange in your system for sure
<ndufresne>
the other option I have in mind is that you are dealing with a broken IOMMU or cache management
<ndufresne>
its not uncommon that ARM devices are broken mainline
<ndufresne>
no one uses mainline for production so ...
<ndufresne>
but it does not look immediatly like panfrost fault
<abc123bac>
Should I try flashing chromeos and check how it is there? To make sure nothing is wrong with my hardware. I used it for a few days before and didn't really notice anything in it
<ndufresne>
I can predict the answer, ChromeOS will work great ;-D
<ndufresne>
but yes, perhaps do a quick sanity check
<abc123bac>
I will test it and see. Might take me a day or two. I did have another question though, kinda related to video playback on this
<abc123bac>
Sometimes, i've noticed that the device just hangs while playing back a video in fullscreen on firefox. It happens very unpredictably. Things work smoothly and just hangs suddenly. Have to force reboot the device
<abc123bac>
Any idea what this could be related to? Was thinking it was the video driver, but I may be wrong
<ndufresne>
you'd have to enable sysrq, and get some dumps through serial interface
<abc123bac>
I don't think my device has an externally exposed serial interface. Need to open it up to see, and I'm not up for that.
<ndufresne>
it's a chrome book ? (if yes, then no)
<robclark>
you need suzyq
<abc123bac>
lenovo chromebook duet, yeah
<ndufresne>
abc123bac: but you can probably hook up a keyboard with a syrq key ?
<ndufresne>
interesting, the devices I worked on was older, and that was no using usb-c
<ndufresne>
pretty cool then
<ndufresne>
worth the value imho
<robclark>
the only drawback on original duet is there is only a single usb-c so you can't charge or use usb peripherals in combo w/ suzyq.. I'm not aware offhand of any other (post-usb-c) chromebook that only has a single usb-c
<robclark>
but suzyq/ccd is great when debugging issues like display not coming up (like I am now) :-P
<ndufresne>
we had a "special" cable with our copy of the MagicLeap that was chained to allow power while using data over your PC ... perhaps that would work ?
<ndufresne>
I need to find if it's generic or not
<ndufresne>
dah, that would be like a docking
<ndufresne>
I bed it won't play with low level serial ..
<abc123bac>
Let me try the chromeos thing first to make sure my hardware isn't bust, then I'll come back and see what debugging to do next. Thanks for the help ndufresne, robclark and alyssa
<ndufresne>
robclark: a cool, I didn't know if the various servo was documented in the public
<robclark>
in theory, schematics/etc for our various debug things should all be public.. not really any reason for them to be proprietary
<ndufresne>
that ribbon was something I had never seen in photo in the internet, but had to use that once
<robclark>
suzyq is (if you have >1 usb-c) defn the most convenient.. it's the one I use most of the time
<alyssa>
abc123bac: it's definitely smelling more and more like something is botched in your hardware or kernel
<alyssa>
even my m1 is more stable than this ;-p
nlhowell has quit [Ping timeout: 480 seconds]
<ndufresne>
robclark: you said ours, so I guess you joined ChromeOS team at Google ?
<alyssa>
old news :-p
<robclark>
yup, I guess you didn't follow the XDC talks last week :-P
<ndufresne>
didn't have time unfortunatly
<ndufresne>
it's all daniels' fault
<robclark>
heheh
<ndufresne>
well, apparently if panfrost (or any gallium driver) was doing AB24 instead of AR24 I would have had more free time :-(
<HdkR>
alyssa: M1 must be more stable because of some awesome community members :)
<alyssa>
HdkR: thx sven
<alyssa>
robclark: I still need to watch the XDC talks ... meant to ask, is turnip shipping in prod CrOS?
<robclark>
ndufresne, hmm, on freedreno side, we support all the swizzles... except tiled/ubwc but those are kinda opaque to sw anyways.. not sure if mesa/st would pick it or not
<ndufresne>
I'm not myself working on it, but ManMower was telling me it looks like the reason it's not doing ABBC on rk3566
<robclark>
alyssa: *kinda*.. not shipping on the android side yet (need to pass 100% cts to ship and we are still a few deqp's away from that).. we are shipping it on native side but not really used outside of webgpu
<ndufresne>
*AFBC
Bennett has joined #panfrost
ManMower has joined #panfrost
<robclark>
ndufresne: on qcom we have a coordinated lie about UBWC (which is basically same thing as AFBC).. we allow the modifier with AB24 and AR24, even though under the hood they are the same thing
<robclark>
but display and gl/vk drivers agree on the lie ahead of time, and things work out ;-)
<robclark>
give me a sec, I'll find the kernel commit
<ndufresne>
hmm, I guess if the compression does not do anything special with alpha vs colors that will have no special side effect
<robclark>
at least for us, it isn't anything to do with alpha.. and everything to do with swizzle
<alyssa>
this is the thread anyway. not that message in particular
<ndufresne>
someone will have to educate me what YTR means
<alyssa>
YUV-like transform
abc123bac has quit [Quit: Leaving]
<alyssa>
do a YUV-like matrix multiply before compressing which can get better compression ratios on certain kinds of content
<ndufresne>
lol, YUV like
<ndufresne>
that's a funny one, but yeah, I get it, you can do subsampling
<ndufresne>
if lossy isn't a problem
<ndufresne>
I doubt thought that subsampling RB will "not have any visual effect"
atler has quit [Ping timeout: 480 seconds]
<ndufresne>
alyssa: though, I think what robclark is doing is not swap YTR and RGB, it swap RGB and RGB but with different swizzling
<ndufresne>
but compression could have special handling of alpha or green (well green most likely)
<ndufresne>
if its lossy
<ndufresne>
I think we need someone to RE AFBC completely
<ndufresne>
to be sure
<ndufresne>
alyssa: basically it tells everything, here's ARGB, do AFB with it, and then when it get back, we just tell the next chip, eh, btw, this is ABGR
Bennett has quit []
Bennett has joined #panfrost
<robclark>
I guess the connection is that everyone would need to agree that AFBC+RGB is the same thing as AFBC+BGR (or visa versa.. and repeat for the other two possible swizzles)
<ndufresne>
(we do handle an alpha channel in our use case)
<robclark>
on the adreno side of things, there is basically a "native" swizzle for every format (ex. every 8_8_8_8 format is the same, but there are some extra bits to configure the swizzle).. add in tiled and/or ubwc and those swizzle bits become a no-op so RGBA+UBWC is same as ABGR+UBWC
<ndufresne>
imho, if same thing works in practice with AFBC, it could do that, but it's seems a bit more complex, since AFBC isn't specific to one board (and may mean different thing on difference soc)
<ndufresne>
I wonder if etnaviv folks have met similar thing or not with DEC400
Bennett has quit []
Bennett has joined #panfrost
nlhowell has joined #panfrost
<robclark>
for AFBC, is ARBC+RGBA different in memory from AFBC+BGRA / AFBC+ABGR / AFBC+ARGB?
<alyssa>
robclark: yes
<alyssa>
which was what some of the pushback from arm was about
<alyssa>
iirc AFBC is untyped / the channels are uninterpreted. it's just compressing unorm8 blocks
<alyssa>
which means the YTR transform is "wrong" if you use a different swizzle
<alyssa>
even though non-YTR is still fine
<alyssa>
(since YTR assumes BGRA iirc. or was it RGBA?)
atler has joined #panfrost
<robclark>
oh, ok.. so UBWC basically forces one's hand with that.. it is not "untyped"
<alyssa>
right..
<alyssa>
and at this point different kernels/userspaces do different things for AFBC+{RGBA,BGRA}(+YTR)
<alyssa>
which means there is no way to set a convention (to either do YTR backwards or to always ignore the swizzle for AFBC) without breaking UABI
<alyssa>
without torching the whole thing and adding a non-b/w compat modifier..
<alyssa>
which i'm errrrr not entirely opposed to.
<robclark>
yeah, a DO_WHAT_I_MEANT modifier might be the right thing, I suppose
pjakobsson_ has joined #panfrost
pjakobsson has quit [Ping timeout: 480 seconds]
nlhowell is now known as Guest444
nlhowell has joined #panfrost
Guest444 has quit [Ping timeout: 480 seconds]
warpme_ has quit [Quit: Connection closed for inactivity]
Bennett has quit [Remote host closed the connection]