<stdint>
wzyy2, yes, I got that, it looks that it use the wrong video
<stdint>
but I can't confirm before I downloaded that
<stdint>
wzyy2, next time, just close that kind of issue, and tell they to submit it to the right place
cnxsoft has joined #linux-rockchip
LongChair1 has joined #linux-rockchip
LongChair has quit [Remote host closed the connection]
LongChair1 is now known as LongChair
wzyy2 has quit [Ping timeout: 260 seconds]
geekerlw has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
geekerlw has quit [Quit: Leaving]
lkcl has joined #linux-rockchip
bbelos has quit [Ping timeout: 258 seconds]
bbelos has joined #linux-rockchip
cosm has quit [Ping timeout: 258 seconds]
cnxsoft1 has joined #linux-rockchip
cnxsoft has quit [Ping timeout: 248 seconds]
cnxsoft1 is now known as cnxsoft
wadim_ has joined #linux-rockchip
paulk-collins has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
Aussie_matt has joined #linux-rockchip
<stdint>
paulk-collins, may I send you private message
<paulk-collins>
stdint, sure
Aussie_matt has quit [Remote host closed the connection]
<phh>
stdint: mpp can work without a (drm or ion) display output, but gstreamer-rockchip can't, am I understanding correctly?
<stdint>
phh, no, you could plus the fakesink with it
<phh>
ah, interesting thanks
<phh>
stdint: so using "drm" allocator, is not related to "vop" drm?
<stdint>
phh, a little hard to say
<stdint>
in theoretically, it only need a buffer allocation, which we use drm currently
<stdint>
but what we do is using the iommu of vop to allocate buffers
<stdint>
without iommu help, we can't allocate so many large buffer
<phh>
stdint: I'm trying to pinpoint where my problem can be. in vcodec_iommu_drm in vcodec_drm_map_iommu, instead of invalidate_tlb I did vcodec_drm_detach(); vcodec_drm_attach()
<phh>
oh wow
<phh>
I thought that was vpu's iommu
<stdint>
phh, yes it is
<stdint>
there are two iommu invoked
<stdint>
I can't use the iommu of vop for VPU to access memory
<phh>
ah, but when rendering the frame from vpu result to vop you need to
<stdint>
the decoded YUV buffer is from VOP iommu
<stdint>
and I need to update the iommu of vpu to import that buffer
<phh>
i see
<phh>
well I really don't see that in the code, but well...
<stdint>
phh, no they don't do that in kernel
<phh>
stdint: so, a difference in drivers/gpu/drm/rockchip could explain the problems I'm noticing?
<stdint>
rockchip mpp just send a fb of the buffer into vcodec driver
<stdint>
then vcodec driver translate that fb into dma buffer and update the iommu of vpu\
<stdint>
phh, I think it just make the vop use iommu instead of default software allocator
<phh>
ok, that's why you were mentioning that I could hit an allocation problem, understood
nighty has quit [Quit: Disappears in a puff of smoke]
<phh>
stdint: so, the vcodec_drm_map_iommu function is only to do the vop iommu?
<stdint>
phh, yes
andoma has quit [Read error: Connection reset by peer]
<stdint>
also hevc iommu if you use that IP
<phh>
so, the rockchip_iovmm_invalidate_tlb call is irrelevant when using fakesink
<stdint>
phh, of course
andoma has joined #linux-rockchip
<phh>
so... my decoding issue is not tlb \o/
andoma has quit [Ping timeout: 240 seconds]
<phh>
stdint: would there be a reason for HEVC to work better than h264 except for speed matters?
<stdint>
phh, have you tried the always power on?
<stdint>
phh, if the hard reset would work, it is not harm to keep the power always on
<phh>
which always power on?
<stdint>
phh, just that IP is well designed
<phh>
oh I forgot, when I try to read h265 with fakesink, I get a kernel panic. I really need to get a serial cable
<stdint>
phh, comment all the vpu power off sentence
<phh>
oh ok
ssvb has quit [Read error: Connection reset by peer]
<phh>
stdint: h265 decoding doesn't depend on vpu_service at all, only hevc_service/
<phh>
?
<phh>
I mean IP-wise
nighty has joined #linux-rockchip
<stdint>
phh, sorry I just go for dinner
<stdint>
phh, yes
<stdint>
phh, and they could work at the same time
<phh>
don't worry you're allowed to have a lie -_-'
<phh>
life*
<phh>
I'll try more extensively to ese if I see a difference between h265 and h264
<stdint>
phh, there are two iommu for hevc as well
<stdint>
you may forget to update the write iommu with hevc
<stdint>
I remember I meet that problem when I was developing that
matthias_bgg has quit [Quit: Leaving]
matthias_bgg has joined #linux-rockchip
libv_ has joined #linux-rockchip
libv has quit [Ping timeout: 255 seconds]
andoma has joined #linux-rockchip
paulk-collins has quit [Remote host closed the connection]
zoobab has joined #linux-rockchip
<zoobab>
hi
<zoobab>
if someone has a RK3399 board, could you run this test: