Test SwiftShader on Android-x86

[Chih-Wei Huang]

Hi,
I made a quick test of SwiftShader on Android-x86
by replacing it with our current GLES libs (Mesa).
It works like a charm! Except the red and blue colors
are swapped. How could it be possible?
Do I need any patch in the frameworks or gralloc side
to fix it? Or do I need to set some configs?

Another question. Any plan to support GLES 3.0 or above?

The SwiftShader I tested is android-emulator-current-release
and the Android version is 7.1.2. (NZH54B).
The device is QEMU 2.9.0 with bochsdrmfb.

The log SurfaceFlinger started:

07-19 12:08:50.432  1078  1078 D libEGL  : loaded /vendor/lib64/egl/libGLESv1_CM_swiftshader.so
07-19 12:08:50.436  1078  1078 D libEGL  : loaded /vendor/lib64/egl/libGLESv2_swiftshader.so
07-19 12:08:50.461  1078  1078 W gralloc : FBIOPUT_VSCREENINFO failed, page flipping not supported
07-19 12:08:50.461  1078  1078 W gralloc : page flipping not supported (yres_virtual=768, requested=1536)
07-19 12:08:50.461  1078  1078 I gralloc : using (fd=11)
07-19 12:08:50.461  1078  1078 I gralloc : id           = bochsdrmfb
07-19 12:08:50.461  1078  1078 I gralloc : xres         = 1024 px
07-19 12:08:50.461  1078  1078 I gralloc : yres         = 768 px
07-19 12:08:50.461  1078  1078 I gralloc : xres_virtual = 1024 px
07-19 12:08:50.461  1078  1078 I gralloc : yres_virtual = 768 px
07-19 12:08:50.461  1078  1078 I gralloc : bpp          = 32
07-19 12:08:50.461  1078  1078 I gralloc : r            = 16:8
07-19 12:08:50.461  1078  1078 I gralloc : g            =  8:8
07-19 12:08:50.461  1078  1078 I gralloc : b            =  0:8
07-19 12:08:50.461  1078  1078 I gralloc : width        = 163 mm (159.568100 dpi)
07-19 12:08:50.461  1078  1078 I gralloc : height       = 122 mm (159.895081 dpi)
07-19 12:08:50.461  1078  1078 I gralloc : refresh rate = 60.00 Hz
07-19 12:08:50.462  1078  1078 E SurfaceFlinger: hwcomposer module not found
07-19 12:08:50.462  1078  1078 I SurfaceFlinger: EGL information: format=0x1
07-19 12:08:50.462  1078  1078 I SurfaceFlinger: vendor    : Android
07-19 12:08:50.462  1078  1078 I SurfaceFlinger: version   : 1.4 Android META-EGL
07-19 12:08:50.462  1078  1078 I SurfaceFlinger: extensions: EGL_KHR_get_all_proc_addresses EGL_ANDROID_presentation_time EGL_KHR_swap_buffers_with_damage EGL_ANDROID_create_native_client_buffer EGL_ANDROID_front_buffer_auto_refresh EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_fence_sync EGL_KHR_create_context EGL_ANDROID_recordable
07-19 12:08:50.462  1078  1078 I SurfaceFlinger: Client API: OpenGL_ES
07-19 12:08:50.462  1078  1078 I SurfaceFlinger: EGLSurface: 8-8-8-0, config=0x11
07-19 12:08:50.480  1078  1078 I surfaceflinger: type=1400 audit(0.0:79): avc: denied { read write } for name="tty0" dev="tmpfs" ino=4207 scontext=u:r:surfaceflinger:s0 tcontext=u:object_r:tty_device:s0 tclass=chr_file permissive=1
07-19 12:08:50.480  1078  1078 I surfaceflinger: type=1400 audit(0.0:80): avc: denied { open } for path="/dev/tty0" dev="tmpfs" ino=4207 scontext=u:r:surfaceflinger:s0 tcontext=u:object_r:tty_device:s0 tclass=chr_file permissive=1
07-19 12:08:50.480  1078  1078 I surfaceflinger: type=1400 audit(0.0:81): avc: denied { ioctl } for path="/dev/tty0" dev="tmpfs" ino=4207 ioctlcmd=0x4b3a scontext=u:r:surfaceflinger:s0 tcontext=u:object_r:tty_device:s0 tclass=chr_file permissive=1
07-19 12:08:50.480  1078  1078 I surfaceflinger: type=1400 audit(0.0:82): avc: denied { sys_tty_config } for capability=26 scontext=u:r:surfaceflinger:s0 tcontext=u:r:surfaceflinger:s0 tclass=capability permissive=1
07-19 12:08:50.481  1078  1078 I SurfaceFlinger: OpenGL ES informations: format=0x1
07-19 12:08:50.481  1078  1078 I SurfaceFlinger: vendor    : Google Inc.
07-19 12:08:50.481  1078  1078 I SurfaceFlinger: renderer  : Google SwiftShader
07-19 12:08:50.481  1078  1078 I SurfaceFlinger: version   : OpenGL ES 2.0 SwiftShader 3.3.0.2
07-19 12:08:50.481  1078  1078 I SurfaceFlinger: extensions: GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_depth32 GL_OES_depth_texture GL_OES_depth_texture_cube_map GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_element_index_uint GL_OES_framebuffer_object GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_texture_3D GL_EXT_blend_minmax GL_EXT_color_buffer_half_float GL_EXT_draw_buffers GL_EXT_instanced_arrays GL_EXT_occlusion_query_boolean GL_EXT_read_format_bgra GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888 GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_instanced_arrays GL_NV_fence GL_NV_framebuffer_blit GL_NV_read_depth

