Author Topic: HTC one FPS  (Read 31164 times)

Offline mikethebigo

  • byte
  • *
  • Posts: 16
    • View Profile
Re: HTC one FPS
« Reply #75 on: May 20, 2013, 11:17:47 PM »
Holy cow, when I get home I can try all the tests but I just tried test number 4 and it worked beautifully!  I didn't have to change my CPU or GPU to performance mode, and it handled everything no sweat, even Zelda which seems to give it a lot of problems.

Offline Paul

  • Administrator
  • double
  • *****
  • Posts: 3495
  • Developer
    • View Profile
    • PaulsCode.Com
Re: HTC one FPS
« Reply #76 on: May 20, 2013, 11:34:22 PM »
I had it set to never skip frames. if that's what you're saying about the race-condition.

I meant two threads racing to use the same resource at the same time.  Where I could see this possibly happening is between the call to eglWaitNative and the call to eglWaitGL.  The way I understand these two methods is the first one waits for the native gl calls to finish, and the second one prevents more gl calls until eglSwapBuffers finishes.  In a multi-threaded environment I could see a scenario where eglWaitNative finishes, and the native thread manages to get in another gl call or two before eglWaitGL is called from the first thread.

Anyway, I'm totally making all this up since I have no idea how the code for these methods actually works behind the scenes  ;D
Device: Samsung Galaxy Nexus i515
CPU: TI OMAP4460, 1.2 GHz (dual core, ARM Cortex-A9)
GPU: PowerVR SGX540, 307 MHz
RAM: 1 GB
Resolution: 720 x 1280
Rom: omni-4.4.4-20141014-toro-FML KitKat 4.4.4, rooted

Device: Eee PC 1015PEM
CPU: Intel Atom N550, 1.5 GHz (dual core, x86)
GPU: Intel GMA 3150, 200 MHz (dual core)
RAM: 2GB
Resolution: 1024 x 600
Rom: android-x86-4.3-20130725 Jelly Bean 4.3, rooted

Offline scorpio16v

  • long
  • ***
  • Posts: 203
    • View Profile
Re: HTC one FPS
« Reply #77 on: May 20, 2013, 11:35:03 PM »
Can confirm, the no-wait-test fixed the lag on Nexus 4 completely. I've used my same test configuration from my last test run and both devices are running in sync.  :)

Offline Grantious

  • bit
  • Posts: 8
    • View Profile
Re: HTC one FPS
« Reply #78 on: May 21, 2013, 01:10:44 AM »
HTC one (no wait) huge speed increase!

Offline mikethebigo

  • byte
  • *
  • Posts: 16
    • View Profile
Re: HTC one FPS
« Reply #79 on: May 21, 2013, 01:46:24 AM »
Of all of the tests, test #4 is definitely the one that basically fixed the problem.  Enjoying good frame rates on pretty much every game now.  Of note, when I use test 4 and also set my CPU/GPU to performance I do get a 5-10 FPS boost in some games but it is really smooth either way.

Now I just need to get my Moga Pro fully compatible with the app and I'll really be on the way to 64 bit greatness!

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: HTC one FPS
« Reply #80 on: May 21, 2013, 08:37:34 AM »
Wow, nothing like waking up to a boatload of great news!!  So glad we finally got this nailed down, and thanks everyone for all the testing effort.  ;D ;D ;D
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: HTC one FPS
« Reply #81 on: May 21, 2013, 09:21:21 AM »
Sounds like it was waiting for something other than the video plug-in's gl calls (maybe in the Android UI?)  Unless there was some type of race-condition going on, where it ended up waiting for 2 or 3 frames to go by before it could update.

EGL provides a cross-platform abstraction for the GL state machine to bind to.  It's mainly for coordinating GL rendering activities with the native windowing/GUI/compositing operations of the platform.  For example, Windows operating systems need to coordinate the drawing of the 2D window frame and widgets with the GL rendering activities inside that frame.  There are mixed mode operations going on, e.g. GDI and OpenGL, and EGL coordinates those operations.

