•   
  • 1
  • 26
  • 27
  • 28(current)
  • 29
  • 30
  • 39
  •   
[i.MX6] XBMC running on Freescale SoC's
LeoKesler, wolfgar,

"__dma_free_remap: trying to free invalid coherent area: " errors are not related specifically to (only) the VPU DMA commit. I removed it a while ago and since then hit the dmesg message few times. the commit makes the error to appear a bit more often though.

Code:
[12147.428407] __dma_free_remap: trying to free invalid coherent area:   (null)
[12147.428443] [<c004d790>] (unwind_backtrace+0x0/0xf4) from [<c0050f38>] (dma_free_coherent+0x1a0/0x1d0)
[12147.428464] [<c0050f38>] (dma_free_coherent+0x1a0/0x1d0) from [<c04da7d8>] (vpu_release+0x208/0x2a8)
[12147.428483] [<c04da7d8>] (vpu_release+0x208/0x2a8) from [<c0100af4>] (fput+0xb8/0x1e4)

currently got this after watching live TV (tvheadend), SD resolution. this is what is in XBMC.log at least x1000 times

Code:
19:37:03 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 3
19:37:03 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 7
19:37:03 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 0
19:37:03 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 4
19:37:04 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 8
19:37:04 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 1
19:37:04 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 5
19:37:04 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 9
19:37:04 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 2
19:37:04 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 6
19:37:05 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 10
19:37:05 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 3
19:37:05 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 7
19:37:05 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 0
19:37:05 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 4
19:37:05 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 8
19:37:06 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 1
19:37:06 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 5
19:37:06 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 9
19:37:06 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 2
19:37:06 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 6
19:37:06 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 10
19:37:07 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 3
19:37:07 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 7
19:37:13 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 6
19:37:13 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 9
19:37:13 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 2
19:37:13 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 10
19:37:14 T:1429124096  NOTICE: VpuDeQueueFrame - Release expired buffer - idx : 3

it started a bit like low FPS (~2), but after few seconds it normalised and worked until I stopped it (~30min). and as the player stopped, the message was thrown into dmesg.

dmesg was during playing constantly filled with
Code:
[12129.620860] mxc_v4l2_output mxc_v4l2_output.0: Enable deinterlace TB.
[12129.620870] mxc_v4l2_output mxc_v4l2_output.0: v4l2 frame_cnt:5331, vb_field:8, fmt:0
[12129.629087] mxc_v4l2_output mxc_v4l2_output.0: disp work finish one frame
[12129.660655] mxc_v4l2_output mxc_v4l2_output.0: warning: timer timeout already expired.
[12129.660681] mxc_v4l2_output mxc_v4l2_output.0: timer handler next schedule: 1392489525086980259nsecs
[12129.660768] mxc_v4l2_output mxc_v4l2_output.0: disp work begin one frame
[12129.660777] mxc_v4l2_output mxc_v4l2_output.0: Enable deinterlace TB.

for each and every frame number (I have loglevel 7). I have the feeling that "deinterlacing" was there part of a discussion.

Also I can confirm that HDMI_CEC connection is broken with (almost) each fatal video error. Looks like it can't survive "resets", "reconnects" or even this errors sometimes: ERROR: GetPicture - player is ahead of time (114939.105933) Sad
Reply
Hi mk01

You can disable deinterlacing that way :
export IMX_DEINT_MOTION=-1
before launching xbmc if you think there is something bad with it

For your DMA issue I don't know : I have run my utilite all the day on SD channels (to perform endurance testing) and it is still playing perfectly after 12hours (source being SD channels)
To be clear : My current kernel has no longer the VPU wandboard patch in it (with this patch I also have issues very quickly)

Regards
Stephan
Reply
@stephan

Is this the kernel you use ?
https://github.com/wolfgar/linux/commits...0.35_4.1.0

Or do have you some other patches also?

hste
Reply
(2014-02-10, 14:14)Koying Wrote: In https://github.com/koying/xbmc/commits/imx , I've squashed your commits up to now (not the 1080i fixes) and I've baselined pure software rendering.
Hey wolfgar,
Got rendering via VIVANTE direct egl texture working Smile
Reply
(2014-02-16, 13:48)hste Wrote: @stephan

Is this the kernel you use ?
https://github.com/wolfgar/linux/commits...0.35_4.1.0

Or do have you some other patches also?

hste
Hi hste,

I use this one :
https://github.com/wolfgar/utilite/commi...af40ac9054

