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.
If my reply answers your question then please click on the "Verify Answer" button.
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
Hardik Shah
Please mark this post as answered via the Verify Answer button below if you think it answers your question. Thanks!
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
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 **************************************************************************************************-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.
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
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.
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.
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.
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?
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.
Have you had chance to try the rotating of the projection matrix yet?
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