camus has quit [Remote host closed the connection]
camus has joined #linux-rockchip
Stat_headcrabed has joined #linux-rockchip
Stat_headcrabed has quit [Quit: Stat_headcrabed]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 264 seconds]
kevery1 is now known as kevery
jaganteki has quit [Quit: Client closed]
jaganteki has joined #linux-rockchip
Stat_headcrabed has joined #linux-rockchip
Stat_headcrabed has quit [Client Quit]
jaganteki has quit [Quit: Client closed]
superherointj has joined #linux-rockchip
jaganteki has joined #linux-rockchip
psydroid2 has joined #linux-rockchip
superherointj has quit [Quit: Leaving]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 245 seconds]
kevery1 is now known as kevery
stikonas has joined #linux-rockchip
warpme has joined #linux-rockchip
raster has quit [Quit: Gettin' stinky!]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
jaganteki has quit [Ping timeout: 250 seconds]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 246 seconds]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
<linkmauve>
CounterPillow, I’m reading the VEPU121 spec, it also supports H.264 encoding in addition to JPEG? Why is there also VEPU580 then?
<CounterPillow>
because that's the pretty garbo Hantro G1 encoder that they just didn't bother removing from the silicon
kevery has quit [Ping timeout: 260 seconds]
kevery1 is now known as kevery
<linkmauve>
Also do I read correctly that there are five of them present in the SoC?
<linkmauve>
Five “cores”.
<linkmauve>
Does that mean we can encode up to five JPEGs at once?
<CounterPillow>
correct
<linkmauve>
Neat.
<linkmauve>
And that also means we can encode up to seven H.264 frames at once?
<linkmauve>
Two on the non-garbo encoders, five on the garbo encoders.
<CounterPillow>
I don't think so, last I checked it seemed like four of the jpeg encoder cores were lacking the h.264 stuff, but I might be misremembering
<linkmauve>
Ah, that could make sense.
<linkmauve>
core0 has a different base address from the other four.
<linkmauve>
In struct hantro_dev, why are there enc_base and dec_base in the same struct? Are there devices with one VPU which does both decoding and encoding?
<CounterPillow>
Basically, due to a mistake :) When the driver was written, it wasn't clear yet that the encoder and decoder could be completely separate and at wildly different addresses
<linkmauve>
Ah, so that’s something to fix, thanks!
<linkmauve>
“* 1 - vpu2 for jpeg/vp8 encoder and decoder”, there is also a VP8 encoder?
<CounterPillow>
yeah
<linkmauve>
The only mention of VP8 in the TRM is about VDPU121.
<linkmauve>
Do you know where it actually is?
<CounterPillow>
The TRM tends to leave stuff out they don't want you to use, but the register offsets should be the same as in any previous implementations of that version of hantro
kevery1 has joined #linux-rockchip
<linkmauve>
:|
kevery has quit [Ping timeout: 264 seconds]
kevery1 is now known as kevery
<CounterPillow>
if it's exposed in MPP it probably works, even if it's not in the TRM :)
<linkmauve>
I guess I’ll try to fetch the TRM of a previous SoC, write the driver, and see if it actually works on this one.
<linkmauve>
Encoding VP8 could be nice for my library, then it could do both encoding and decoding for both WebP and JPEG.
<linkmauve>
CounterPillow, do you think it would make sense to expose the five JPEG encoders as five /dev/video* devices, or would it be better to hide that behind a single one and handle the complexity of parallel encoding in the driver?
<linkmauve>
Now that I’m writing that question I think the answer is obviously the latter.
<CounterPillow>
I've brought this up before in #linux-media iirc and somebody (I don't remember who) told me that it'd be reasonable to expose them all individually and have applications handle the parallel stuff, but either works
<CounterPillow>
Whatever you do, it definitely shouldn't leak into the DT though. DT should still list them all individually
<linkmauve>
Of course.
<CounterPillow>
I think having them all show up as just one /dev/video device has the advantage of the kernel being able to pick requests to encode JPEG to one that isn't busy
<linkmauve>
Yeah, it seems like both the most efficient and the easiest option for userland.
<linkmauve>
Is there a way in V4L2 to expose the known parallelism to userspace, so it can make informed decisions re buffer allocations and such?
<linkmauve>
I guess that’s a question for #linux-media.
<linkmauve>
CounterPillow, according to 3a2196fc41febcaad01e184e423f1fed6d68b37f, it supports two H.264 encoders and four JPEG encoders in parallel.
<linkmauve>
Not one and five.
<linkmauve>
See check_frm_task_cnt_cap().
<CounterPillow>
interesting
<linkmauve>
CounterPillow, do you usually run mpp and capture how it programs the hardware and then rewrite that in the kernel, or do you study its source code, or do you rely on the TRM?
<CounterPillow>
my rkdjpeg driver work was so primitive and in the early stages I didn't need to do any complex studying of anything so far, so I can't answer that question :)
<linkmauve>
Alright. :)
<linkmauve>
I might be interested in helping you out with that one, but I’m also probably taking more work than I can do atm. ^^'
<linkmauve>
Between this, JPEG decoding support in cedrus (that one is close!), the userspace library onix…
<linkmauve>
For VP8 encoding, vepu1 and vepu2 look very similar in mpp/hal/vpu/vp8e/hal_vp8e_vepu1_v2.c and mpp/hal/vpu/vp8e/hal_vp8e_vepu2_v2.c, basically only register renaming it seems.