Question is coming from TI 3rd party who is helping TI customer: 

"eglWaitGL() will block until all the rendering is complete by the SGX.  But, I think you want to synchronize the input of texture images.  That is done by IMG's Buffer Class API for texture streaming, as shown in the example.  It is designed to allow the texture images to be updated efficiently for each frame."

may not be acceptable for our solution.  What is meant by block until "all" rendering is complete?

We need to be able take a composited frame from the SGX and hand it to the DSP efficiently.  Part of this is the custom allocation of the destination buffer.  That is resolved with the new Graphics SDK.  The other part is eglWaitGL to know that the frame is ready.

** We need to know that this is the best technique available to use in SGX and that it does NOT flush the OpenGL pipeline **

If it does flush the pipeline, we believe it will introduce a delay which will drops the performance below 30 fps?

When we used glReadPixels, we observe that the performance is essentially dropped to below 20 fps.

Additionally they provide

We have a new issue with the Graphics SDK.

We are seeing frame tearing when using streaming texture input with Graphics SDK 10.

Frame tearing is a well-known video issue where the video rendering (in this case inaccessible and inside of the Graphics SDK libraries) is improperly synchronized with input streaming texture frames.  It causes intermittent "half-frames" displayed on the screen where motion from FrameN+1 is displayed on the top and FrameN is displayed on the bottom.

Can anyone provide some direction?