# eglSwapBuffers displays before rendering has finished. **URL:** \ **Category:** PowerVR Insider\ **Tags:** pvrtrace\ **Created:** [February 3, 2018, 12:45pm UTC](https://forums.imgtec.com/t/eglswapbuffers-displays-before-rendering-has-finished/2575 "2018-02-03T12:45:29Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![devmiyax](https://avatars.discourse-cdn.com/v4/letter/d/838e76/32.png) [@devmiyax](https://forums.imgtec.com/u/devmiyax)\ **Post date:** [February 3, 2018, 12:45pm UTC](https://forums.imgtec.com/t/eglswapbuffers-displays-before-rendering-has-finished/2575/1 "2018-02-03T12:45:29Z")
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? ![](http://www.uoyabause.org/system/reports/screenshots/000/003/467/original/_storage_emulated_0_yabause_screenshots_T-1246G_2018_02_03_08_29_02.png?1517664544) 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](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](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](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. ---
**Author:** ![PaulLy](https://avatars.discourse-cdn.com/v4/letter/p/958977/32.png) [@PaulLy](https://forums.imgtec.com/u/PaulLy)\ **Post date:** [February 5, 2018, 10:20am UTC](https://forums.imgtec.com/t/eglswapbuffers-displays-before-rendering-has-finished/2575/2 "2018-02-05T10:20:53Z")
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. ---
**Author:** ![CarlosSarria](https://sea1.discourse-cdn.com/flex015/user_avatar/forums.imgtec.com/carlossarria/32/263_2.png) [@CarlosSarria](https://forums.imgtec.com/u/CarlosSarria)\ **Post date:** [February 9, 2018, 9:01am UTC](https://forums.imgtec.com/t/eglswapbuffers-displays-before-rendering-has-finished/2575/3 "2018-02-09T09:01:00Z")
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. ---
**Author:** ![devmiyax](https://avatars.discourse-cdn.com/v4/letter/d/838e76/32.png) [@devmiyax](https://forums.imgtec.com/u/devmiyax)\ **Post date:** [February 9, 2018, 7:24pm UTC](https://forums.imgtec.com/t/eglswapbuffers-displays-before-rendering-has-finished/2575/4 "2018-02-09T19:24:05Z")
I’ve obtained PVRTrace data. Can you check frames from 700 to 710? [http://www.uoyabause.org/org.uoyabause.uranus\_emulationmain.pvrtrace](http://www.uoyabause.org/org.uoyabause.uranus_emulationmain.pvrtrace) ---
**Author:** ![CarlosSarria](https://sea1.discourse-cdn.com/flex015/user_avatar/forums.imgtec.com/carlossarria/32/263_2.png) [@CarlosSarria](https://forums.imgtec.com/u/CarlosSarria)\ **Post date:** [February 12, 2018, 8:21am UTC](https://forums.imgtec.com/t/eglswapbuffers-displays-before-rendering-has-finished/2575/5 "2018-02-12T08:21:12Z")
Hi Shinya, Many thanks for sending the trace. We will have a look and we’ll get back to you. Regards. Carlos. ---
**Author:** ![devmiyax](https://avatars.discourse-cdn.com/v4/letter/d/838e76/32.png) [@devmiyax](https://forums.imgtec.com/u/devmiyax)\ **Post date:** [February 22, 2018, 3:29am UTC](https://forums.imgtec.com/t/eglswapbuffers-displays-before-rendering-has-finished/2575/6 "2018-02-22T03:29:51Z")
Is there any progress? ---
**Author:** ![omarzohdi](https://avatars.discourse-cdn.com/v4/letter/o/6de8d8/32.png) [@omarzohdi](https://forums.imgtec.com/u/omarzohdi)\ **Post date:** [February 23, 2018, 3:18pm UTC](https://forums.imgtec.com/t/eglswapbuffers-displays-before-rendering-has-finished/2575/7 "2018-02-23T15:18:49Z")
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. ---
**Author:** ![Black-Seraph](https://sea1.discourse-cdn.com/flex015/user_avatar/forums.imgtec.com/black-seraph/32/276_2.png) [@Black-Seraph](https://forums.imgtec.com/u/Black-Seraph)\ **Post date:** [July 2, 2018, 4:39pm UTC](https://forums.imgtec.com/t/eglswapbuffers-displays-before-rendering-has-finished/2575/8 "2018-07-02T16:39:02Z")
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. ---
**Author:** ![omarzohdi](https://avatars.discourse-cdn.com/v4/letter/o/6de8d8/32.png) [@omarzohdi](https://forums.imgtec.com/u/omarzohdi)\ **Post date:** [July 3, 2018, 9:35am UTC](https://forums.imgtec.com/t/eglswapbuffers-displays-before-rendering-has-finished/2575/9 "2018-07-03T09:35:28Z")
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. ---
**Author:** ![Black-Seraph](https://sea1.discourse-cdn.com/flex015/user_avatar/forums.imgtec.com/black-seraph/32/276_2.png) [@Black-Seraph](https://forums.imgtec.com/u/Black-Seraph)\ **Post date:** [July 3, 2018, 9:50am UTC](https://forums.imgtec.com/t/eglswapbuffers-displays-before-rendering-has-finished/2575/10 "2018-07-03T09:50:52Z")
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. ---
**Author:** ![omarzohdi](https://avatars.discourse-cdn.com/v4/letter/o/6de8d8/32.png) [@omarzohdi](https://forums.imgtec.com/u/omarzohdi)\ **Post date:** [July 4, 2018, 10:23am UTC](https://forums.imgtec.com/t/eglswapbuffers-displays-before-rendering-has-finished/2575/11 "2018-07-04T10:23:09Z")
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. ---
**Author:** ![Black-Seraph](https://sea1.discourse-cdn.com/flex015/user_avatar/forums.imgtec.com/black-seraph/32/276_2.png) [@Black-Seraph](https://forums.imgtec.com/u/Black-Seraph)\ **Post date:** [July 18, 2018, 2:28pm UTC](https://forums.imgtec.com/t/eglswapbuffers-displays-before-rendering-has-finished/2575/12 "2018-07-18T14:28:22Z")
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? ---
**Author:** ![Black-Seraph](https://sea1.discourse-cdn.com/flex015/user_avatar/forums.imgtec.com/black-seraph/32/276_2.png) [@Black-Seraph](https://forums.imgtec.com/u/Black-Seraph)\ **Post date:** [January 22, 2019, 5:28pm UTC](https://forums.imgtec.com/t/eglswapbuffers-displays-before-rendering-has-finished/2575/13 "2019-01-22T17:28:17Z")
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. ---
**Author:** ![Olivier](https://avatars.discourse-cdn.com/v4/letter/o/d2c977/32.png) [@Olivier](https://forums.imgtec.com/u/Olivier)\ **Post date:** [April 24, 2019, 7:21pm UTC](https://forums.imgtec.com/t/eglswapbuffers-displays-before-rendering-has-finished/2575/14 "2019-04-24T19:21:16Z")
Hello all, What’s the status of this issue? ---
**Author:** ![Black-Seraph](https://sea1.discourse-cdn.com/flex015/user_avatar/forums.imgtec.com/black-seraph/32/276_2.png) [@Black-Seraph](https://forums.imgtec.com/u/Black-Seraph)\ **Post date:** [June 3, 2019, 4:02pm UTC](https://forums.imgtec.com/t/eglswapbuffers-displays-before-rendering-has-finished/2575/15 "2019-06-03T16:02:43Z")
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. ---
**Author:** ![Cwiiis](https://sea1.discourse-cdn.com/flex015/user_avatar/forums.imgtec.com/cwiiis/32/326_2.png) [@Cwiiis](https://forums.imgtec.com/u/Cwiiis)\ **Post date:** [October 8, 2019, 11:45am UTC](https://forums.imgtec.com/t/eglswapbuffers-displays-before-rendering-has-finished/2575/16 "2019-10-08T11:45:35Z")
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?