<chewitt>
I kept 'cache' as this is consistent with the newer dts changes. It's not present in any of the vendor kernel dts.
Emantor has joined #linux-rockchip
<chewitt>
I've initially started down the the route of making regs/h264/hevc files, but I don't think this is needed
<chewitt>
the main changes I can see are 4K not 8K, and single vs. multi core
<chewitt>
the 381 files already handle 1080p/4K/8K media
<chewitt>
so I've capped capabilities at 4K in adding the variant, and that should prevent you ever reaching an 8K path
<chewitt>
although both 3588 and 3576 in detlevs patches set e.g. '.max_width = 65520' so I'm not sure where those values are from
<diederik>
'cache' should absolutely be there for VDPU346. It wasn't listed in the/my old patch, but I found in the TRM that it should be there
<chewitt>
same for '.max_height = 65520'
<chewitt>
the assigned-clock-rates are cribbed from the vendor dts
<diederik>
supported image size for H264 is "16x16 to 65520x65520" (page 375 TRM part 1)
<chewitt>
and assigned-clocks in the upstream codebase omits the clock with a zero rate
<diederik>
yeah, the assigned-clocks was just wrong
<diederik>
I had/have trouble finding out what 'assigned-clocks' actually is (and what's different vs 'clocks'). All I found was that it was an array of phandles
<diederik>
(so that's one of the things I wanted research further before making/posting my RFC patch)
<diederik>
supported image size for H265 is "64x64 to 65472x65472" ... (page 374)
<diederik>
"1920x1088" is another odd number
<diederik>
(I have no idea about 3576; no device and no TRM)
<diederik>
I noticed 'cache' was missing in the vendor kernel too. And I'm reasonably sure their unit address is wrong (and yours is right)
<chewitt>
for 3588 and 3576 the addresses are clearly sequential between the regs and then mmu
<chewitt>
so I've just followed the same pattern
<diederik>
what is a bit odd (and confusing) is that the TRM says the "max (re)solution is up to 64K x 64K" ... which normally would means 65536x65536 ...
<chewitt>
my ability to read TRM type documents is not brilliant
<chewitt>
i'm quite good at educated guesswork though :)
<diederik>
my ability isn't great either, but I 'happen' to find all the right info (and thereby felt confident I could create a patch after all)
<chewitt>
anyway.. i'm afk, need to do a 16k training run, so back in a couple of hours
<diederik>
enjoy :)
<chewitt>
unlikely.. it's 33ºC with 'feels like 42ºC' humidity .. time to go sweat 3kg out
<chewitt>
(I moan, but this is normal here at this time of year)
Daanct12 has joined #linux-rockchip
<CounterPillow>
diederik: H.264 and H.265 place certain constraints on resolutions, namely that they need to be a multiple of the smallest block size of those codecs iirc. That's why you get 1088 pixels in height, it's 16*68. The actual area that contains meaningful data is in that case 1920x1080 and the parts outside of it are cropped off by the decoder because there is no information there, just whatever funny smears and patterns the coding
<CounterPillow>
produces
hexdump01 has quit [Ping timeout: 244 seconds]
hexdump01 has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
hexdump01 has quit [Ping timeout: 256 seconds]
npcomp has quit [Ping timeout: 256 seconds]
hexdump01 has joined #linux-rockchip
npcomp has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]
<chewitt>
although this means there's currently no real-world difference between vdpu346 and vdpu381 to justify having a separate variant and compatible
<chewitt>
so I guess we need to spot register differences
<chewitt>
although these are likely only minor changes, so creating vdpu346 specific h264, hevc, reg files will be a large copy/paste from vdpu381
<chewitt>
which is bad, as there'll be a ton of code duplication
<chewitt>
and my very n00b level coding skills aren't enough for a proper dedupe refactoring :)
System_Error has quit [Remote host closed the connection]
<chewitt>
diederik according to the datasheet 3568 does not support av1/avs2
System_Error has joined #linux-rockchip
<Kwiboo>
I should probably review the v2 of detlev rkvdec patches instead of waiting for v3 ones, but I do not understand the use of vdpu38x_fill_pixfmt_mp, internal use of .step_width = 64 should provide same alignment and the reason why it is like that for rkvdec1 part
maz_ is now known as maz
naoki has quit [Quit: naoki]
warpme has joined #linux-rockchip
warpme has quit [Client Quit]
<diederik>
CounterPillow: makes sense, thanks :)
eballetbo has quit [Quit: Connection closed for inactivity]
<diederik>
chewitt: ttbomk rk3568 does indeed not support avs2. That's why seeing avs2 mentioned as one of the decoder modes (TRM Part 2 page 558) is 'interesting'. (And it turns out it's also mentioned in various other registers)
<chewitt>
I'd expect the creation of TRM docs to be handled by some kind of internal 'docs' team who are not chip engineers themselves
<chewitt>
and while 'review' will be a step before publishing, the probably very-busy chips engineers prob. do little more than skip/scan read them
<chewitt>
I know I would suck at spotting copy/paste mistakes in that kind of doc :)
<chewitt>
and if you know the latest chip is a mashup of bits from earlier chips; you import sections to save time and then rework/massage them a little
<chewitt>
tl/dr; there's a reason docs start with a revisions table
<diederik>
There are also various hardware revisions ...
<chewitt>
the silicon itself is a copy/paste exercise of various IP blocks, so you probably end up with bits leftover from previous designs
<diederik>
Even if you're right, I'm going to assume the TRM is right, unless I have very strong belief it isn't. Otherwise you'll end up in a position that you believe everything you want to believe; and not what you don't like
<chewitt>
and sometimes bits are copied more wholesale but then intentionally disabled in some way
<chewitt>
I'd trust the datasheet for overall features/capabilities; the decision about whats in/out is entirely done by product marketing
stikonas has joined #linux-rockchip
<diederik>
VDPU346 and VDPU381 have a lot of similarities, but IMO it does warrent a separate compatible as there are various differences
<chewitt>
engineering then takes the fastest route to achieving that featureset
<chewitt>
I agree the compatible is needed
<chewitt>
the challenge is how to implement that without wholesale duplicating the drivers
<chewitt>
the differences are likely quite small, so you have high levels of boilerplate like duplication
<chewitt>
I'm confident I (we) can spot some reg differences and make something that works
<diederik>
If you put 3568 Part 2 para 10.4.3 and 3588 Part 1 para 5.4.3 side by side, you can easily spot 'minor' differences
<chewitt>
but it will duplicate loads and that's bad code, and the refactoring of that is beyond my copy/pasting l33t skiilz :)
<diederik>
H265: Main10 + Level 5.1 vs Main + Main10 + Level 6.1 f.e and RK3588 has in quite a number of case more of 'things' (not sure if they're registers or sth else)
<chewitt>
old dogs can learn new tricks, but 'time to value' is poor
<diederik>
I can probably identify the differences (and list them), but I haven't gotten further then "I think we need to do 'something' with some 'data' object as I've seen in various places"
<diederik>
But to actually implement that, I'd need external help by someone who can implement that (properly) (IOW: I'm in pretty much the same boat as you)
<diederik>
I do have several suggestions to improve the commit messages, but if the contents is the same as before, then I'd be quite pleased with that
<diederik>
(AV1 is handled by VDPU981, not VDPU381; for example)
<chewitt>
I've spotted where the 5.1 vs 6.1 difference is handled
<chewitt>
'vdpu38x_hevc_ctrl_descs' in rkvdec.c
<chewitt>
If you can list out the differences we can do some detective work on what changes to make
<chewitt>
in testing with Jellyfish files, I can play the 10mbps HEVC ones fine, but 15mbps and up show stuttering
<chewitt>
that feels a bit low for a modern board
<chewitt>
(unless it's the wifi-bridge connection speed)
<chewitt>
3588 board is handling 300mbps fine :)
<chewitt>
(connected on Gbit ethernet)
<chewitt>
it's the same for both H264 and HEVC files
<diederik>
That still sounds like a very improvement over my (previous) test results, where 3mbps seemed to be the point where things got more difficult
<diederik>
I'm still figuring out how to update my 'media-next' branch; I found a "media: rkvdec: Add HEVC support for the VDPU381 variant" commit which wasn't there when I grabbed the patches ...
raster has quit [Quit: Gettin' stinky!]
Daanct12 has quit [Quit: WeeChat 4.7.1]
<chewitt>
[ 3179.533241] rk_iommu fe043e00.iommu: Page fault at 0x00000000028e7240 of type read
<diederik>
Finally tracked down where the HEVC VDPU381 'came from'. Its code was present in my patches, just 'merged' into 'Add H264 support for VDPU383'; now it's a separate commit
<chewitt>
I loath the 'patch bundles' approach that LE uses in a few places
<chewitt>
It ends up being considerably easier to keep each commit in its own patch
<chewitt>
the number of patches can get large, but packaging can always be automated
<diederik>
Yeah, I don't understand the reason for that. Separate patches is so much easier to handle and track progress
FergusL6 has joined #linux-rockchip
FergusL has quit [Ping timeout: 252 seconds]
FergusL6 is now known as FergusL
<diederik>
chewitt: what happened to 'fixup_variant' ?
<chewitt>
squashed
<diederik>
thanks.
psydroid has quit [Ping timeout: 255 seconds]
<diederik>
I *think* the values for 'fixup_variant' aren't correct. Those seem to be the values for VDPU381
<diederik>
for VDPU346, H265 has 4096x2304 as supported image size; for H264 it's also 4096x2304 (page 469 RK3568 TRM Part 2)
<diederik>
and min_width and min_height should be 64; step size is 16 for both ... and those values are the same between VDPU346 and VDPU381
stikonas has quit [Quit: Konversation terminated!]
<diederik>
for H264 the min_width and min_height are 16; step size is also 16
psydroid has joined #linux-rockchip
<diederik>
hmmm ... maybe I'm not understanding things correctly? (Or there are various issues with detlev's code; me being wrong seems more likely)
<chewitt>
"supported image size for H265 is "64x64 to 65472x65472" ... (page 374)" <= from you, yesterday
<diederik>
yes, thus .min_width and .min_height should be 64. You have them at 16
<diederik>
for H264 you have .min_width = 64 and .step_width = 64 and those should both be 16
<sre>
Since we are talking about Linux specifically: The clocks DT property is used by the consumer driver, e.g. video decoder driver. OTOH assigned-clocks works independently from it
<diederik>
(bit embarrassing that I missed that though)
<sre>
Modern platforms often use a combination. The driver requests a bunch of clocks, that it needs to be operational. It does not explicitly request a specific frequency, so that the driver works on multiple platforms (which potentially offer different frequencies).
<sre>
Then assigned-clocks is used to assign a known good clock frequency
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
veremitz- has joined #linux-rockchip
cbeznea has quit [*.net *.split]
npcomp has quit [*.net *.split]
veremitz has quit [*.net *.split]
clarity has quit [*.net *.split]
Net147 has quit [*.net *.split]
diederik has quit [*.net *.split]
veremitz- is now known as veremitz
cbeznea has joined #linux-rockchip
clarity has joined #linux-rockchip
Net147 has joined #linux-rockchip
diederik has joined #linux-rockchip
npcomp has joined #linux-rockchip
<dsimic>
wens: gah, so it seems you'll have to shop a bit and get a beefier PSU :/
<dsimic>
it's actually quite expected for ~15 W not to be enough power when all CPU cores are loaded and the NVMe SSD does a lot
<diederik>
chewitt: Kwiboo responded to my mails about this and IIUC then .min_width, .step_width and .min_height should all be 64, but .step_height be 16
<chewitt>
for HEVC?
<diederik>
I interpreted it as for both HEVC and H264
warpme has joined #linux-rockchip
chewitt has quit [Quit: Zzz..]
warpme has quit [Ping timeout: 250 seconds]
cbeznea_ has joined #linux-rockchip
diederik has quit [Ping timeout: 258 seconds]
cbeznea has quit [Ping timeout: 258 seconds]
diederik has joined #linux-rockchip
warpme has joined #linux-rockchip
<Dex2x>
has anyone tried to use a TF to EMMC adapter to boot from that over an sdcard?
raster has joined #linux-rockchip
warpme has quit [Ping timeout: 258 seconds]
<Kwiboo>
diederik: yes for buffers to be aligned correctly the step_width is set to 64, that way for 8-bit buffers are aligned to 64 bytes, and for 10-bit buffers are aligned to 80 bytes, i.e. buffers always end up aligned to 16 bytes
warpme has joined #linux-rockchip
warpme has quit [Ping timeout: 256 seconds]
warpme has joined #linux-rockchip
warpme has quit [Ping timeout: 255 seconds]
Net147_ has joined #linux-rockchip
clarity has quit [Ping timeout: 258 seconds]
<diederik>
And so that is indeed regardless of format, thx
<dsimic>
Dex2x: I forgot to mention that Kingston makes high-endurance microSD cards that are A1 rated, i.e. with high random I/O performance
<dsimic>
other brands seemingly don't have such A1-rated cards... maybe Samsung has, but I don't know much about its product range there
<dsimic>
SanDisk doesn't, I know that for sure
<Dex2x>
I have a sandisk, high endurance, u3, v30
<dsimic>
it lacks "A1", which is very important
<Dex2x>
But somethings the boards don't support the high speeds and don't have the firmware/driver needed for that, and slows it down
<dsimic>
the sequential I/O performance is much less important than random I/O
<Dex2x>
sandisjk extreme is A2
<dsimic>
is it hgh endurance?
<dsimic>
is it high endurance? *
<Dex2x>
Not sure what their extreme line is
<dsimic>
it isn't high endurance
<Dex2x>
but I see the kingston endurance A1fc
<dsimic>
let me repeat that, AFAIK, SanDisk makes no high endurance microSD cards that are A1 rated
<dsimic>
and the A1 rating denotes high random I/O performance offered by the card
<dsimic>
the higher A2 rating requires host-side support
<Dex2x>
wow they have a max endurance
<dsimic>
it's all nice, but is it A1 rated?
<Dex2x>
not that I see
<dsimic>
you seem to ignore most of what I keep eriting :/
<dsimic>
s/eriting/writing/
<Dex2x>
No I was just saying what I found on their site, I was looking to see if any are A1 rated
<dsimic>
I see
<dsimic>
it's nice that more high-endurance options are out there, but if they're not A1 rated, they're good for dash cameras and stuff like that only
<Dex2x>
Okay so it's A2 that requires the host as well for that?
<Dex2x>
I have honestly forgotten a bit about what the A2 and A1 meant
<dsimic>
yes, the higher A2 rating requires host-side support
<Dex2x>
just that one needs host to have the needed driver
<dsimic>
according to the specs, it's unclear do A2-rated cards also provide A1 rating with no host-side support in place
warpme has joined #linux-rockchip
<dsimic>
maybe they do, but also maybe they don't
warpme has quit [Ping timeout: 258 seconds]
<Dex2x>
well I am going to order 2x of the a1 endurance from kingston
<Dex2x>
sandisk has WD microsd cards? And industrial ones. I did not know this
<CounterPillow>
SanDisk is a brand owned by WD
<Dex2x>
TIL, I did not know this
warpme has joined #linux-rockchip
<dsimic>
Dex2x: IMHO, it's hard to go wrong with the Kingston A1-rated high-endurance microSD cards... they're also quite fast, I even had the Linux kernel git repository on one of them and it worked rather fast
warpme has quit [Ping timeout: 250 seconds]
stikonas has joined #linux-rockchip
warpme has joined #linux-rockchip
warpme has quit [Ping timeout: 258 seconds]
<Dex2x>
thanks dsimic will help for my orangepi 5
<Dex2x>
I think I will get an odroid h4plus as well though
warpme has joined #linux-rockchip
cbeznea has joined #linux-rockchip
cbeznea_ has quit [Read error: Connection reset by peer]