How to solve tearing problem without great perform punishment？

Are the kernel modules reloaded after the change in powervr.ini ? With a resolution of 1024*768 16bpp, memory needed for 3 flip buffers should be around 5 MB, but only 4 MB is allocated in bootargs for fb0.

- In addition, consider moving to a later version of the Graphics SDK in OE- refer below:

http://patches.openembedded.org/patch/15187/

I have changed vram size to 12M for fb0,and use flip drive it never tear again,but I was confused why it need 3 flip buffer? like MS Windows's ddraw or SDL it only need 2 buffer in flip mode ,one for render as backbuffer, and one for dac as frontbuffer. Does it create one frontbuffer and 2 backbuffer by default at FLIP mode?

Good to know that there is no tearing now. Yes.

Prabindh, you seem to know what's going on with the OMAP GFX setup.  I have a similar issue to what was discussed above.

We're using a Beagleboard xM/OMAP3530.  With /etc/powervr.ini set to

WindowSystem=libpvrPVR2D_FLIPWSEGL.so

And /media/mmcblk0p1/uEnv.txt set to

dvimode=1024x768-16@60

We get the expected resolution.  When we edit powervr.ini to

WindowSystem=libpvrPVR2D_BLITWSEGL.so

we get a small improvement in tearing, but we're still obviously not using double-buffering.  When we change powervr.ini to

WindowSystem=libpvrPVR2D_FLIPWSEGL.so

we error out of EGL initialization, apparently because we have insufficient space for the required framebuffers.

dvimode=1024x768-16@60 vram=12M

doesn't help EGL initialization.  With

vram=12M dvimode=1024x768-16@60

I seem to default back to 640x480.  Similarly when I try some of your suggestion

vram=12M omapfb.vram=0:4M,1:4M,2:4M omapfb.mode=dvi:1024x768-16@60

we also default back to 640x480.  I'm guessing the startup is ignoring the directive when it receives unexpected syntax.  In fact, the syntax I copied may not even be intended for uEnv.txt.  I know the board initialization has been somewhat fluid, with different mechanisms in place at various times.  We're using library version 1.6.16.3977.  Are you familiar with the Beagleboard enviroment? If so can you specify what we could be doing to get the double buffering to work?

Note that in http://processors.wiki.ti.com/index.php/SGXDbg#Release_mode_operation, section 4.1 the documentation states

libpvrPVR2D_FRONTWSEGL.so (for direct writes to FrameBuffer - FRONT mode of operation - directly writes to FrameBuffer without waiting for vsync - fastest mode of operation)

libpvrPVR2D_FLIPWSEGL.so (for VSync synchronised writes to Framebuffer - slower, but avoids tearing)

libpvrPVR2D_BLITWSEGL.so (for direct writes to back-buffer, which later gets written to FrameBuffer with sync)

I assume that the descriptions of FLIP and BLIT are reversed unintenionally?  We assume that to get double-buffering we want the FLIP library.  Also, do you know if there are limitations on the memory block size allocated to VRAM?  Could we allocate just 5Mb, which would be sufficient for three buffers of 1024x768?

Thanks in advance for your attention.

Hi,

You can set the bootargs as mentioned below -

http://processors.wiki.ti.com/index.php/Graphics_SDK_Quick_installation_and_user_guide#Step_1_:_Bootargs_setup.2Fverification

It should work. If not, then please check if your u-boot version supports that. You can check your u-boot code to have the below update -

http://lists.denx.de/pipermail/u-boot/2009-September/061564.html

If not, please consider updating your u-boot to latest version & try. Also let us know the kernel version you are using.

Also buffer size requirements is calculated as - display resolution * bpp. For eg for display resolution of 1024x768, a single buffer requirement would be 1024x768x2 (for 16 bpp) = 1.5 MB. 3MB for 32 bpp.

The definition of FLIP provided is right. It uses multiple buffers & hence the vsync mechanism for synchronised writes to framebuffer.

Thanks,

Prathap.

Prathap, you gave me the secret incantation.  On the Beagleboard, I had to change the uEnv.txt frile from:

dvimode=1024x768-16@60

to:

dvimode=1024x768-16@60 vram=8M omapfb.vram-0:8M

With the FLIP library, I'm now as fast as the FRONT library, and tearing of moving leading/trailing as well as left-right half offset problems are gone.

The BLIT library had improved the animation artifacts a little, but ran25% slower.

I hope this is useful to other Beagleboard users.

Hi, I met other 2 kind of tearing:

  I decode video to a opengl texture (using glTexSubImage2D),and render it on screen, the output position across screen center. and then tearing happen, other things on screen didn't tear, just the video region。 It seems left half screen render with texture before updated, right half with texture after update. 

(draw background > decode video to buffer > update buffer to texture > draw texture on screen > draw other thing  >Swap render target) loop, only the video tear.

the second kind of tearing is, at most time it doesn't tear, but will happen at sometimes and last for 10+ second, at column y=512, and also at row x=512, looks like something cpu heavy prevent the driver from vsync. 

glTexImage2D is not the recommended way to draw textures. For the right way, check the below.

http://processors.wiki.ti.com/index.php/GPU_Compositing

For reporting issues, check below for the information required:

http://processors.wiki.ti.com/index.php/SGXDbg#Baselining_the_current_SGX_driver_environment