[Nicolas Capens]

Hi Chih-Wei,

SwiftShader tries to get information on the pixel format from the fb0 device's VSCREENINFO (see src/OpenGL/libEGL/Display.cpp), but if unsuccessful it assumes an X8B8G8R8 format (red in the least significant byte). The logcat output is very useful; it tells us that "FBIOPUT_VSCREENINFO failed", and also that "r = 16:8" meaning it's putting the red component in the third byte (and blue in the first). Hence we're seeing everything swapped. :-)

I'm not sure why the FBIOPUT_VSCREENINFO would fail. Perhaps it's not supported by bochsdrmfb?

Regarding your other question; yes, OpenGL ES 3.0 support is under development. It's already available for "experimental" use when setting EGL_CONFIG_CAVEAT to EGL_DONT_CARE when choosing an EGL config (to allow for non-conformant configs).

Cheers,

Nicolas

--
You received this message because you are subscribed to the Google Groups "swiftshader" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swiftshader+unsubscribe@googlegroups.com.
To post to this group, send email to swift...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/swiftshader/9293b943-e491-44e8-9035-e689ff456612%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chih-Wei Huang]

Nicolas Capens於 2017年7月19日星期三 UTC+8下午10時53分54秒寫道：

Hi Chih-Wei,

SwiftShader tries to get information on the pixel format from the fb0 device's VSCREENINFO (see src/OpenGL/libEGL/Display.cpp), but if unsuccessful it assumes an X8B8G8R8 format (red in the least significant byte). The logcat output is very useful; it tells us that "FBIOPUT_VSCREENINFO failed", and also that "r = 16:8" meaning it's putting the red component in the third byte (and blue in the first). Hence we're seeing everything swapped. :-)

I'm not sure why the FBIOPUT_VSCREENINFO would fail. Perhaps it's not supported by bochsdrmfb?

Thank you for the quick response and nice explanation.

So instead of bochsdrmfb, I tried the UVESAFB driver now.
Then "FBIOPUT_VSCREENINFO failed" disappears.
However, the colors are still swapped.
What could be the problem now?

Is there a way to force the pixel format?

