prahal has quit [Remote host closed the connection]
dlan has joined #linux-exynos
cosm_ has joined #linux-exynos
isaque_cb has joined #linux-exynos
isaque_cb has quit [Remote host closed the connection]
isaque has joined #linux-exynos
afaerber has quit [Quit: Ex-Chat]
krzk has quit [Quit: Ex-Chat]
afaerber has joined #linux-exynos
afaerber has quit [Ping timeout: 250 seconds]
afaerber has joined #linux-exynos
ndufresne has joined #linux-exynos
<ndufresne>
o/
<javier__>
ndufresne: \o
* ndufresne
is GStreamer developper, maintaining V4L2 support (including m2m)
<javier__>
ndufresne: why are you still hacking on exynos4 btw? don't you have exynos5 boards?
<ndufresne>
I can't stand the fan (joke)
<ndufresne>
I'm hacking on the version 4 for various reason
<ndufresne>
One of the reason is that I already fixed FIMC there before and knows it's usable, while I'm not so sure of the state of the GSC
<ndufresne>
The team that wrote those driver didn't go very far in testing, and like getting buffersize wrong ;-P
<javier__>
ndufresne: Ok, fair enough
<ndufresne>
also, Exynos4 let me test a complex use case, which is the requirement for using a seperate IP block to de-tile the decoded images
<ndufresne>
another reason, because we often have regressions in both kernel and gst with older hw
<javier__>
ndufresne: I think the first step is to fix the MFC memory reservation nodes since the current values in mainline are pretty useless
<javier__>
and as you said, consolidate them in dtsi since the definitions are duplicated in almost all dts
<ndufresne>
yes, specially that for many embedded use cases, CMA is not a problem, but you need to know how to give it enough, some doc around it wil lbe nice
<ndufresne>
ok, btw, what I believe is the righ way to calculate the reservation is
<ndufresne>
(I'm missing one value in fact, I don't know how much extra the MFC OS needs, that is somewhere in the driver code for sure)
<ndufresne>
so let's say we want 1080p, 4 streams
<ndufresne>
(streams or instances if you prefer)
<ndufresne>
You need 1920 * 1088 * 12bits-per-pixel / 8bits-per-bytes * 16 (theorical maximum frames, if H264 is the worst)
<ndufresne>
though, when I worked on the Cotton Candy, I remember the MFC requeting up to 17 frames
<ndufresne>
but that was on small resolution, in general I see 9 frames
<ndufresne>
we need some loose, since userspace may need some extra to allow proper parallelism
Vasco_O is now known as Vasco
Vasco is now known as Vasco_O
<javier__>
ndufresne: now I've doubts again if this really belongs to the dtsi and not the dts. Since what could be possible may depend on how much RAM the board has
<ndufresne>
(we should also max it up to what we have reserved, rather then returning an error, that would be more v4l2 compliant)
Vasco_O is now known as Vasco
<javier__>
but yeah, I think that a sane default that allows to decode a H.264 1080p video makes sense for the dtsi
<javier__>
and dts can override as you said
<ndufresne>
if things where balanced, we could have something that allow up to 1 instance 1080p being the base minimum
<ndufresne>
and you'd get more instances if running lower resolution
<javier__>
ndufresne: do you know the difference between MFCv[4-8] ?
<ndufresne>
and a way to increase that if yo uare ready to use more ram
<javier__>
ups sorry I meant MFCv[5-8]
<ndufresne>
javier__: not in detail, at a certain point, the internal tiling moved from 64x32 in Z flip Z pattern to a linear 16x16 iles (to match the MALI)
<javier__>
ndufresne: I see
<ndufresne>
there was VP8 and I guess 9 in the 8 version that was added, but that's not breaking anything
<ndufresne>
some registered change, but that is clearly reflected in the driver structure
<javier__>
ndufresne: yeah
<ndufresne>
MFC is just an OS/Software we talk to using an IPC, I'm glad they documented it, since if you compare let's say with amlogic, they don't, as hte dev use to hack the drivers and the firmware at the same time
<javier__>
ndufresne: yes, things are not that bad on exynos for MFC
<javier__>
ndufresne: thanks a lot for your explanations, I know have a better idea of how these values should be setup
<javier__>
at least for my use case, I'm still not sure what we should do with the mainline dts[i]
<javier__>
I'm leaving for a while for lunch, bbl
<ndufresne>
I believe as long as we are unsure, we'll keep it this way
<ndufresne>
yep, lunch time for me too
<javier__>
ndufresne: agreed
<ndufresne>
if only we could have global constant in dts ;-P
LiquidAcid has joined #linux-exynos
bzyx has quit [Ping timeout: 246 seconds]
bzyx has joined #linux-exynos
afaerber has quit [Quit: Ex-Chat]
krzk has joined #linux-exynos
krzk has quit [Client Quit]
krzk has joined #linux-exynos
TheSeven has quit [Ping timeout: 250 seconds]
TheSeven has joined #linux-exynos
cosm_ has quit [Quit: Leaving]
krzk has quit [Quit: leaving]
Vasco is now known as Vasco_O
<Wizzup>
LiquidAcid: Can you point me at the kernel and libdrm patched required for your G2D armsoc