Author Topic: RGBA_8888 mode  (Read 7253 times)

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
RGBA_8888 mode
« on: April 26, 2013, 08:02:40 AM »
Is this option still necessary?  If so, shouldn't the default be enabled?

When it's disabled, we ask for a 16-bit color context, but the OpenGL spec requires egl to return the deepest color context that matches the requested config.  So in virtually any modern device we will get a 32-bit context regardless (unless the device drivers are buggy).  In other words, the same context config is used regardless of the option setting, and therefore the option has no impact on performance or visual quality.

Note that the original rice plugin always asks for 32 bits by default, and only asks for 16 if an obscure option is enabled.

It seems we could remove the option, and always request a 32 bit context.  If context creation fails, we could try again with 16 bit depth for the obscure device that only has 16 bit color (but do we really need to support such a low-performance device?).  Another approach, we could provide an advanced option to force 16-bit mode (disabled by default), in which case we'd have to manually check the EGL configurations in GameSurface.java to be sure a 16-bit config is selected (since the list will also include 32 bit configs per spec).
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: 3499
  • Developer
    • View Profile
    • PaulsCode.Com
Re: RGBA_8888 mode
« Reply #1 on: April 26, 2013, 08:32:58 AM »
This option was originally added, due to the default RGB_565 mode having ugly banding on several devices.  The SGS2, for example:

For comparsion.

mupen64plus v1.3 on SGS 2


and with RGBA8888 test


You can see it on original Hardware much more, because the jpg compression makes the banding more smooth.
You can see that's not a problen caused on the SuperAmoLED. The banding is visible on screenshoots and tv-output.
This is possible an GPU problem. So you can expect better results on much more devices.

p.s.
n64oid has the banding problem too.
p.p.s.
z-hack fixed most of gles2n64 glitches for SGS 2, but on my tegra 2 tablet it caused jagged eyes on the big mario head. - z-hack shouldn't be enabled as default.

I think we'll want to be careful about removing the option entirely, in case doing so breaks things for some devices.  I'm not sure if that is likely to happen, but a quick search of the forum brought up this quote (taken completely out of context here, but the fact that the setting had any effect even in an obscure case like this gives me pause when considering removing the setting):

I turned off RGBA_8888 Mode and I could finally get into the game!

If we can get away with defaulting to RGBA_8888 without breaking things (without at least a workaround), then it is probably a good idea to go for it.
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: RGBA_8888 mode
« Reply #2 on: April 26, 2013, 08:40:30 AM »
So the SGS2 drivers weren't following OpenGL spec because they should have returned the 32-bit (RGBA_8888) context even if 16-bit (RGB_565) was requested by default.

For the crashing, that was probably a context creation issue, i.e. the device didn't have 32-bit color.  So we can just handle that silently in the java side if the context creation fails.  No need to expose it to the user to figure out.

« Last Edit: April 26, 2013, 08:42:15 AM 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: RGBA_8888 mode
« Reply #3 on: April 26, 2013, 08:45:51 AM »
On a side note, I wonder if the US SGS3 is returning a software-emulated rendering context, and that's what's causing the lagginess.  Have we ruled that out yet?  I may add some extra logging to verify.
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: RGBA_8888 mode
« Reply #4 on: April 26, 2013, 09:35:45 AM »
I read about the color spec stuff the Nvidia Tegra GLES2 developer guide:

Quote
EGL Configurations
Searching the Returned List
EGLís method of sorting configurations returned from queries is often counter-intuitive. Applications using eglChooseConfig must not simply select the first returned configuration, nor should they request only one configuration. An example of a common and confusing case is requesting a 565 RGB configuration. Owing to section 3.4 of the EGL spec, eglChooseConfig must return the deepest color buffer first, even if it is deeper than the requested format, and even if the requested format could have been matched exactly. In other words, an implementation that supports 565 and 8888 must return 8888 earlier in the list than 565, even if 565 is requested. The EGL spec notes the following in a footnote to 3.4:
Quote
This rule places configs with deeper color buffers first in the list returned by eglChooseConfig. Applications may find this counterintuitive, and need to perform additional processing on the list of configs to find one best matching their requirements. For example, specifying RGBA depths of 5651 could return a list whose first config has a depth of 8888.

Applications should always request an array of multiple configurations, and should query important attributes such as red, green and blue depths of each, performing their own manual sorting and filtering of the resulting array. EGLís behavior is defined by the spec; Tegraís driver cannot deviate from the proscribed order.

32-bit versus 24-bit
Tegra does not support rendering to 24-bit "888" buffers. Applications wishing to use such formats should request a RGBA8888 format to ensure that the OS does not return a SW-emulated configuration. Requesting 24-bit RGB888 with OpenGL ES1.x on Android can lead to a SW-rendered configuration and decreased performance and available features.

All sorts of stuff seems relevant here.  We always use the first config in the returned list (not recommended) and we don't necessarily get what we ask for.  The SW-emulated configuration also stands out as a possible cause of lagginess on some devices.
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: 3499
  • Developer
    • View Profile
    • PaulsCode.Com
Re: RGBA_8888 mode
« Reply #5 on: April 26, 2013, 09:47:33 AM »
On a side note, I wonder if the US SGS3 is returning a software-emulated rendering context, and that's what's causing the lagginess.  Have we ruled that out yet?  I may add some extra logging to verify.

I haven't checked that, actually.  What property of the context would we check for that?
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: RGBA_8888 mode
« Reply #6 on: April 26, 2013, 09:50:49 AM »
Was going to check on that next chance I get.
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: RGBA_8888 mode
« Reply #7 on: April 26, 2013, 10:56:31 AM »
Just posted a test branch for the SGS3.  16-bit depth buffer might be software-emulated on SGS3.  Inspired by the last paragraph of this page.

Would you mind posting a build for testers when you get a chance?
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: 3499
  • Developer
    • View Profile
    • PaulsCode.Com
Re: RGBA_8888 mode
« Reply #8 on: April 26, 2013, 11:14:09 AM »
Thanks, I'll have it up shortly.
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 Paul

  • Administrator
  • double
  • *****
  • Posts: 3499
  • Developer
    • View Profile
    • PaulsCode.Com
Re: RGBA_8888 mode
« Reply #9 on: April 26, 2013, 11:59:22 AM »
I just blasted out emails to folks with GS3, HTC One, and Xperia Z who have reported the lag problems.  Hopefully we'll get a response on this soon.  Even if it doesn't fix the problem, it would be good to look at some logcats to see what profiles are being matched and which is getting picked on these phones.
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: RGBA_8888 mode
« Reply #10 on: April 26, 2013, 12:00:16 PM »
Awesome, thanks.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version