eglSwapBuffers displays before rendering has finished.

PowerVR Insider
1

I’m developing a app on GPD XD plus which has PowerVR GX6250 using Android NDK.
The displayed images after eglSwapBuffers are called seem the images which didn’t finish the rendering.
Do you have any suggestions?

My App has view extended from SurfaceView.
https://github.com/devmiyax/yabause/blob/master/yabause/src/android/app/src/main/java/org/uoyabause/android/YabauseView.java

After surfaceChanged, initialize EGL
https://github.com/devmiyax/yabause/blob/master/yabause/src/android/jni/yui.c#L858

Every time drawing has done, call eglSwapBuffers.
https://github.com/devmiyax/yabause/blob/master/yabause/src/android/jni/yui.c#L372

Other devices( NVidia X1 K1, Qualcomm adreno) works fine with my code.

2

Hi Shinya,

Could you record a trace using the PVRTrace tool from our SDK? The Trace may give us some clues as to what exactly is happening here.

Thanks,
PaulL.

3

Hi Shinya,

I have to reckon that we haven’t seen this problem before. This is just a guess, but I would say that it is caused by the multi-threading synchronization and the eglMakeCurrent calls. The surface might be changed mid-rendering.
Does the same problem happen if you disable asynchronous rendering?And if you add an “artificial” slow down?
We haven’t tried yet to build your application. Do you have a prebuilt APK we can have a look at?

Best regards.

Carlos.

4

I’ve obtained PVRTrace data. Can you check frames from 700 to 710?

http://www.uoyabause.org/org.uoyabause.uranus_emulationmain.pvrtrace

5

Hi Shinya,

Many thanks for sending the trace. We will have a look and we’ll get back to you.

Regards.

Carlos.

6

Is there any progress?

7

Hi Shinya,

Apologies for the late reply.

We’ve been analyzing your trace file. We were able to recreate the issue. It appears it is a bug in our drivers. The issue stems from the way the driver interprets the access flags when mapping the buffer.

A temporary work around can be implemented by going to the file ygles.c on line 518 when calling glMapBufferRange, add the GL_MAP_UNSYNCHRONIZED_BIT to the access flags.

I’ll pass the issue to the driver team and hopefully we’ll have a permanent fix implemented as soon as possible.

Thank you,
Omar.

8

It’s been over 4 months… has any progress been made?
If so, would the driver team please be nice enough to provide updated driver blobs to me?
I’m the community-elected person in charge of maintaining said device’s Android ROM.

9

Hi,

The bug has been fixed and is available in our 1.10 drivers. Unfortunately we do not release drivers for retail devices as the drivers are specific to the platform and can only be released by the OEM. You’d have to contact the OEM of the device and request the new driver.

Thank you,
Omar.

10

When was the driver released and what MTK SDK version contains it?

If I want to make such an request I first have to go through the device manufacturer’s representative, which in turn needs to go through Mediatek’s representative to get their hands on said files.

This is a lengthy process and I’d prefer to have the required information beforehand as to avoid confusion (which is bound to happen due to the language barrier between us community maintainers (english) and the OEMs (chinese)…).

Being awfully blunt here, I’d prefer to just be handed the handful of blobs I need and be on my merry way, I know my way around Android and can build what I need if I have that, but if that isn’t an option then I at least want all the information I need to request said files beforehand.

11

Hi,

Unfortunately we cannot provide the drivers as they need to be modified by MTK to run on their specific platform. You’d have to get them from MTK if you want to ensure that they work.

The date of release and the MTK SDK version containing the driver is not information we can provide as it’s up to MTK to modify and distribute the drivers. You’d have to ask them to provide you with that information.

Thank you,
Omar.

12

I’ve been given partial access to the latest SDK MTK has made and find that it still comes bundled with driver version 1.7, leaving me to fight for myself once again.

Is there no way these new drivers could be made available so I could adapt them to our kernel and OS source?

13

The latest MTK SDK shipped for our device now comes with the 1.9 drivers… which, again, does not ship the fix you guys supposedly implemented in 1.10.

Can we skip the whole run-around thing once and for all and just have the drivers please so we can adapt them ourselves? Waiting on MTK to actually get this thing shipped is a lost cause.

14

Hello all,
What’s the status of this issue?

15

I doubt we’ll be seeing actual help from them other than telling us to ask MTK, which again, won’t ever help as MTK doesn’t give a damn either.

16

It’s very unlikely that we’re going to receive an updated driver at this point, so it’d be good to get as much information about this bug as possible. Could you be more specific about the exact error?

I’m trying to work around it, but your advice about just adding GL_MAP_UNSYNCHRONIZED_BIT both doesn’t work with the current code-base and also doesn’t make sense to me - surely if this is a synchronization issue, that would just make it more likely to occur everywhere instead of just on this device? What exactly is wrong with the implementation of glMapBufferRange that causes this issue?