This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

How to resolve the vertical tearing issue at the center of screen ?

We have designed an application on TI8168 evm for our evaluation purpose. Basically we use v4l2 driver to capture
HD720P data into memory, then feed the data into sgx530 GPU for display using OpenGL ES 2.0. Of course, in order
to achieve real-time performance, we used the streaming texture method.

All these work out fine. But the main issue we noticed so far is the vertical tearing at the center of screen.
we have to get it resolve before moving on asap. We would appreciate any help we can get.

Here is what we have investigated about this issue.
 
According to the two online documents below, we have experimented the setting in powervr.ini.
Setting WindowSystem to FLIPWSEGL or LINUXFBWSEGL did NOT resolve the problem
even through it might decrease the occurring frequency of video tearing a little bit.   
 
http://processors.wiki.ti.com/index.php/SGXDbg
http://processors.wiki.ti.com/index.php/GSG:_OMAP35x_Graphics_SDK_Additional_Procedures

It seems to us that the problem is not simply an issue of using singe buffer or ping-pong buffer. We even experimented  
rendering data into pixmap surface (4 pixmap ring buffers), but the vertical tearing artifacts are still there.

Is there a way that we can get egl driver source code (OpenGL-ES driver code would be even better)?  It's very hard to
trace the issue with only binary code available.
 
Any help or input would be highly appreciated.
 

