narmstrong changed the topic of #linux-amlogic to: Amlogic mainline kernel development discussion - our wiki http://linux-meson.com/ - ml linux-amlogic@lists.infradead.org - official channel moved from Freenode - publicly logged on https://libera.irclog.whitequark.org/linux-amlogic
vagrantc has quit [Quit: leaving]
JohnnyonFlame has joined #linux-amlogic
jacobk has quit [Read error: Connection reset by peer]
kbingham has quit [Quit: ZNC - http://znc.in]
kbingham has joined #linux-amlogic
Daanct12 has joined #linux-amlogic
Danct12 has quit [Ping timeout: 255 seconds]
kbingham has quit [Quit: ZNC - http://znc.in]
kbingham has joined #linux-amlogic
buzzmarshall has quit [Quit: Konversation terminated!]
hexdump0815 has quit [Ping timeout: 240 seconds]
hexdump0815 has joined #linux-amlogic
jacobk has joined #linux-amlogic
Danct12 has joined #linux-amlogic
Danct12 has quit [Remote host closed the connection]
jacobk has quit [Ping timeout: 248 seconds]
jacobk has joined #linux-amlogic
naoki has joined #linux-amlogic
ldevulder has joined #linux-amlogic
camus1 has joined #linux-amlogic
camus has quit [Ping timeout: 264 seconds]
camus1 is now known as camus
luka177 has quit [Ping timeout: 240 seconds]
luka177 has joined #linux-amlogic
hexdump0815 has quit [Ping timeout: 255 seconds]
Daanct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-amlogic
hexdump0815 has joined #linux-amlogic
<narmstrong> well, vdec hasn't been updated since early 2020, and it may be totally broken since nothing was fixed since
<narmstrong> this is why it stayed in staging and nobody even tests it
<narmstrong> now it has been enabled in defconfig perhaps it will help more people testing it ?
chewitt has joined #linux-amlogic
<chewitt> vkoskiv: what ffmpeg sources are you using for testing?
<chewitt> and what kernel source?
<chewitt> technically a311d should be using the (badly named) 'hevc' driver for h264 not the older 'vdec' driver code for gxbb/gxl/gxm boards
<chewitt> but 'vdec' can/should play 8-bit/1080p/h264 media without issues .. subject to using the right sources
rockosov has joined #linux-amlogic
<vkoskiv> chewitt: I tried both the debian unstable ffmpeg, I think i was 6.0-7+b1, and the latest HEAD that I pulled from the ffmpeg repo
<vkoskiv> Hmm, I think the ffmpeg is actually coming from the reform repo, and it has patches for i.mx8
JohnnyonFlame has quit [Read error: Connection reset by peer]
<josch> vkoskiv: yes we have ffmpeg patches in the reform repo, but currently, building ffmpeg is disabled because of buggy hardware decoding on imx8mq
<josch> vkoskiv: use "apt-cache policy ffmpeg" to figure out where your ffmpeg binary comes from
<vkoskiv> Yep, confirmed it's coming from debian unstable
<chewitt> looks like a need an account on the Gitlab to see what's in the repos :)
<vkoskiv> I don't see a kernel module named 'hevc' under staging for meson, but an object called 'vdec_hevc.o' does get linked into meson_vdec
<chewitt> there's three commits in here that I run with LibreELEC https://github.com/chewitt/linux/commits/amlogic-6.5.y
<chewitt> the pi devs have an interest in v4l2_m2m support since it's used on pi 0-4 boards (not pi5)
<chewitt> and we collaborated a little to ensure the changes they would attempt to upstream also worked on the current staging driver (and also an Exynos chip)
<chewitt> the initial attempt to start upstreaming hit some friction on the ffmpeg list
<chewitt> (as things often do)
<vkoskiv> Interesting, I'll try these changes
<vkoskiv> Where do those firmware .bin files come from?
<chewitt> there are two sources
<chewitt> the LE branch has some newer files than are in the upstream linux-firmware repo
<chewitt> that doesn't necessarily guarantee they are better .. only different
<vkoskiv> And sorry, noob question, but these .bin files are the amlogic proprietary firmware blobs, right?
<chewitt> correct
<chewitt> Amlogic ships a single firmware blob file for Android
<chewitt> for Linux they were extracted into individual files using a tool
<vkoskiv> Cool, okay. I think I'm running the g12a chip here (not sure what the difference is between gxbb/gxl/g12a), I think I'll be able to apply these and build another .ko to try out
<vkoskiv> Thanks for the info!
<chewitt> a311d is g12b .. which uses the g12a blobs
<vkoskiv> Ah, got it.
<vkoskiv> Okay, I need to read up on how this firmware gets packaged/loaded before I go much further
<vkoskiv> Aha! dmesg says firmware is missing
<chewitt> drop them in /usr/lib/firmware/meson/vdec
<vkoskiv> That would probably make the hardware decoder unhappy :D
<chewitt> indeed !
<vkoskiv> josch: I'll figure this out and then submit a patch to reform-debian-packages if/when I get it working
<vkoskiv> chewitt: Thank you, I think you just saved me a lot of debugging time
<vkoskiv> I'm still pretty early in learning all this driver stuff
<chewitt> i'm on a multi-year quest to get people to work on the media drivers :)
<chewitt> the history and story of how things are in their current state is, err, complicated
<vkoskiv> hey! I'm decoding h264 with hardware decoding now!
<vkoskiv> That was quick
<vkoskiv> Literally just dropped the firmware files in, and it works.
<vkoskiv> I can see the vdec interrupts ticking up on CPU0 when I play
<f_> ohh nice
<josch> vkoskiv: awesome!! :D
<f_> Didn't know the driver was working *that* well!
<chewitt> seeking in media probably doesn't work without the ffmpeg sources I flagged
<f_> Never tried using it so I couldn't tell lol
<chewitt> I confess that it's a long time since I looked at vanilla ffmpeg capabilities
<f_> chewitt: I guess all this is included in LibreELEC right?
<josch> vkoskiv: do you know what the hardware decoder can do? does it manage 1024p@60? can it do 10bit? does hevc work?
<chewitt> f_: correct
<f_> Sure.
<f_> would be nice to have SPL etc on eMMC and <random operating system> on SD card, on my set-top box..
<chewitt> josch: the answers to that Q aren't so simple
<josch> as they always are :)
<f_> IIRC it does still have some issues
<f_> 10-bit doesn't work for sure.
<chewitt> have a read of the LE release notes here (scroll down to the Amlogic section) https://libreelec.tv/2023/03/06/libreelec-nexus-11-0-0/
<vkoskiv> Still some weirdness, ffplay uses about twice as much CPU when decoding with vdec, than it does when decoding in software
<f_> >H264 playback and seeking is solid
<chewitt> note the distinction between older (gxbb/gxl/gxm) and newer (g12a/b and sm1) devices
<vkoskiv> Yeah, ffplay pretty consistently uses ~400% cpu with hardware decoding, <200% when sw decoding
<f_> chewitt: Sure
<vkoskiv> It does play 1080p@60FPS though
<f_> >No drivers for in-box DVB tuners
<f_> ripped off mine lol
<f_> my box is sitting without the original tuner
<f_> Considering how it's useless in mainline
<chewitt> the general advice for someone with an a311d chip would be to ignore the existence of hardware decode drivers
<chewitt> it should be capable of playing anything software-decoded up to 1080p happily
<vkoskiv> I'm using h264_v4l2m2m
<vkoskiv> Yeah, software-decoded 1080p works perfectly fine here, I'm just interested in the reduced CPU load of hardware decode
<f_> chewitt: didn't you want to plumb SPL into LE images?
<vkoskiv> Software decoded 1080p@60* works fine, to be clear
<chewitt> hardware decoding on g12a and up really needs the hevc driver which was started and never completed
<f_> chewitt: I said that you should expect it to still be a WIP until it lands upstream
<f_> guess what
<f_> I don't think I'll be able to finish DRAM init anytime soon
<chewitt> there's been some work sponsored by lvrp16 to investigate moving the media drivers forwards, but it didn't bear fruit yet
<f_> lack of gxbb and gxl LPDDR hardware
* f_ checks lafrite specs again
<chewitt> all gxbb devices I've ever seen were DDR3
<f_> yet, gxbb BL2 seems to support LPDDR
<chewitt> theoretical existence and commercial availability are different concepts
<f_> Have no doubt some gxl devices will probably use LPDDR2 or LPDDR3
<f_> all gxbb devices seem to be using DDR3 for sure, gxl no real idea
<chewitt> the first boards I've seen with LPDDR anything were SM1 (VIM3L) with LPDDR4
<f_> I don't think the patches I'll send will include DDR4 support either, although I do have DDR4 gxl hardware. It will be worked on later.
<chewitt> the challenge for LE is that we need 'a' method to work everywhere
<f_> chewitt: but I guess once this lands upstream with all gxbb defconfigs updated depending on dram settings, this should be usable on most gxbb hardware.
<chewitt> so I can do basic experiments on specific boards but actual use in a distro needs a lot more code support for things
<f_> Are you manually signing the binaries or using amlogic-boot-fip makefiles to do so?
<chewitt> I use the boot-fip Makefiles
<f_> sure
<chewitt> I guess the Makefiles can be adjusted to use a different flow of course
<f_> Right now when you build my tree it will also build signed images and put them at the root of the repo
<f_> so...
<f_> $ export CROSS_COMPILE=... BL31=path/to/upstream/tf-a/bl31.bin SCP=path/to/bl30.bin
<f_> $ make <board>_defconfig
<f_> $ make -j8
<f_> $ dd if=u-boot-gxbb-with-spl.bin of=/dev/mmcblk0 bs=512 seek=1
<f_> could probably also include Kwiboo's recent amlimage patches which also include the relocation hack.
<f_> (thus not needing aml_chksum if you want *one* image for eMMC and SD)
<f_> except it doesn't use bl1.bin.hardkernel but newer relocation code.
<chewitt> sure
<f_> AFAICT gxbb support in SPL is pretty much done
<f_> except for a bug when trying to load bl30+bl301 which makes it loop, if you're unlucky it ends up retrying again and again and never boots.
<f_> Weirdly enough, Kwiboo's tree doesn't have this bug. Still need to investigate..
<f_> bl30+bl301 is a huge mess though
<chewitt> bl301 is used with everything
<f_> yeah BL31 panics if bl30 isn't there.
psydroid has joined #linux-amlogic
<chewitt> vkoskiv I'm watching some tv in the background in kodi (1080p/H264) and I'm rarely seeing CPU on a single core over 9-10%
<chewitt> it moves between the larger cores (as you'd expect)
<chewitt> and there's a few other % running on the smaller cores
<vkoskiv> chewitt: Building that rpi-ffmpeg branch now to see if that makes a difference
<chewitt> what device-tree does the reform use?
<chewitt> (not seeing anything for it in torvalds/master)
<vkoskiv> the i.mx8 dts for the reform is in mainline, this one isn't yet
<vkoskiv> (the upgrade is still quite new, software side is being worked on)
<chewitt> I registered for an account on that GitLab instance, but needs to be approved .. can't see anything until then :(
<vkoskiv> weird, let me check
<vkoskiv> minute: Is the reform gitlab instance supposed to be that way?
<vkoskiv> chewitt: here it is for the time being: https://pastebin.com/VTQZ6Fd1
<vkoskiv> still 400+ % cpu use on the rpi_import_1 branch of rpi-ffmpeg
<chewitt> "model = "MNT-REFORM2-BPI-CM4";"
<vkoskiv> I'll profile it a bit to see what it's doing
<chewitt> ^ alsa has a 15 character limit on model name
<chewitt> anything longer is truncated
<vkoskiv> josch: ^
<chewitt> MNT-REFORM2 would be good :)
<vkoskiv> There are different variants of REFORM2, since the SoM is swappable
<vkoskiv> But this is good to know - Can this affect hardware decoding? I thought alsa was more of an audio system
<f_> MNT-REFORM2-G12?
<chewitt> REFORM2-A311D perhaps
<f_> MNT-REFORM2-BPI?
<chewitt> what's the other SoM option?
<f_> chewitt: i.MX and RPi CM4 IIRC
<josch> vkoskiv: REFORM2-A311D fits into the 15 char limit and we use a311d to talk about the SoM in other parts
<vkoskiv> currently on reform2, LS1028A, this A311D and the stock one is i.mx8mq
<josch> chewitt: also nxp ls1028a
<vkoskiv> A311D uses the Banana Pi compute module, the adapter board can also take a RCM4
<vkoskiv> chewitt: I gues I'll try cherry-picking these amlogic commits from your branch, do you think that would make a difference to the CPU use?
<vkoskiv> seeking did work, but it was a bit weird, perhaps.
<chewitt> no harm in trying
<chewitt> the challenge with them is .. with 10-bit or 4k media you'll probably wedge the board
<chewitt> I also disable the mpeg2 codec as this is used with some dvb streams and the hardware driver is broken
<vkoskiv> 'wedge'?
<chewitt> the board locks up
<vkoskiv> Ah, the whole SoC, or just the hardware decoder part?
<chewitt> hard lockup .. power cycle required
<vkoskiv> Oof, okay. Well, I'm interested in 1080p and regular 8 bit color
<chewitt> the challenge is that users turn up with all kinds of weird media .. and expect it to just play
<vkoskiv> Yeah. I'm more than willing to accept weirdness if it means I get hardware decoding for 1080p
<vkoskiv> Is hardware encoding realistic now or in the near future on here?
<chewitt> i'm not aware of anyone working on the driver
<f_> only if someone starts working on it :)
<chewitt> and anecdotal comments from others suggest the Amlogic venc isn't so amazing
<chewitt> i.e. a311d is more than capable of software-encoding at a higher quality than hardware venc would achieve (even if it did exist)
<vkoskiv> fair enough. I don't think encoding was the bottleneck when I got OBS to work, seemed like sway was doing something weird, it was using more CPU than OBS when capturing the screen
<minute> vkoskiv: it's because your repo is not public, vs our repo
<vkoskiv> Ah, I'll set it to public. Sorry for the confusion!
<f_> tbh it's nice to see more happy a311d reform users.
<chewitt> yup, that's visible
<vkoskiv> Mine should be too, now.
<f_> just curious about the battery life. A311D doesn't consume much power.
<chewitt> yup
<f_> It has been designed for media boxes after all.
<vkoskiv> It's better than with i.mx8, I feel like.
<f_> That reform laptop you're using is the first ever laptop to ship with an Amlogic SoC.
<minute> ha.
<f_> No one (I know of) has done this kind of thing with Amlogic SoCs before.
<vkoskiv> I wonder if the AMlogic people know :D
<f_> Some amlogic folks are lurking here
<f_> but they never post.
<chewitt> ahh.. lots more patches than just the dts .. so I'll wait for things to go upstream before picking to an LE image :)
<f_> chewitt: what?
<chewitt> I was thinking to pick the reform2 dts into the kernel I use for LE
<f_> ah ok
<chewitt> but it needs a few more things than just the dts
<chewitt> that shouldn't be needed on 6.5.y kernels IIRC
<chewitt> the patch was superseded by https://github.com/chewitt/linux/commit/8279e6cde53957ff8fbcda515a87484eefbfc693 which is now upstream
<vkoskiv> Good to know, josch has been tending to the reform patches, but I think I could try removing that patch to see if it works without it
gis has quit [Ping timeout: 255 seconds]
buzzmarshall has joined #linux-amlogic
gis has joined #linux-amlogic
Danct12 has quit [Quit: WeeChat 4.1.0]
naoki has quit [Quit: naoki]
Danct12 has joined #linux-amlogic
luka177 has quit [Read error: Connection reset by peer]
luka177 has joined #linux-amlogic
ungeskriptet7 has joined #linux-amlogic
ungeskriptet has quit [Ping timeout: 260 seconds]
ungeskriptet7 is now known as ungeskriptet
luka177 has quit [Ping timeout: 245 seconds]
luka177 has joined #linux-amlogic
<lvrp16> chewitt: we're stalled at the firmware waiting for some assistance from Amlogic
<lvrp16> instead of stateful, I want to get it done in one go so that Vulkan Video can be supported via stateless if possible
<lvrp16> otherwise the wheel will keep spinning in the future on this topic
<chewitt> get them to reveal the ISA used for the firmware blobs .. then we can reverse them and figure it all out ourselves :)
jacobk has quit [Ping timeout: 248 seconds]
vagrantc has joined #linux-amlogic
<f_> chewitt: bruteforce arch in ghidra
<f_> ??????
<f_> profit
<chewitt> feel free to have a crack at it
<chewitt> @cyrozap had a look before but came to the conclusion it was a custom ISA .. IIRC
jacobk has joined #linux-amlogic
<f_> ¯\_(ツ)_/¯
chewitt has quit [Quit: Zzz..]
luka177 has quit [Ping timeout: 258 seconds]
luka177 has joined #linux-amlogic
<vkoskiv> perf'd to see what is taking up so much CPU when hardware decoding (400+% cpu vs. <200% on sw decode), and perf says #1 is deinterleaveBytes_c at 65%, second is __memcpy_generic at 20%
<vkoskiv> Third is also __memcpy_generic, but at 2.31%. Assuming that's just on a different codepath? Not sure why it's shown twice
<vkoskiv> 2nd is in red, 3rd in green, whatever that means.
<vkoskiv> Hm, with swdec, there are no obvious outliers above ~2% overhead
<vkoskiv> Is this because all I have are mem2mem variants, so it just has to do a lot of copying?
<vkoskiv> (no idea if mem2mem is bad, or the standard way)
<vkoskiv> If I try vp9, it seems to start playing, but no window pops up, seems to be stuck at the start there
<vkoskiv> With the rpi-ffmpeg branch, I seem to get no video with h264, and a failed to open file or configure filtergraph error with vp9
jacobk has quit [Ping timeout: 260 seconds]
mripard has quit [Quit: mripard]
jacobk has joined #linux-amlogic
<vkoskiv> Haven't tried the kernel patches yet
ldevulder has quit [Read error: Connection reset by peer]
ldevulder has joined #linux-amlogic
jacobk has quit [Ping timeout: 248 seconds]
jacobk has joined #linux-amlogic
jacobk has quit [Ping timeout: 240 seconds]
jacobk has joined #linux-amlogic
luka177 has quit [Ping timeout: 252 seconds]
luka177 has joined #linux-amlogic
vagrantc has quit [Quit: leaving]
psydroid has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
luka177 has quit [Ping timeout: 264 seconds]
luka177 has joined #linux-amlogic