lanefu changed the topic of #armbian-rockchip to: Armbian - Linux for ARM development boards | Rockchip SoC | www.armbian.com | This channel is relayed to the equivalent Discord channel | this channel is logged
<DC-IRC>
[Discord] <ioncube7221> I was hoping if there is a way something like this, then I can habe MALI OpenCl ...very popular in CFD modelling https://www.youtube.com/watch?v=I1SVVp9GX9I
<DC-IRC>
[Discord] <microlinux> Sure, ahh yeah, there may be mali blobs that can be used.
<DC-IRC>
[Discord] <microlinux> But I have no idea about those
<DC-IRC>
[Discord] <microlinux> That is running on an ancient bsp kernel tho
<DC-IRC>
[Discord] <gambl0r> hello, any idea why this orangepi5-plus noble/kde-plasma build is failing? log is here: https://paste.armbian.com/icadipetic
<DC-IRC>
[Discord] <superkali> Let me understand, from what I see they put 2 more cores than A53 so I have been taken from the A72 and consequently a depowered version compared to the rk3588, but will they ever be able to do something with more cores and clocks?
<DC-IRC>
[Discord] <superkali> Ah no wtf how much core have rk3688 and why he told rk35xx has only 2 core a72
<DC-IRC>
[Discord] <gambl0r> is there anything I need to state in the build command to get panthor working on noble? Is it possible?
<DC-IRC>
[Discord] <superkali> just add ENABLE_EXTENSIONS="mesa-vpu" on ./compile.sh command
<DC-IRC>
[Discord] <gambl0r> done, thanks
<DC-IRC>
[Discord] <superkali> welcome
<DC-IRC>
[Discord] <lanefu> Guess who's gonna wait at least 3 years before buying another SBC with a flagship Rockchip SoC
<DC-IRC>
[Discord] <spooky8086> A53 cores should be retired, what is Rockchip doing.
<DC-IRC>
[Discord] <runaway97> everything they can to not retire them
acari has joined #armbian-rockchip
<DC-IRC>
[Discord] <runaway97> so what kernel is this crap going to ship with for the next 4 years?
<DC-IRC>
[Discord] <spooky8086> Probobly 6.1, i think there may be a new sdk release soon ish? Though i dont have access anymore, my ssh keys expired
<DC-IRC>
[Discord] <rpardini> Hey folks, any guesses on why I get rkmpp accelerated h264 decode on command-line `ffmpeg` but not on Kodi?
<DC-IRC>
[Discord] <rpardini> I'm on `legacy` 5.10, `jammy`, and `EXT=mesa-vpu`; all kodi and ffmpeg/avcodec packages from liujianfeng1994/rockchip-multimedia...
<DC-IRC>
[Discord] <rpardini> kodi is running directly with `kodi-standalone`
<DC-IRC>
[Discord] <rpardini> ffmpeg cli works perfect with `h264_rkmpp` and `hevc_rkmpp` but Kodi fries CPUs...
<DC-IRC>
[Discord] <nicod_sbc> Isnt EXT=mesa-vpu for 6.1?
<DC-IRC>
[Discord] <nicod_sbc> Start with normal image without vpu mesa extension and do this.
<DC-IRC>
[Discord] <monkablyat> mesa-vpu extension uses panfork ppa for legacy builds and kisak for vendor
<DC-IRC>
[Discord] <monkablyat> extension seems fine like it is right now
<DC-IRC>
[Discord] <rpardini> Yeah. If I do manually I end up in the same situation. Since cmdline `ffmpeg` works accelerated, I don't believe it's a 5.10/6.1 issue?
<DC-IRC>
[Discord] <ioncube7221> Is it me or you also feel video playback degradation whem `jammy` & `noble` are compared using tools from same ppa @microlinux I have observed this in Opi3b
<DC-IRC>
[Discord] <ioncube7221> Is it me or you also feel video playback degradation when `jammy` & `noble` are compared (former being superior) using tools from same ppa @microlinux I have observed this in Opi3b
<DC-IRC>
[Discord] <ioncube7221> Can you expalin what this word mean `kisak for vendor`
<DC-IRC>
[Discord] <monkablyat> It's a PPA that provides mesa upstream driver
<DC-IRC>
[Discord] <ioncube7221> Try KODI by logging out & loggin in directly to `KODI SESSION` thus it will report windowing system as `gmb` instead of `wayland` This produce superior result
<DC-IRC>
[Discord] <rpardini> Did this. Still get near to 100% CPU usage across 8 cores to play `jellyfish-400-mbps-4k-uhd-hevc-10bit.mkv`
<DC-IRC>
[Discord] <rpardini> Did this. Still get near to 100% CPU usage across 8 cores to play `jellyfish-400-mbps-4k-uhd-hevc-10bit.mkv` in Kodi. `ffmpeg` does it at almost 6x with almost 0% CPU usage.
<DC-IRC>
[Discord] <microlinux> Nah, they are mostly the same as A55, even better sometimes. It's the affordable SoC. You can't mix A72 with A55 afaik.
<DC-IRC>
[Discord] <rpardini> Also tried with `vendor`, `mesa-vpu` and `jammy`: same stuff (Kodi fries CPUs, shows `ff-hvec (SW)`; ffmpeg cli uses `hevc_rkmpp` fine)
<DC-IRC>
[Discord] <nicod_sbc> No idea here. I don't use kodi.
<DC-IRC>
[Discord] <rpardini> This doesn't work. `Kodi` session is actually X11, and `Kodi on Wayland` is just that. GBM (sic?) is only without any display and then running `kodi-standalone`, but that only works on `legacy`, not `vendor`, as far as I can tell. Either way there's no rkmpp
<DC-IRC>
[Discord] <rpardini> I found it, grandmaster Amazingfate has instructions in the forum:
<DC-IRC>
[Discord] <rpardini> (in Kodi) _Settings -> Player -> Videos, enable "Allow using DRM PRIME decoder" and "Allow hardware acceleration with DRM PRIME". And set "PRIME Render Method" to "Direct To Plane"_
<DC-IRC>
[Discord] <rpardini> Heh. Indeed rkmpp works now π but it seems to render to the wrong plane so video is black π€ EGL also black image. Will try on another board, think this is &vop stuff in the DT I can't grok...
<DC-IRC>
[Discord] <microlinux> "Ricardo Pardini stranded in bspland" season 3, episode 25 hahaha
<DC-IRC>
[Discord] <rpardini> bsp kernel is small price to pay for enjoying the userspace work of the grandmasters
<DC-IRC>
[Discord] <rpardini> oh btw @spooky8086 I stole your `jammy` vendor kernel branch and pushed as `rk-5.10-rkr8` for 5.10.209 goodness. Hope that's ok. I dropped your packaging and some useless Meko stuff, and picked some of the -rkr6 commits done more recently.
<DC-IRC>
[Discord] <monkablyat> Grand Theft BSP
<DC-IRC>
[Discord] <zeeto9> Does this apply to mainline version? Iβm putting armbian back onto another orange pi 5 plus, but in the past I never got hw acceleration working. If this is for mainline, when I build, I need to ensure mesa-vpu is disabled and this will allow for the ppa to work?
<DC-IRC>
[Discord] <spooky8086> Not a problem, the bsp is cursed in general π
<DC-IRC>
[Discord] <zeeto9> Does this apply to mainline version? Iβm putting armbian back onto another orange pi 5 plus, but in the past I never got hw acceleration working. If this is for mainline, when I build, I need to ensure mesa-vpu is disabled and this will allow for the ppa to work?
<DC-IRC>
[Discord] <zeeto9> I guess my question really is: in this situation, what is βnormal imageβ
<DC-IRC>
[Discord] <nicod_sbc> Not for mainline, only for legacy kernel.
<DC-IRC>
[Discord] <zeeto9> Oh ok. Thanks for the quick response. That makes sense since thatβs where Iβve been using those ppa so far, on the 6.1 versions.
<DC-IRC>
[Discord] <Tonymac32> I don't completely disagree, but I would say that all of this effort simply prolongs the pain, there's no reason for any of these lazy ass SoC vendors to be anything other than second rate university script kiddies with their kernels if the community keeps saving them from their own failure
<DC-IRC>
[Discord] <runaway97> yup
<DC-IRC>
[Discord] <runaway97> how about people let them figure their shit together, then decide if buying the board is worth it from a software standpoint?
<DC-IRC>
[Discord] <runaway97> falling for hardware specs on paper can't get any dumber
<DC-IRC>
[Discord] <Tonymac32> we are all human, and that means we're like goldfish. "oooo shiny" π
<DC-IRC>
[Discord] <Tonymac32> well, most of us are human. I suspect there are a few bots around π
<DC-IRC>
[Discord] <runaway97> yeah. one lie i like to tell myself from time to time is that "software will come"
<DC-IRC>
[Discord] <runaway97> one day
<DC-IRC>
[Discord] <runaway97> just not today
<DC-IRC>
[Discord] <Tonymac32> eventually, sometimes. Although in the case of the RK3328 as an example, it only "sort of" came
<DC-IRC>
[Discord] <runaway97> yeah and if they release rk3688 soon i feel like people will quickly forget about 3588
<DC-IRC>
[Discord] <Tonymac32> well, anyone caring about utility/stability is still rocking an RK3399 and might have some RK3568's
<DC-IRC>
[Discord] <Tonymac32> since those are fairly well covered
<DC-IRC>
[Discord] <Tonymac32> I have... 5? RK3588's, none of them are in use
<DC-IRC>
[Discord] <Tonymac32> I bought a T6, and a Rock5B. They seemed the most utility-driven. Oh, and a RK3588-NAS from FE
<DC-IRC>
[Discord] <Tonymac32> pi shapes are silly now unless you're under 10 watts
<DC-IRC>
[Discord] <runaway97> true
<DC-IRC>
[Discord] <monkablyat> Hydrogen-powered cauliflower recycling robot prototype 4.20 online and waiting for input
<DC-IRC>
[Discord] <rpardini> Well the bang-for-buck of rkmpp on vendor kernel and the community userspace is hard to beat.
<DC-IRC>
[Discord] <rpardini> And it's mostly due to nonstandard interfaces and half-specs and _userspace_ (ffmpeg/gstreamer/etc) -- not only kernel.
<DC-IRC>
[Discord] <rpardini> The Intel stuff is solid and in that sense any arm64 vdev/venc is just masochistic at this stage.
<DC-IRC>
[Discord] <Tonymac32> yeah, that's why I don't bother with that stuff on these devices. I *can* offroad a family sedan. It doesn't mean I *should*
<DC-IRC>
[Discord] <rpardini> I mean, for a regular user getting an Armbian vendor image and running a jellyfin container and getting out-of-box support for rkmpp is pretty equivalent to doing the same for Intel's Quicksync on a N100 say.
<DC-IRC>
[Discord] <rpardini> Except, it's done by 3 or 4 colleagues here against a vendor kernel and vendor libs.
<DC-IRC>
[Discord] <rpardini> So it's more like offroading the pieces of an alien spaceship and _winning_
<DC-IRC>
[Discord] <Tonymac32> yeah but we're not end users here. We're the poor bastards interfacing the alien spaceship parts toa Lada Niva and praying for rain so we can get bombed with github issues on specific codecs not working π
<DC-IRC>
[Discord] <Tonymac32> is this the "we're sorry the RK3588 only mostly worked" bugfix, or is this a nosedive off a cliff to pray they can get some market share back?
<DC-IRC>
[Discord] <Tonymac32> @rpardini there is a xiabao-nas-dts in the dts folder for rockchip64-6.11 and an "add board" patch that adds the dts. any thoughts on me removing that patch?
<DC-IRC>
[Discord] <Tonymac32> (in case dark magic is afoot)
<DC-IRC>
[Discord] <rpardini> Hmm I thought I converted it around 6.10.y
<DC-IRC>
[Discord] <Tonymac32> yeah the patch persists π
<DC-IRC>
[Discord] <rpardini> I've been... making mistakes.... recently
<DC-IRC>
[Discord] <Tonymac32> It builds without, I'll smoke it
<DC-IRC>
[Discord] <rpardini> There's a bunch of stuff in `dt` that landed upstream too
<DC-IRC>
[Discord] <rpardini> I added warning and listings during patching for those
<DC-IRC>
[Discord] <Tonymac32> cool, I'll keep an eye out
<DC-IRC>
[Discord] <rpardini> eg all the radxa-zero-3's landed
<DC-IRC>
[Discord] <mecoblock> I agree partially. Type-C Power input is fine (for example to be powered by almost any new monitor via one cable for DP too)
<DC-IRC>
[Discord] <mecoblock> that said a 12v dc input will always be a great power source
<DC-IRC>
[Discord] <Tonymac32> show me the TCPM driver on linux that doesn't need hacked all to hell for ~60% success rate with basic functionality and I'll agree
<DC-IRC>
[Discord] <Tonymac32> it's a pipe dream unless someone rewrites the driver stack and the hand-off from the bootloader to include state machine states
<DC-IRC>
[Discord] <Tonymac32> "Oh it works on my machine after 35 patches and when I hold my breath while glancing at an image of Linus Torvalds" isn't anything that should ever hit production
<DC-IRC>
[Discord] <Tonymac32> hmmm, I hadn't noticed anything for the type C drivers, I'll take a look
<DC-IRC>
[Discord] <Tonymac32> it's been broken for ... 7 years so far though π
<DC-IRC>
[Discord] <Tonymac32> it was literally the first question I asked Radxa when the rock5B was announced. π π π
<DC-IRC>
[Discord] <Tonymac32> the FR NanoPi M4 has this issue, the LC Renegade Elite, and a couple others I've played with
<DC-IRC>
[Discord] <Tonymac32> the FE NanoPi M4 has this issue, the LC Renegade Elite, and a couple others I've played with
<DC-IRC>
[Discord] <efectn> Barrel jack is far better than messing with tcpm drivers. Board manufacturers should stop pushing stupid usbc port for powert
<DC-IRC>
[Discord] <efectn> Barrel jack is far better than messing with tcpm drivers. Board manufacturers should stop pushing stupid usbc port for power
<DC-IRC>
[Discord] <Tonymac32> I mean, to Salva's point, I get it, it's "cool" to have so few wires
<DC-IRC>
[Discord] <Tonymac32> but yeah these devices don't include batteries so the engineering requirements are exponentially more demanding than a cell phone or tablet
<DC-IRC>
[Discord] <Tonymac32> I mean, to Meco's point, I get it, it's "cool" to have so few wires (I'm hallucinating names now)
<DC-IRC>
[Discord] <efectn> The friendlyarm's and khadas' way is not bad either i think. Separete stm32 means extra cost but works ootb at least
<DC-IRC>
[Discord] <Tonymac32> the old Radxa had a separate controller as well
<DC-IRC>
[Discord] <Tonymac32> the Rock4's are clean
<DC-IRC>
[Discord] <Tonymac32> but you can't use it for a hub setup
<DC-IRC>
[Discord] <Tonymac32> in theory if tcpm was working properly you could hook these things to a type C hub and get power and all your peripherals and monitor over a single cable
<DC-IRC>
[Discord] <Tonymac32> FriendlyARM learned after the M4, M4V2, etc
<DC-IRC>
[Discord] <Tonymac32> π
<DC-IRC>
[Discord] <efectn> Khadas also supports PD on rk35588's usb port as well as external MCU connected usbc port
<DC-IRC>
[Discord] <efectn> But it's not a problem since i don't use usb hub for powering π
<DC-IRC>
[Discord] <efectn> But it's not a problem for me since i don't use usb hub for powering π
<DC-IRC>
[Discord] <Tonymac32> yeah none of these things are worthy of desktop status at the end of the day so building around that expectation isn't realistic
<DC-IRC>
[Discord] <Tonymac32> (and before anyone chimes in that they use one of these as a desktop, sure, and I could absolutely do most of my daily tasks on windows 3.1. It's not about what you are willing to deal with, it's what the market actually expects)
<DC-IRC>
[Discord] <runaway97> yea it should definitely be done like this imo
<DC-IRC>
[Discord] <runaway97> USB-C PD-only for power alone
<DC-IRC>
[Discord] <runaway97> and another one for PD + data, if/when USB-C stack gets fixed
<DC-IRC>
[Discord] <microlinux> Maybe both connectors? Jack 12v and type C PD as option?
<DC-IRC>
[Discord] <Tonymac32> sehr teuer
<DC-IRC>
[Discord] <Tonymac32> would be expensive to implement
<DC-IRC>
[Discord] <Tonymac32> and PD will have a hard time as soon as you take "make USB ports actually support their standard current levels" into account
<DC-IRC>
[Discord] <Tonymac32> for example the Rock5B would been 14 watts available at all times just for USB
<DC-IRC>
[Discord] <Tonymac32> so 5V operation is out of the question
<DC-IRC>
[Discord] <Tonymac32> it's honestly the difference between a toy TV box pretending to be a general purpose computer and a.. well.. general purpose computer
<DC-IRC>
[Discord] <Tonymac32> at least they should document the port capabilities individually and in groups if they share power internally