-Perry



  • Hi Perry,

    What is the version of Graphics SDK and PSP you are using? Can you provide the output of below script by running it on the EVM?

    https://gforge.ti.com/gf/download/docmanfileversion/203/3715/gfx_check.sh

    Have you taken a look at v3dfx-base & also the v3dfx component that is part of graphics SDK 04.05.00.03 ? This also uses the bufferclass driver for video streaming use cases.

    v3dfx-base-

    https://github.com/prabindh/v3dfx-base

    http://processors.wiki.ti.com/index.php/V3dfx-base

    v3dfx component that is part of the graphics SDK release -

    http://processors.wiki.ti.com/index.php/3dfxuserguide

    Thanks,

    Prathap.

     

  • Hi,

    What is the mem usage on A8. Can you please check this using "top" command on A8 and let us know. if you have very high B/W usage on A8 then you are probably hitting silicon errata "Advisory 2.0.68". This is solved in ES2.1 version of silicon. You can find errata@http://www.ti.com/lit/er/sprz329b/sprz329b.pdf

    Regards,

    Hardik shah

  • Thanks you both for your prompt reply.
    
    Hi Prathap, I have attached the result of gfx_check.sh for your reference. Please let me know if there is anything else
    
    that I can provide for the investigation. I did notice your nice work on v3dfx in graphics SDK and glad to know that you
    
    have kindly put it on github. I will defintely explore it in detail and see if I can find any clue that might help to resolve this
    
    annoying verical tearing issue.

    7028.gfx_check_result.txt
    root@dm816x-evm:~/TICode/graphics/StreamTexture# ./gfx_check.sh 
    WSEGL settings
    [default]
    #WindowSystem=libpvrPVR2D_FRONTWSEGL.so
    #WindowSystem=libpvrPVR2D_FLIPWSEGL.so
    WindowSystem=libpvrPVR2D_LINUXFBWSEGL.so
    
    ------
    ARM CPU information
    Processor       : ARMv7 Processor rev 2 (v7l)
    BogoMIPS        : 986.31
    Features        : swp half thumb fastmult vfp edsp neon vfpv3 
    CPU implementer : 0x41
    CPU architecture: 7
    CPU variant     : 0x3
    CPU part        : 0xc08
    CPU revision    : 2
    
    Hardware        : ti8168evm
    Revision        : 0000
    Serial          : 0000000000000000
    ------
    SGX driver information
    Version 1.6.16.4117 (release) /home/perry/graphics/sdk4.05/GFX_Linux_KM
    System Version String: SGX revision = 1.2.5
    ------
    Framebuffer settings
    
    mode "1920x1080-60"
        # D: 148.500 MHz, H: 67.500 kHz, V: 60.000 Hz
        geometry 1920 1080 1920 4320 32
        timings 6734 148 88 36 4 44 5
        rgba 8/16,8/8,8/0,8/24
    endmode
    
    Frame buffer device information:
        Name        : ti81xxfb
        Address     : 0x8f000000
        Size        : 33554432
        Type        : PACKED PIXELS
        Visual      : TRUECOLOR
        XPanStep    : 1
        YPanStep    : 1
        YWrapStep   : 0
        LineLength  : 7680
        Accelerator : No
    ------
    Rotation settings
    0
    ------
    Kernel Module information
    Module                  Size  Used by
    ti81xxhdmi             14478  0 
    tvp7002                 6405  1 
    ti81xxvin              20364  0 
    ti81xxvo               20143  0 
    cmemk                  20271  0 
    omaplfb                10762  0 
    bufferclass_ti          4946  0 
    ti81xxfb               24254  1 
    vpss                   72346  5 ti81xxhdmi,ti81xxvin,ti81xxvo,omaplfb,ti81xxfb
    syslink              1104515  0 
    pvrsrvkm              155298  2 omaplfb,bufferclass_ti
    ipv6                  209855  12 
    ------
    Boot settings
    console=ttyO0,115200n8 rootwait rw mem=272M earlyprintk notifyk.vpssm3_sva=0xA0000000 vram=32M root=/dev/nfs nfsroot=192.168.20.242:/home/perry/targetfs12 ip=dhcp
    ------
    Linux Kernel version
    Linux dm816x-evm 2.6.37 #1 Fri Dec 9 11:59:08 IST 2011 armv7l unknown
    
    


    Hi Hardik,  Please see attached the mem and cpu usage log of TOP. I also pasted a few lines below.  It seems to me
    
    that the system can not be considered as overloaded  with mem=35% and CPU=1%.  I also verified that the vertical tearing
    
    is not introduced in the video capture process. If I use v4l2 driver to directly display captured data, video is clean without visible 
    artifacts. It looks like the problem happens in the data path from GPU to final frame buffer.
    6622.Top_result_for_mem_cpu_usage.txt
    ---------------------------------------------------------------------------
    CPU:   0% usr   0% sys   0% nic  98% idle   0% io   0% irq   0% sirq
    Load average: 0.09 0.04 0.05 1/56 1542
      PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND
     1538  1349 root     S    84148  35%   1% ./ProgressiveVideo_OpenGLOutput 
     1537  1535 root     R     3128   1%   0% top 
       27     2 root     SW       0   0%   0% [kworker/u:1]
     1349  1347 root     S     3400   1%   0% -sh 
     1260     1 messageb S     3324   1%   0% /usr/bin/dbus-daemon --system 
     1535  1534 root     S     3128   1%   0% -sh 
     1272     1 root     S     3000   1%   0% /sbin/syslogd -n -C64 -m 20 
     1267     1 root     S     2940   1%   0% /usr/sbin/telnetd 
     1274     1 root     S     2936   1%   0% /sbin/klogd -n 
     1534  1267 root     S     2520   1%   0% login -- root
     1347     1 root     S     2516   1%   0% login -- root      
     1279     1 root     S     2292   1%   0% /usr/sbin/thttpd -d /srv/www -u root -c /cgi-bin/* 
     1348     1 root     S     1968   1%   0% /sbin/getty 38400 tty1 
       73     1 root     S <   1956   1%   0% /sbin/udevd -d 
        1     0 root     S     1708   1%   0% init [5]   
       45     2 root     SW       0   0%   0% [kworker/0:2]
        3     2 root     SW       0   0%   0% [ksoftirqd/0]
        9     2 root     SW       0   0%   0% [irq/74-serial i]
       29     2 root     SW       0   0%   0% [kworker/u:3]
       15     2 root     SW       0   0%   0% [khubd]
       44     2 root     SW       0   0%   0% [mmcqd/0]
        2     0 root     SW       0   0%   0% [kthreadd]
        7     2 root     SW       0   0%   0% [irq/72-serial i]
       25     2 root     SW       0   0%   0% [scsi_eh_0]
       36     2 root     SW       0   0%   0% [mtdblock6]
       22     2 root     SW       0   0%   0% [kswapd0]
       37     2 root     SW       0   0%   0% [mtdblock7]
       26     2 root     SW       0   0%   0% [scsi_eh_1]
     1108     2 root     SW       0   0%   0% [kjournald]
        6     2 root     SW<      0   0%   0% [khelper]
        8     2 root     SW       0   0%   0% [irq/73-serial i]
       10     2 root     SW<      0   0%   0% [mboxd]
       11     2 root     SW       0   0%   0% [sync_supers]
       12     2 root     SW       0   0%   0% [bdi-default]
       13     2 root     SW<      0   0%   0% [kblockd]
       14     2 root     SW<      0   0%   0% [omap2_mcspi]
       16     2 root     SW       0   0%   0% [kseriod]
       17     2 root     SW<      0   0%   0% [kmmcd]
       18     2 root     SW<      0   0%   0% [musb-hdrc.0]
       19     2 root     SW<      0   0%   0% [musb-hdrc.1]
       20     2 root     SW<      0   0%   0% [rpciod]
       23     2 root     SW<      0   0%   0% [aio]
       24     2 root     SW<      0   0%   0% [nfsiod]
       30     2 root     SW       0   0%   0% [mtdblock0]
       31     2 root     SW       0   0%   0% [mtdblock1]
       32     2 root     SW       0   0%   0% [mtdblock2]
       33     2 root     SW       0   0%   0% [mtdblock3]
    root@dm816x-evm:~# 
    
    
    *************************************************************************************************** CPU: 0% usr 0% sys 0% nic 98% idle 0% io 0% irq 0% sirq Load average: 0.09 0.04 0.05 1/56 1542 PID PPID USER STAT VSZ %MEM %CPU COMMAND 1538 1349 root S 84148 35% 1% ./ProgressiveVideo_OpenGLOutput 1537 1535 root R 3128 1% 0% top **************************************************************************************************

    -Perry

  • Hi Perry,

    Thanks for the update & nice words on v3dfx. I would pass this on to the team.

    Some suggestions/clarifications required -

    Are you using the graphics SDK release 04.05.00.03? From the logs you have provided, i can see it as 04.05. Want to make sure that you are using 04.05.00.03 as that is the latest on 04.05 series.

    Can you share the commandline you are using for inserting the ti81xxfb.ko module?

    Add - ti81xxfb.vram=0:24M,1:8M in your bootargs.

    Always use libpvrPVR2D_FLIPWSEGL.so in /etc/powervr.ini.

    Can you try debug build of graphics SDK?  Do you see any error on running your app? You can also define DEBUG in GFX_Linux_KM/services4/3rdparty/dc_ti81xx_linux/omaplfb.h so that we get additional debug prints from the displayclass driver. This will print the all framebuffer details, number of buffers & you can verify this.

    Do you see the tearing at other resolutions as well ie VGA, 1080p etc?

    Do you see the tearing at 16 bpp as well? You can change the resolution/bpp using fbset command.

    We have not seen any such issue with our unit test apps using bufferclass driver or v3dfx. Also we have other customers/users using bufferclass driver successfully in their apps without any such issue. Having said that, there may be problem & hence we need to root cause whether its an app problem or bufferclass driver problem. For this, as you mentioned already, it will be helpful if you can explore v3dfx in detail/use it & let us know if there is any difference in the way your app is using bufferclass driver vs the way v3dfx is using. Now that you have access to the v3dfx source,  a detailed comparison between your app & v3dfx could give some hints/pointers here.

    Thanks,

    Prathap.

     

     

     

     

     

  • Tearing is 99.9% of the time cause by using single buffering somewhere in the path.

    Can you post a short video clip of the issue?

    The issue Hardik is considering manifests more like random jumping of the entire display rather than constant effect.

    If you are using the video in as a texture than can you try displaying the texture on a rotated projection to see if the tearing appears to follow the source image or the display image?

    BR,

    Steve

  • Just to clarify a few thing first. I am in the process of working on other suggestions .

    * Yes. I installed the SDK with Graphics_SDK_setuplinux_4_05_00_03.bin.

     * This is how I installed the driver: insmod ti81xxfb.ko vram=0:32M One 1920x1080 HD frame comsumes about 8M, 4 frame buffers would need 32M. I actually did place "ti81xxfb.vram=0:32M" in my bootargs. Since I will do the same thing again when doing "insmod", So I recently removed it from bootargs. I did this to avoid change both places during my experiments. But I understand that I must put vram=32M in the bootargs to reserve memory first as you can see from my previously attached files (gfx_check_result.txt). Since we are dealing with a NULL windows system, I would guess egl layer code will use underlying fbdev to do the job. I have intentionally changed my test code to avoid using fbdev to obtain the frame buffer in fearing that it might affect egl layer's implementation. But my test shows no difference. in this case, I use cmem to allocate all input and output frame buffers. * I definitely see the same vertical tearing with 1080I data. Since the current v4l2 driver code cannot capture SD video, I don't know the result with SD. On my DM8168 evm board, only TVP7002 is currently (in the waiting mode for TI's next release) supported for component video capture, I am not aware the performance on VGA data yet. * Our taget format is RGBA 32-bit data. Basically we use GPU to do scaling and color space conversion (16-bit YUV in ==> 32bit RGB out), The tearing I observed for both 1080I and 720P is for 32-bit RGB output. I will experiment with 16-bit output also. One thing that might worth mentioning is that the tearing is still there even with scaled video images. I certainly can experiment with rotation as Steve Clynes mention.

    Thanks,

    -Perry
  • Attached a short video clip. The vertical tearing is visible around  the point of  2 sec and 5 sec.

    I shot the video using my iPod, so the quality is not so good. But it does serve the purpose of showing

    the issue. The file is playable on VLC. If you play it in loop mode, it may be more convinient to spot the artifact.

    I am sure that it operates on FLIP mode, not on Front mode.  If it's on Front mode, the tearing happens quite often.

    I also notice the LINUXFB mode behaves the same as FLIP mode.

    -Perry

    Click here to play this video

  • Thanks for the update.

    As already suggested, you can try with debug build & verify number of buffers & also see if there are any error messages getting printed.

    Also have you tried v3dfx & are you able to reproduce the issue with it. This will help to isolate any setup/environment issues, which should not be the case but just to confirm. Once you see v3dfx working fine on your setup, then comparing it with your app to understand the differences & whether its possible to reproduce the issue by modifying v3dfx to match your app would help here.

    Thanks,

    Prathap. 

  • Perry,

    This really looks like classic buffering tearing issues.

    Don't forget that there are multiple places where double/triple buffering should be used in your path.

    You also need to make sure that double buffering is used on the capture side to, not just on the display side.

    This is why rotating the projection will help. If the tearing rotates with the projection then it is a capture side issue.

    BR,

    Steve

  • As suggested, I have tried v3dfx. Unfortunately I reproduced 
    the exact same issue with v3dfx. Please see attached video clip.


    In this case, vertical tearing get much worse, it appears almost on every frame. What I did was introducing live video into v3dfx application. I simply combined TI's capture demo application (saLoopBack) with v3dfx. The code change is pretty straight forward and can be it done in a short period of time. The video source is 720P HD content and I have made it sure that I am not using OpenGL in single buffer mode (FRONTWSEGL) which is the known cause of vertical tearing as we have discussed. Thanks, -Perry
  • Reproduced the video vertical tearing issue with modified v3dfx application. 
    attach the video clip again.

    Click here to play this video
  • Hi Perry,

    Thanks for the update. Do you see issues only with live video? ie do you see issues with v3dfx standalone?

    Also can you please share your changes for reference?

    Thanks,

    Prathap.

  • Also please provide the PSP , HDVPSS software versions in use. Also it would be helpful if you can provide the exact details, steps on how we can reproduce the issue with standalone v3dfx on our setups here.

    Thanks,

    Prathap.

  • Have you had chance to try the rotating of the projection matrix yet?

    BR,

    Steve

  • Hi Prathap and Steve,

    PSP=psp04.00.01.13.patch2           HDVPSS=ti816x_hdvpss.xem3

    Detailed procedure to reproduce the vertical tearing issue with v3dfx:

    -hook up a blu-ray player to dm8168-evm component input, set blu-ray player output as 720P

    -start blu-ray player to play video

    -modify the source file tesmain.c  according to attached file

    -build v3dfx

    -boot up the dm8168 evm

    -load drivers according to attached file load_drivers_for_v3dfx.sh

    -run ./v3dfx –t  1 , you will see tearing happens on almost every frame

    Please find the missing files in your email box @ti.com

    Thanks,

     

    -Perry

  • Perry,

    I will have to defer to Prathap since I am a hardware guy, not a software guy unfortunately.

    BR,

    Steve

  • Hi Perry,

    SGX is based on the deferred rendering architecture, which means pixels from an input texture buffer can be read with a delay of up to 3 frames.

    So, a buffer being passed to texture streaming can not be released back to V4L2 driver for at least the next 3 frames.  If the buffers are being released immedaitely, then the buffer will be overwritten by V4L2 driver while SGX driver is still handling it.  If you are queing 3 buffers currently with V4L2 capture, can you queue 6 & also make sure that the buffer being passed to texture streaming driver is not released back to v4L2 for atleast the next 3 frames.

    Thanks,

    Prathap.

  • Prathap Srinivas said:
    SGX is based on the deferred rendering architecture, which means pixels from an input texture buffer can be read with a delay of up to 3 frames.

    Allow me to jump in.
    We have a product based on DM8148.  The OGL display normally works fine, but in a certain display mode, we were having a jumpy-display issue.
    Based on this tip, we implemented a logic to delay the release of buffers for 3 cycles, and the problem is now fixed!

    Thank you!

    p.s. This info should been mentioned in SGXDbg wiki page.