07-19 16:06:54.154  1084  1084 D libEGL  : loaded /vendor/lib64/egl/libEGL_swiftshader.so
07-19 16:06:54.269  1084  1084 D libEGL  : loaded /vendor/lib64/egl/libGLESv1_CM_swiftshader.so
07-19 16:06:54.271  1084  1084 D libEGL  : loaded /vendor/lib64/egl/libGLESv2_swiftshader.so
07-19 16:06:54.282  1084  1084 W gralloc : page flipping not supported (yres_virtual=768, requested=1536)
07-19 16:06:54.282  1084  1084 I gralloc : using (fd=11)
07-19 16:06:54.282  1084  1084 I gralloc : id           = VESA VGA
07-19 16:06:54.282  1084  1084 I gralloc : xres         = 1024 px
07-19 16:06:54.282  1084  1084 I gralloc : yres         = 768 px
07-19 16:06:54.282  1084  1084 I gralloc : xres_virtual = 1024 px
07-19 16:06:54.282  1084  1084 I gralloc : yres_virtual = 768 px
07-19 16:06:54.282  1084  1084 I gralloc : bpp          = 32
07-19 16:06:54.282  1084  1084 I gralloc : r            = 16:8
07-19 16:06:54.282  1084  1084 I gralloc : g            =  8:8
07-19 16:06:54.282  1084  1084 I gralloc : b            =  0:8
07-19 16:06:54.282  1084  1084 I gralloc : width        = 163 mm (159.568100 dpi)
07-19 16:06:54.282  1084  1084 I gralloc : height       = 122 mm (159.895081 dpi)
07-19 16:06:54.282  1084  1084 I gralloc : refresh rate = 91.71 Hz

 

[Nicolas Capens]

Could you try replacing the X8B8G8R8 at this line with X8R8G8B8?

Let me know if that fixes it and then we can try to find the root cause. Thanks!

--
You received this message because you are subscribed to the Google Groups "swiftshader" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swiftshader+unsubscribe@googlegroups.com.
To post to this group, send email to swift...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/swiftshader/9631c4de-fd56-47e9-b03c-92a5d5f918ae%40googlegroups.com.

[Chih-Wei Huang]

Nicolas Capens於 2017年7月20日星期四 UTC+8上午12時55分43秒寫道：

Could you try replacing the X8B8G8R8 at this line with X8R8G8B8?

Let me know if that fixes it and then we can try to find the root cause. Thanks

Thanks for the suggestion.
I tested but no effect.

So I added mode debug messages.
Then I found the ioctl FBIOGET_VSCREENINFO is OK
(note in my previous logcat the failed ioctl is
FBIOPUT_VSCREENINFO instead of FBIOGET_VSCREENINFO)
so it get the fb info correct. info.transp.length is 0
so it chose sw::FORMAT_X8R8G8B8.
Isn't it correct?
Then I tried sw::FORMAT_X8B8G8R8.
But the colors are still swapped.
I lost.

Reading the code,
Am I correct that it just returns if a known format
is found without closing the fd?
(in Display::getDisplayFormat())
It's a fd leak. Isn't it?

 

About GLES3, how could I enable it correctly
so the apps know the system support it?
The benchmark apps like GFXBench app don't see
GLES3 support so the GLES3 tests are disabled.
 

[Chih-Wei Huang]

Chih-Wei Huang於 2017年7月20日星期四 UTC+8下午12時23分47秒寫道：

Nicolas Capens於 2017年7月20日星期四 UTC+8上午12時55分43秒寫道：

Could you try replacing the X8B8G8R8 at this line with X8R8G8B8?

Let me know if that fixes it and then we can try to find the root cause. Thanks

Thanks for the suggestion.
I tested but no effect.

So I added mode debug messages.
Then I found the ioctl FBIOGET_VSCREENINFO is OK
(note in my previous logcat the failed ioctl is
FBIOPUT_VSCREENINFO instead of FBIOGET_VSCREENINFO)
so it get the fb info correct. info.transp.length is 0
so it chose sw::FORMAT_X8R8G8B8.
Isn't it correct?
Then I tried sw::FORMAT_X8B8G8R8.
But the colors are still swapped.
I lost

I tesed again the UVESAFB. Surprisingly the color is correct now!
My log shows it chose FORMAT_A8R8G8B8:
(I'm not sure why it's wrong yesterday. maybe I made some mistake?)