What's a bit confusing in our case is the term 'native' in eglWaitNative.  It doesn't mean the 'native' as in C++ vs. Java, but rather means 'native' as in the Android native drawing and compositing operations vs. GL based draw operations.  The eglWait* functions are probably for apps where a lot of mixed-mode rendering occurs and must be coordinated, e.g. where one thread is drawing the GL stuff and another is updating the decor, overlays, etc. drawn using a different API.  I think they are used in the SDL Android example code to guarantee compositing safety at the possible expense of performance.  I.e. they erred on the side of caution, but I don't think the use is necessarily prescriptive.

In our case, that "other stuff" is indeed the Android OS, refreshing the Action/Menu bar, Navigation bar, context menus, and GameOverlay, all of which occurs on a different thread.  But in our case, there's no need for them to be in perfect frame sync as long as the GL surface never overdraws the "other stuff".  That's a big assumption (see next paragraph) but for the sake of discussion assume that it holds.  My guess is that the new Adreno chipsets have some additional optimizations that make it more lazy in refreshing the "other stuff".  When Garrett enabled the "Show touches" option in the Android settings, that forced the chipset to refresh the "other stuff" at a higher rate and hence allowed the app to run at a higher FPS.

I'm not sure about earlier Android versions, but at least for the JellyBean devices tested here, the Android layout manager (via the 'merge' object) seems to be smart enough to keep the two layers separate and not allow GL to overdraw the "other stuff" even if they're updated at different rates.  I'm not sure if all Android versions and chipsets have these smarts, though.  The main regression I could imagine this introducing would be flickering of the GameOverlay, Action Bar, and in-game context menus.  I think that's the main risk we should keep an eye out for.

Edit: One other piece of info: eglWaitGL is functionally the same as calling glFinish, which the official Khronos docs say
Quote
glFinish is NOT required before a call to eglSwapBuffers or glReadPixels.   glFinish can take some time and for performance reasons it is best to use this function infrequently and only when necessary.
« Last Edit: May 21, 2013, 12:02:34 PM by littleguy »
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: HTC one FPS
« Reply #82 on: May 21, 2013, 09:31:03 AM »
If we do find the flicker regression on some devices, the easy solution would be to add a user preference (disabled by default) and call the eglWait* functions only if it's enabled.  We could add it to the video settings and call it "Eliminate menu/button flicker" with the description text saying "May degrade game speed" or something.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: HTC one FPS
« Reply #83 on: May 21, 2013, 11:43:50 AM »
Now I just need to get my Moga Pro fully compatible with the app and I'll really be on the way to 64 bit greatness!

Please start a new thread on the issue and we'll be happy to work with you on it.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline jnewbern

  • bit
  • Posts: 4
    • View Profile
Re: HTC one FPS
« Reply #84 on: September 24, 2013, 08:57:24 PM »
Hi all,

I have a HTC one and am having issues with lag on Zelda OOT using the version of mupen on the google play store. I found this thread and tried the no wait test #4 version of mupen and it worked great. No lag. But unfortunately the no wait version in this thread does not have native support for my moga pocket controller. With the no wait test version I can use the universal moga driver but that does not support the analog sticks. It treats them as just touch pads. Is there a version that has the htc one fix and supports the moga analog sticks? Thanks for all your help devs I appreciate all your hard work.

big fan.

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: HTC one FPS
« Reply #85 on: September 24, 2013, 09:23:33 PM »
The unofficial MOGA universal driver definitely gives analog control, but only if you're rooted.  Otherwise I think they just act like a d-pad.  See this thread for more info:
http://www.paulscode.com/forum/index.php?topic=877.0

The version available in the Play store does contain all the fixes described in this thread.  These fixes have been there since version 2.3.0 (see the changelog in the About menu).

Just to be clear, "lag" is not the same thing as low FPS.  You should be getting high framerates (30 FPS or more) with the HTC One.  If your audio lags behind the video and input, that's a different problem altogether.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline Paul

  • Administrator
  • double
  • *****
  • Posts: 3495
  • Developer
    • View Profile
    • PaulsCode.Com
