ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion
crabbedhaloablut has quit [Ping timeout: 268 seconds]
crabbedhaloablut has joined #linux-rockchip
stikonas has quit [Ping timeout: 272 seconds]
lurchi_ is now known as lurchi__
kilobyte_ch has quit [Ping timeout: 268 seconds]
smaeul has joined #linux-rockchip
kilobyte_ch has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 245 seconds]
kevery1 is now known as kevery
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 252 seconds]
kevery1 is now known as kevery
Danct12 has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 252 seconds]
kevery1 is now known as kevery
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #linux-rockchip
loki_val has joined #linux-rockchip
crabbedhaloablut has quit [Remote host closed the connection]
lurchi_ has joined #linux-rockchip
lurchi__ has quit [Ping timeout: 252 seconds]
indy has quit [Quit: ZNC 1.8.2 - https://znc.in]
indy has joined #linux-rockchip
indy has quit [Client Quit]
indy has joined #linux-rockchip
indy has quit [Quit: ZNC 1.8.2 - https://znc.in]
indy has joined #linux-rockchip
indy has quit [Quit: ZNC 1.8.2 - https://znc.in]
indy has joined #linux-rockchip
Danct12 has quit [Read error: Connection reset by peer]
loki_val has quit [Remote host closed the connection]
Daanct12 has joined #linux-rockchip
crabbedhaloablut has joined #linux-rockchip
rembo10 has quit [Quit: ZNC 1.8.2 - https://znc.in]
rembo10 has joined #linux-rockchip
ldevulder_ is now known as ldevulder
ldevulder has quit [Read error: Connection reset by peer]
ldevulder has joined #linux-rockchip
ldevulder has quit [Remote host closed the connection]
ldevulder has joined #linux-rockchip
Daanct12 has quit [Remote host closed the connection]
crabbedhaloablut has quit [Ping timeout: 268 seconds]
crabbedhaloablut has joined #linux-rockchip
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #linux-rockchip
stikonas has joined #linux-rockchip
chewitt has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 268 seconds]
kevery1 is now known as kevery
s1b1 has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
s1b1 has joined #linux-rockchip
lurchi_ is now known as lurchi__
crabbedhaloablut has quit [Ping timeout: 268 seconds]
crabbedhaloablut has joined #linux-rockchip
warpme___ has joined #linux-rockchip
stikonas_ has joined #linux-rockchip
stikonas has quit [Ping timeout: 240 seconds]
matthias_bgg has quit [Quit: Leaving]
stikonas_ has quit [Remote host closed the connection]
stikonas_ has joined #linux-rockchip
stikonas_ has quit [Remote host closed the connection]
stikonas_ has joined #linux-rockchip
stikonas_ is now known as stikonas
psydroid2 has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
Jmabsd has joined #linux-rockchip
<Jmabsd> Hi all, a general ARM question:   How is hardware video decoding implemented in Linux (and say FreeBSD) for ARM64?
<jakllsch> it depends
<Jmabsd> I think for Intel, hw video decoding is in a library called libva*. Is there some analogous library for ARM64?
<Jmabsd> jakllsch: tell
<jakllsch> sometimes it's done via vaapi, sometimes it's done via v4l2
chewitt has quit [Read error: Connection reset by peer]
chewitt has joined #linux-rockchip
<Jmabsd> jakllsch: I see.  This decoding depends on that the ARM64 video hardware has been fed with the right binary blobs right?
<Jmabsd> Is that driver uploading accomplished by Xorg logics (in kernel or userland)?
<jakllsch> again it depends
<Jmabsd> Tell =)
<Jmabsd> Did anyone discuss this extensively?
<jakllsch> there are many video codec hardware cores
<jakllsch> each might have its own driver
<jakllsch> and you might have it on a seperate GPU chip
<jakllsch> some use microcode, others might not
<jakllsch> some might supply libva drivers, others might supply v4l2 drivers
<jakllsch> not sure FreeBSD has video codec drivers on embedded aarch64 at this point
<jakllsch> NetBSD is probably only just getting hw video codecs working on PC-style GPUs
<Jmabsd> OpenBSD has had Intel and AMDGPU graphics implemented.
<Jmabsd> However may not be bundled with the OS yet
<Jmabsd> Why is ARM64 so much after?
<jakllsch> because it's (generally) not the same hardware
<jakllsch> different drivers
<Jmabsd> cool. is any web site devoted to hw video decoding on ARM64?
<jakllsch> probably not
<Jmabsd> ic
<Jmabsd> is hw video decoding on ARM64 well supported on Linux?
<Jmabsd> for various SoCs
<jakllsch> depends
<jakllsch> does Android count as Linux?
<Jmabsd> maybe
<Jmabsd> so Android has it?
<Jmabsd> Androids
<Jmabsd> for proper Linuxes like Debian, Armdroid, what's the video decoder support situation
<jakllsch> Android phones will generally have working hw video codecs
<Jmabsd> sometimes with closed source patches? duh
<jakllsch> usually not even with upstreamed drivers..
<Jmabsd> Does Rockchips have upstreamed drivers?
<jakllsch> i think that might even depend on the SoC
<jakllsch> but it's being worked on at least
<Jmabsd> any URL documents the progress?
<jakllsch> probably not
<Jmabsd> i see
<Jmabsd> so open source drivers?
<jakllsch> i think so
<Jmabsd> but still hardware blob right
<Jmabsd> the hw video decoder is some ARM proprietary IP isn't it
<jakllsch> not sure; i think at least one of the codec cores used don't need microcode
jagan has joined #linux-rockchip
<jakllsch> some rockchip SoCs actually have multiple codec cores in the same SoC that use different drivers
<urja> i think for rockchip it's not ARM, it's rockchip (not sure if they bought it though, i have not gone in depth... and also i dont know of the newest stuff)
<jakllsch> sometimes even with overlapping codec standard support
<Jmabsd> wow. how much variety among ARM64:s does there exist in terms of how hw video decoding is done ????
<Jmabsd> so it's not a part of the normal graphics output acceleration??
<jakllsch> it's seperate from the GPU usually, yes
<jakllsch> (the GPU handles 3D and surfaces and whatnot)
psydroid3 has joined #linux-rockchip
psydroid2 has quit [Read error: No route to host]
<mps> I'm far for video expert but on my rk3399 gru-kevin playing video is faster and with a lot less load with panfrost than without it
<mps> s/for/from/
<Jmabsd> mps: what is gru-kevin??
<urja> it's a samsung chromebook plus
<urja> anyways that's just because you have surfaces/layers
<Jmabsd> urja: ?
<urja> https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/ kevin is googles codename for that chromebook (the baseboard is gru)
<Jmabsd> ah right, gru-kevin is a chromebook
<Jmabsd> ahh, so what is "panfrost"
<Jmabsd> okey cool "The Panfrost driver stack includes an OpenGL ES implementation for Arm Mali GPUs based on the Midgard and Bifrost microarchitectures. It is conformant on Mali-G52 and Mali-G57 but non-conformant on other GPUs. The following hardware is currently supported:"
<urja> the open source ARM Mali midgard-and-newer driver (just installing mesa gives you that)
<mps> urja: and the kernel panfrost driver
<urja> ah yes
<Jmabsd> cool
<Jmabsd> mps,urja,jakllsch: Are the Panfrost/Lima MALI drivers *a form of* libva/v4l2 driver, or is it separate from those?
<Jmabsd> Does Mali do video decoding??
<urja> separate, they're OpenGL drivers, not decoding accelerators
<Jmabsd> aha icic
<urja> they help to composite the output once it is decoded
<Jmabsd> https://github.com/heiher/libmali-rk3399 curious what this is
Jmabsd has quit [Quit: Client closed]
warpme___ has quit [Quit: Connection closed for inactivity]
<a1batross> hi there. Is there a page describing current status of rk3568 support? I'm currently working on for-next branch of linux-rockchip repo, it seems it has some more work done on rk3568 than released kernels.
<a1batross> our device is based on radxa cm3 plus SoM. So far, it works fine enough with a bit modified dts of radxa3 board
<mriesch> a1batross: https://wiki.pine64.org/wiki/Quartz64_Development targets the rk3566 but can be applied pretty much 1:1 to rk3568
psydroid3 has quit [Remote host closed the connection]
psydroid3 has joined #linux-rockchip
<a1batross> mriesch: yeah, saw that page. It helps that 66 and 68 like sister chips... :)
<a1batross> thanks anyway :)
lurchi__ is now known as lurchi_
psydroid3 has quit [Remote host closed the connection]
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
stikonas has quit [Ping timeout: 276 seconds]
lurchi_ is now known as lurchi__