Stéphan



(2014-02-16, 16:30)Koying Wrote:
(2014-02-10, 14:14)Koying Wrote: In https://github.com/koying/xbmc/commits/imx , I've squashed your commits up to now (not the 1080i fixes) and I've baselined pure software rendering.
Hey wolfgar,
Got rendering via VIVANTE direct egl texture working Smile

Hi Koying,

Congratulations !
I look forward to giving it a try...
Has the switch to vivante direct texture brought the expected benefits ?
I come back to you as soon as I have been able to give it a try

Best regards
Stephan
Reply
(2014-02-16, 17:12)wolfgar Wrote: Has the switch to vivante direct texture brought the expected benefits ?
I come back to you as soon as I have been able to give it a try
Main benefit, as far as I'm concerned, is to stay inside XBMC way of working as much as possible and to not be dependent on the kernel's V4L and/or fb support.

On the pro side, I don't see performance penalty (on cubox-i quad), XBMC's 3D support is working, as is VSYNC (with FB_MULTI_BUFFER=2).
On the con side, deinterlacing is not implemented, yet, and there is a corner-case issue with top-bottom 3D if the height is not mod-16, because cropping is a bit hacky.



On an other note, this DMA issue is a bitch.
I compile on the device and ld is fragmenting it like hell Wink
Reply
(2014-02-16, 16:30)Koying Wrote:
(2014-02-10, 14:14)Koying Wrote: In https://github.com/koying/xbmc/commits/imx , I've squashed your commits up to now (not the 1080i fixes) and I've baselined pure software rendering.
Hey wolfgar,
Got rendering via VIVANTE direct egl texture working Smile

Where are these functions found?

LinuxRendererGLES.cpp:2692:66: error: 'glTexDirectVIVMap' was not declared in this scope
LinuxRendererGLES.cpp:2693:45: error: 'glTexDirectInvalidateVIV' was not declared in this scope

Martin
Reply
(2014-02-16, 21:06)emveepee Wrote: LinuxRendererGLES.cpp:2692:66: error: 'glTexDirectVIVMap' was not declared in this scope
LinuxRendererGLES.cpp:2693:45: error: 'glTexDirectInvalidateVIV' was not declared in this scope
By me, they come from
Code:
#ifdef HAS_IMXVPU
// GLES extension functions
#include <GLES/gl.h>
#include <GLES/glext.h>
#endif
My image comes from http://imx.solid-run.com/forums/viewtopic.php?f=8&t=326
Reply
(2014-02-16, 21:38)Koying Wrote:
(2014-02-16, 21:06)emveepee Wrote: LinuxRendererGLES.cpp:2692:66: error: 'glTexDirectVIVMap' was not declared in this scope
LinuxRendererGLES.cpp:2693:45: error: 'glTexDirectInvalidateVIV' was not declared in this scope
By me, they come from
Code:
#ifdef HAS_IMXVPU
// GLES extension functions
#include <GLES/gl.h>
#include <GLES/glext.h>
#endif
My image comes from http://imx.solid-run.com/forums/viewtopic.php?f=8&t=326

Can you tell what is the parameters you use in .configure command line ?
Reply
Code:
./configure --enable-neon --enable-codec=imxvpu \
        --enable-gles --disable-sdl --disable-x11 --disable-xrandr --disable-openmax \
        --disable-optical-drive --disable-joystick \
        --disable-crystalhd --disable-vtbdecoder --disable-vaapi --disable-vdpau \
        --disable-pulse --disable-projectm
I'm using the "-fb" versions of libEGL, libVIVANTE & libGAL
Reply
(2014-02-16, 21:46)Koying Wrote:
Code:
./configure --enable-neon --enable-codec=imxvpu \
        --enable-gles --disable-sdl --disable-x11 --disable-xrandr --disable-openmax \
        --disable-optical-drive --disable-joystick \
        --disable-crystalhd --disable-vtbdecoder --disable-vaapi --disable-vdpau \
        --disable-pulse --disable-projectm
I'm using the "-fb" versions of libEGL, libVIVANTE & libGAL

I am getting this error:

LinuxRendererGLES.cpp: In member function ‘void CLinuxRendererGLES::UploadIMXMAPTexture(int)’:
LinuxRendererGLES.cpp:2692:66: error: ‘glTexDirectVIVMap’ was not declared in this scope
(GLvoid **)(&codecinfo->data[0]), &physical);
^
LinuxRendererGLES.cpp:2693:45: error: ‘glTexDirectInvalidateVIV’ was not declared in this scope
glTexDirectInvalidateVIV(m_textureTarget);
^
/xbmc/Makefile.include:95: recipe for target 'LinuxRendererGLES.o' failed