07-20 05:28:11.313  1094  1094 D libEGL  : loaded /vendor/lib/egl/libGLESv1_CM_swiftshader.so
07-20 05:28:11.315  1094  1094 D libEGL  : loaded /vendor/lib/egl/libGLESv2_swiftshader.so
(the log I added)
07-20 05:28:11.317  1094  1094 I libEGL_swiftshader: using (fd=8)
07-20 05:28:11.317  1094  1094 I libEGL_swiftshader: xres         = 1024 px
07-20 05:28:11.317  1094  1094 I libEGL_swiftshader: yres         = 768 px
07-20 05:28:11.317  1094  1094 I libEGL_swiftshader: xres_virtual = 1024 px
07-20 05:28:11.317  1094  1094 I libEGL_swiftshader: yres_virtual = 768 px
07-20 05:28:11.317  1094  1094 I libEGL_swiftshader: bpp          = 32
07-20 05:28:11.317  1094  1094 I libEGL_swiftshader: r            = 16:8
07-20 05:28:11.317  1094  1094 I libEGL_swiftshader: g            =  8:8
07-20 05:28:11.317  1094  1094 I libEGL_swiftshader: b            =  0:8
07-20 05:28:11.317  1094  1094 I libEGL_swiftshader: a            = 24:8
07-20 05:28:11.317  1094  1094 I libEGL_swiftshader: choose sw::FORMAT_A8R8G8B8
(end of the log I added)
07-20 05:28:11.327  1094  1094 W gralloc : page flipping not supported (yres_virtual=768, requested=1536)
07-20 05:28:11.327  1094  1094 I gralloc : using (fd=11)
07-20 05:28:11.327  1094  1094 I gralloc : id           = VESA VGA
07-20 05:28:11.327  1094  1094 I gralloc : xres         = 1024 px
07-20 05:28:11.327  1094  1094 I gralloc : yres         = 768 px
07-20 05:28:11.327  1094  1094 I gralloc : xres_virtual = 1024 px
07-20 05:28:11.327  1094  1094 I gralloc : yres_virtual = 768 px
07-20 05:28:11.327  1094  1094 I gralloc : bpp          = 32
07-20 05:28:11.327  1094  1094 I gralloc : r            = 16:8
07-20 05:28:11.327  1094  1094 I gralloc : g            =  8:8
07-20 05:28:11.327  1094  1094 I gralloc : b            =  0:8
07-20 05:28:11.327  1094  1094 I gralloc : width        = 163 mm (159.568100 dpi)
07-20 05:28:11.327  1094  1094 I gralloc : height       = 122 mm (159.895081 dpi)
07-20 05:28:11.327  1094  1094 I gralloc : refresh rate = 91.71 Hz

Then I hack Display::getDisplayFormat() to select
FORMAT_A8R8G8B8 even if alpha=0.