Re: HTC one FPS
« Reply #86 on: September 24, 2013, 09:26:26 PM »
The bugfix should already be built into the app on the play store.  Are you using Mupen64Plus AE (and not one of the ripoffs like Super N64)?  Take a look at the version number (press "About" from the main menu), and let me know what it says.  I suppose this could be a regression.  Can anyone else with one of the problem devices confirm that the extreme lag is back in the latest version?

--EDIT-- Littleguy beat me to the answer :)
Device: Samsung Galaxy Nexus i515
CPU: TI OMAP4460, 1.2 GHz (dual core, ARM Cortex-A9)
GPU: PowerVR SGX540, 307 MHz
RAM: 1 GB
Resolution: 720 x 1280
Rom: omni-4.4.4-20141014-toro-FML KitKat 4.4.4, rooted

Device: Eee PC 1015PEM
CPU: Intel Atom N550, 1.5 GHz (dual core, x86)
GPU: Intel GMA 3150, 200 MHz (dual core)
RAM: 2GB
Resolution: 1024 x 600
Rom: android-x86-4.3-20130725 Jelly Bean 4.3, rooted

Offline jnewbern

  • bit
  • Posts: 4
    • View Profile
Re: HTC one FPS
« Reply #87 on: September 24, 2013, 09:41:27 PM »
So I did a little more investigating. The version of mupen64 i am using from the play store is 2.3.4. And I see from the changelog that it incorporated the htc one fix a few versions ago. But I still do notice a different between the no wait version from this thread (2.2.1). I am using the gles2n64 plugin with default settings. In 2.3.4 When i run around kokiri village in the beginning of the game I get 19-21 fps and occasionally it drops down to 15 fps with noticable visual lag and audio breaks. When i use the no wait version 2.2.1 my fps is 19-21 and never dips down when i run around. Honestly 19-21 seems a bit low in general but the game seems to run just fine to me except for when it dips down to 15. So obviously i dont know what is causing the issue. Any help would be appreciated.

Also I noticed that links boots seem to be sunk into the ground a bit when running over the main paths through the village.

FYI my htc one is not rooted and running stock android. Thanks

Offline Paul

  • Administrator
  • double
  • *****
  • Posts: 3495
  • Developer
    • View Profile
    • PaulsCode.Com
Re: HTC one FPS
« Reply #88 on: September 24, 2013, 09:44:52 PM »
There have been quite a few changes since 2.2.1, so it is possible one of them resulted in a speed regression on the HTC One.  If you have the time, it would be helpful if you could go back through older versions (posted in the Beta Testing Has Begun thread in the Announcements/ General Discussion board), and find which version the speed difference first appeared.
Device: Samsung Galaxy Nexus i515
CPU: TI OMAP4460, 1.2 GHz (dual core, ARM Cortex-A9)
GPU: PowerVR SGX540, 307 MHz
RAM: 1 GB
Resolution: 720 x 1280
Rom: omni-4.4.4-20141014-toro-FML KitKat 4.4.4, rooted

Device: Eee PC 1015PEM
CPU: Intel Atom N550, 1.5 GHz (dual core, x86)
GPU: Intel GMA 3150, 200 MHz (dual core)
RAM: 2GB
Resolution: 1024 x 600
Rom: android-x86-4.3-20130725 Jelly Bean 4.3, rooted

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: HTC one FPS
« Reply #89 on: September 24, 2013, 09:48:12 PM »
Ok, thanks for the quick update.  The difference in FPS you describe is relatively subtle compared to the original posts of this thread... those users were having dramatic reductions in FPS (like 5 FPS when they should have 30 FPS).  It is possible that the latest version has a new bug (regression) that's causing some hiccups for you.

IIRC I get about 15 FPS on my Tegra3 in the Kokiri village.  That's actually a very graphically demanding section of the game.

Edit: Now Paul beat me to the punch :)
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version