http://pastebin.com/40CipFas

Any idea ? I am using a version of this PKGBUIILD: https://github.com/CrawX/PKGBUILDs/blob/...x/PKGBUILD , with your git and .configure options.

If I try to compile a clean, without any modification (from PKGBUILD), I get this error:

checking for main in -lEGL... no
configure: error: Could not find a required library. Please see the README for your platform.

Update: export LDFLAGS="$LDFLAGS -L/opt/fsl/lib" for avoid this error: checking for main in -lEGL... no

Thank you.
Reply
(2014-02-16, 17:56)Koying Wrote:
(2014-02-16, 17:12)wolfgar Wrote: Has the switch to vivante direct texture brought the expected benefits ?
I come back to you as soon as I have been able to give it a try
Main benefit, as far as I'm concerned, is to stay inside XBMC way of working as much as possible and to not be dependent on the kernel's V4L and/or fb support.

On the pro side, I don't see performance penalty (on cubox-i quad), XBMC's 3D support is working, as is VSYNC (with FB_MULTI_BUFFER=2).
On the con side, deinterlacing is not implemented, yet, and there is a corner-case issue with top-bottom 3D if the height is not mod-16, because cropping is a bit hacky.



On an other note, this DMA issue is a bitch.
I compile on the device and ld is fragmenting it like hell Wink

Hi Koying,

My question was simply about the use of direct texture and the associated performance improvement.
But OK I have just been able to try your version and obviously your cpu load issue is gone (it seems to be very similar to the V4L version)
Have you also been able to give it a try for android ?

Apart from the deinterlacing issue you mentioned, I can't have a good VSYNC in spite of defining the environment variable
export FB_MULTI_BUFFER=2
before launching xbmc. Have you configured something else ?

Obviously you are totally right regarding the advantage of using this way of rendering : it is more aligned with xbmc way of working.
(Regarding 3D I trust you as I am perfectly unable to test this feature Wink )

I have just grabbed your version on a new branch https://github.com/wolfgar/xbmc/commits/nov4l and will at least merge my latest changes.
I will also try to "isolate" better my v4l version so that we can have a very similar DVDVideoCodecIMX.cpp file and can have the 2 versions coexist by the time it makes sense...

Also, as you are a xbmc team member, maybe you can help with upstream this imx6 port ?

At last for the DMA issue, I have lots of reports but on my side, I have really very rare issue with my main configuration (utilite pro).
A user reported that he thinks USB activity may increase the occurrence because issues became very sparse when he stopped using a USB driver to stream over network


Kind regards
Stephan
Reply
(2014-02-16, 21:06)emveepee Wrote: Where are these functions found?

LinuxRendererGLES.cpp:2692:66: error: 'glTexDirectVIVMap' was not declared in this scope
LinuxRendererGLES.cpp:2693:45: error: 'glTexDirectInvalidateVIV' was not declared in this scope

Martin

closed binaries: gpu-viv-bin-mx6q
Reply
(2014-02-16, 00:13)wolfgar Wrote: For your DMA issue I don't know : I have run my utilite all the day on SD channels (to perform endurance testing) and it is still playing perfectly after 12hours (source being SD channels)
To be clear : My current kernel has no longer the VPU wandboard patch in it (with this patch I also have issues very quickly)

Stefan,

me too without it, few days. I still can't find a "rule" with the TV slowing down. yesterday I watched olympic games for 10s, then under run buffers, skipped frames and done. Opened right again and watched for next 4h without issues.

So I really believe you you can't hit this problem.

btw: as you started discussion with integration to XBMC, could we implement resolutions & freq changes etc ?
Reply
(2014-02-17, 06:32)mk01 Wrote: closed binaries: gpu-viv-bin-mx6q

I was trying to merge these new build's with GeexBox but I can't takes koyring's repo beyond that error. Stéphan's non-44l repo does build xbmc.bin so the binaries are there. It must be a nuance of the Geexbox build process.

Martin
Reply
  •   
  • 1
  • 26
  • 27
  • 28(current)
  • 29
  • 30
  • 39
  •   



Logout Mark Read Team Forum Stats Members Help
[i.MX6] XBMC running on Freescale SoC's4
This forum uses Lukasz Tkacz MyBB addons.