@@ -672,7 +695,8 @@ sw::Format Display::getDisplayFormat() const
                                                   info.blue.length   == 8 && info.blue.offset   == 0  &&
                                                   info.transp.length == 0)
                                                {
-                                                       return sw::FORMAT_X8R8G8B8;
+                                                       ALOGI("alpha=0 but choose sw::FORMAT_A8R8G8B8");
+                                                       return sw::FORMAT_A8R8G8B8;
                                                }
                                                if(info.red.length    == 8 && info.red.offset    == 0  &&
                                                   info.green.length  == 8 && info.green.offset  == 8  &&

Test again with bochsdrmfb. The color is also correct.

07-20 05:35:15.198  1087  1087 D libEGL  : loaded /vendor/lib/egl/libGLESv1_CM_swiftshader.so
07-20 05:35:15.201  1087  1087 D libEGL  : loaded /vendor/lib/egl/libGLESv2_swiftshader.so
07-20 05:35:15.203  1087  1087 I libEGL_swiftshader: using (fd=8)
07-20 05:35:15.203  1087  1087 I libEGL_swiftshader: xres         = 1024 px
07-20 05:35:15.203  1087  1087 I libEGL_swiftshader: yres         = 768 px
07-20 05:35:15.203  1087  1087 I libEGL_swiftshader: xres_virtual = 1024 px
07-20 05:35:15.203  1087  1087 I libEGL_swiftshader: yres_virtual = 768 px
07-20 05:35:15.203  1087  1087 I libEGL_swiftshader: bpp          = 32
07-20 05:35:15.203  1087  1087 I libEGL_swiftshader: r            = 16:8
07-20 05:35:15.203  1087  1087 I libEGL_swiftshader: g            =  8:8
07-20 05:35:15.203  1087  1087 I libEGL_swiftshader: b            =  0:8
07-20 05:35:15.203  1087  1087 I libEGL_swiftshader: a            =  0:0
07-20 05:35:15.203  1087  1087 I libEGL_swiftshader: alpha=0 but choose sw::FORMAT_A8R8G8B8
07-20 05:35:15.203  1087  1087 W gralloc : FBIOPUT_VSCREENINFO failed, page flipping not supported
07-20 05:35:15.203  1087  1087 W gralloc : page flipping not supported (yres_virtual=768, requested=1536)
07-20 05:35:15.203  1087  1087 I gralloc : using (fd=11)
07-20 05:35:15.203  1087  1087 I gralloc : id           = bochsdrmfb
07-20 05:35:15.203  1087  1087 I gralloc : xres         = 1024 px
07-20 05:35:15.203  1087  1087 I gralloc : yres         = 768 px
07-20 05:35:15.203  1087  1087 I gralloc : xres_virtual = 1024 px
07-20 05:35:15.203  1087  1087 I gralloc : yres_virtual = 768 px
07-20 05:35:15.203  1087  1087 I gralloc : bpp          = 32
07-20 05:35:15.203  1087  1087 I gralloc : r            = 16:8
07-20 05:35:15.203  1087  1087 I gralloc : g            =  8:8
07-20 05:35:15.203  1087  1087 I gralloc : b            =  0:8
07-20 05:35:15.203  1087  1087 I gralloc : width        = 163 mm (159.568100 dpi)
07-20 05:35:15.203  1087  1087 I gralloc : height       = 122 mm (159.895081 dpi)
07-20 05:35:15.203  1087  1087 I gralloc : refresh rate = 60.00 Hz


Any idea?

[Nicolas Capens]

On Thu, Jul 20, 2017 at 12:23 AM, Chih-Wei Huang <cwh...@android-x86.org> wrote:

Nicolas Capens於 2017年7月20日星期四 UTC+8上午12時55分43秒寫道：

Could you try replacing the X8B8G8R8 at this line with X8R8G8B8?

Let me know if that fixes it and then we can try to find the root cause. Thanks

Thanks for the suggestion.
I tested but no effect.

So I added mode debug messages.
Then I found the ioctl FBIOGET_VSCREENINFO is OK
(note in my previous logcat the failed ioctl is
FBIOPUT_VSCREENINFO instead of FBIOGET_VSCREENINFO)
so it get the fb info correct. info.transp.length is 0
so it chose sw::FORMAT_X8R8G8B8.
Isn't it correct?
Then I tried sw::FORMAT_X8B8G8R8.
But the colors are still swapped.
I lost.

Reading the code,
Am I correct that it just returns if a known format
is found without closing the fd?
(in Display::getDisplayFormat())
It's a fd leak. Isn't it?

Thanks for spotting that! Patching it.

Yes, since it's not conformant yet it's intentional that only apps which explicitly query non-conformant EGL configs see the ones with ES3 capabilities. Anyway, you can force-enable it in Config.cpp by disabling 'strictConformance'.

--
You received this message because you are subscribed to the Google Groups "swiftshader" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swiftshader+unsubscribe@googlegroups.com.
To post to this group, send email to swift...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/swiftshader/295258d1-d0aa-4b20-ad47-486d2fd10c80%40googlegroups.com.

[Nicolas Capens]

Great, that looks entirely correct.

Interesting. Adding an alpha channel could produce undesired results so this isn't a proper solution, but if it fixes the order of color components then it indicates a bug elsewhere. I'll check for differences in the handling of these formats in SwiftShader, and maybe also dig through these:

https://android-review.googlesource.com/#/q/RGB888

https://android-review.googlesource.com/#/q/RGBA8888

https://android-review.googlesource.com/#/q/BGRA8888

--
You received this message because you are subscribed to the Google Groups "swiftshader" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swiftshader+unsubscribe@googlegroups.com.
To post to this group, send email to swift...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/swiftshader/e6ff935f-6775-43ee-a709-57cddc3e2bb4%40googlegroups.com.

[Nicolas Capens]

https://swiftshader-review.googlesource.com/11209: does this fix the issue for you?

[Chih-Wei Huang]

Nicolas Capens於 2017年8月3日星期四 UTC+8上午3時45分03秒寫道：

https://swiftshader-review.googlesource.com/11209: does this fix the issue for you?

I just made the test.
The color is correct now. Thanks a lot!

But honestly speaking, I also have some changes
that may affect the result in my android side.
So I'm not very sure if it really fixes my issue.
I tried to recall the environment I tested
two weeks ago but not succeeded.
Anyway, I think it's perfect now.

BTW, what's the purpose the the different branches?

* android-emulator-current-release
* cloud-android-current-release

Which branch should I use?
The master branch seems also fine for me.

[Nicolas Capens]

On Fri, Aug 4, 2017 at 5:24 AM, Chih-Wei Huang <cwh...@android-x86.org> wrote:

Nicolas Capens於 2017年8月3日星期四 UTC+8上午3時45分03秒寫道：

https://swiftshader-review.googlesource.com/11209: does this fix the issue for you?

I just made the test.
The color is correct now. Thanks a lot!

But honestly speaking, I also have some changes
that may affect the result in my android side.
So I'm not very sure if it really fixes my issue.
I tried to recall the environment I tested
two weeks ago but not succeeded.
Anyway, I think it's perfect now.

I actually noticed that we're only handling FORMAT_R8G8B8 in FrameBuffer::copyRoutine, not FORMAT_B8G8R8. So the patch couldn't have been the proper fix.

While that's still a bug, I vaguely recall that 24-bit color formats are not even supposed to be used by any Android devices, mainly because many ARM processors demand power-of-two data alignment. So this code path might not be used at all (by Android).

If you get the chance could you check if any of your other changes fixed the root cause?

 

BTW, what's the purpose the the different branches?

* android-emulator-current-release
* cloud-android-current-release

Which branch should I use?
The master branch seems also fine for me.

These are the branches used by the Android Emulator and Cloud Android projects, respectively. The master branch often contains newer features and bug fixes though. But sometimes we're working on things for Chrome and we might inadvertently regress Android. That hasn't happened often though. For us it's also more useful if people report issues with builds from the master branch, since it excludes things we've already fixed, and it's useful to know early on if something broke. So the short answer is use the master branch if that works for you. :-)

--
You received this message because you are subscribed to the Google Groups "swiftshader" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swiftshader+unsubscribe@googlegroups.com.
To post to this group, send email to swift...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/swiftshader/c00aa483-02c6-4000-8d08-ebaac4dd0658%40googlegroups.com.

[Chih-Wei Huang]

Nicolas Capens於 2017年8月4日星期五 UTC+8下午10時57分37秒寫道：

On Fri, Aug 4, 2017 at 5:24 AM, Chih-Wei Huang <cwh...@android-x86.org> wrote:

Nicolas Capens於 2017年8月3日星期四 UTC+8上午3時45分03秒寫道：

https://swiftshader-review.googlesource.com/11209: does this fix the issue for you?

I just made the test.
The color is correct now. Thanks a lot!

But honestly speaking, I also have some changes
that may affect the result in my android side.
So I'm not very sure if it really fixes my issue.
I tried to recall the environment I tested
two weeks ago but not succeeded.
Anyway, I think it's perfect now.

I actually noticed that we're only handling FORMAT_R8G8B8 in FrameBuffer::copyRoutine, not FORMAT_B8G8R8. So the patch couldn't have been the proper fix.

While that's still a bug, I vaguely recall that 24-bit color formats are not even supposed to be used by any Android devices, mainly because many ARM processors demand power-of-two data alignment. So this code path might not be used at all (by Android).

I agree. I didn't see explicit clues that RGB_888 is used.
 

If you get the chance could you check if any of your other changes fixed the root cause?

OK. I made more tests.
I found my fb device and the requested format in eglCreateWindowSurface affect the result.

By default AOSP requests HAL_PIXEL_FORMAT_RGBA_8888 explicitly[1].
I tested QEMU with different fb devices: bochsdrmfb, uvesafb and virtiodrmfb.
The first two have r-b swapped issue, but the color of virtiodrmfb is correct (I'm surprised)

We have a patch in eglCreateWindowSurface[2] that would select HAL_PIXEL_FORMAT_BGRA_8888 finally.
With the patch I got correct colors in the 3 fb devices.
Though it works but HAL_PIXEL_FORMAT_BGRA_8888 may cause some apps fail.
Is there a way to make HAL_PIXEL_FORMAT_RGBA_8888 works?

[1]: https://android.googlesource.com/platform/frameworks/native/+/master/opengl/libs/EGL/eglApi.cpp#481
[2]: https://osdn.net/projects/android-x86/scm/git/frameworks-native/commits/f92829a8e0586074a2f4d82e81433590b8494cd2

 

BTW, what's the purpose the the different branches?

* android-emulator-current-release
* cloud-android-current-release

Which branch should I use?
The master branch seems also fine for me.

These are the branches used by the Android Emulator and Cloud Android projects, respectively. The master branch often contains newer features and bug fixes though. But sometimes we're working on things for Chrome and we might inadvertently regress Android. That hasn't happened often though. For us it's also more useful if people report issues with builds from the master branch, since it excludes things we've already fixed, and it's useful to know early on if something broke. So the short answer is use the master branch if that works for you. :-)

Great. Thank you for the explanation.
I'll stay with the master. :-)

[Chih-Wei Huang]

Chih-Wei Huang於 2017年8月10日星期四 UTC+8下午5時28分48秒寫道：

Nicolas Capens於 2017年8月4日星期五 UTC+8下午10時57分37秒寫道：

On Fri, Aug 4, 2017 at 5:24 AM, Chih-Wei Huang <cwh...@android-x86.org> wrote:

Nicolas Capens於 2017年8月3日星期四 UTC+8上午3時45分03秒寫道：

https://swiftshader-review.googlesource.com/11209: does this fix the issue for you?

I just made the test.
The color is correct now. Thanks a lot!

But honestly speaking, I also have some changes
that may affect the result in my android side.
So I'm not very sure if it really fixes my issue.
I tried to recall the environment I tested
two weeks ago but not succeeded.
Anyway, I think it's perfect now.

I actually noticed that we're only handling FORMAT_R8G8B8 in FrameBuffer::copyRoutine, not FORMAT_B8G8R8. So the patch couldn't have been the proper fix.

While that's still a bug, I vaguely recall that 24-bit color formats are not even supposed to be used by any Android devices, mainly because many ARM processors demand power-of-two data alignment. So this code path might not be used at all (by Android).

I agree. I didn't see explicit clues that RGB_888 is used.
 

If you get the chance could you check if any of your other changes fixed the root cause?

OK. I made more tests.
I found my fb device and the requested format in eglCreateWindowSurface affect the result.

By default AOSP requests HAL_PIXEL_FORMAT_RGBA_8888 explicitly[1].
I tested QEMU with different fb devices: bochsdrmfb, uvesafb and virtiodrmfb.
The first two have r-b swapped issue, but the color of virtiodrmfb is correct (I'm surprised)

We have a patch in eglCreateWindowSurface[2] that would select HAL_PIXEL_FORMAT_BGRA_8888 finally.
With the patch I got correct colors in the 3 fb devices.

Sorry I forgot another important patch [3].
This patch is in AOSP master branch but not in Nougat (which I'm using).
I just picked it to our branch recently (for other reasons).
It fortunately fixed the color swapped issue here.
The reason is, without it, alpha=0 and eglCreateWindowSurface
would select RGBX_8888 finally which results in the color swapped issue.
(in bochsdrmfb and uvesafb, but virtiodrmfb is still correct)
That's what I encountered two weeks ago.

[3]: https://android.googlesource.com/platform/frameworks/native/+/e7f39727a484107b2d2a78eaaaacad3d7f44c24d%5E%21/#F0
[4]: https://android.googlesource.com/platform/frameworks/native/+/master/opengl/libs/EGL/eglApi.cpp#499