i.Mx6 Vivante libGAL.so: _UploadBGRtoARGB

cancel
Showing results for 
Search instead for 
Did you mean: 

i.Mx6 Vivante libGAL.so: _UploadBGRtoARGB

Jump to solution
4,011 Views
leroy_o
Contributor III

Hi,

I am working on an OpenGL project on the freescale i.MX6 which uses GL_RGB textures.

I have been doing code profiling with oprofile and found out that libGAL.so makes convertions in CPU: _UploadBGRtoARGB, which account for 30 % of the CPU load in our application.

Does this mean that the native format of Vivante hardware is BGRA, and if I want to improve the efficiency of my application, i need to use GL_BGRA?


Labels (2)
1 Solution
157 Views
LorenHuang
Contributor IV

I believe the texture you are using is RGB888, right? Vivante GPU(not only vivante GPU, almost all GPU) doesn't support 24bit pixel format, so it need to convert it to 32bit pixel RGBX8888. Function _UploadBGRtoARGB() can also output RGBX8888. If the type of GL_RGB is GL_UNSIGNED_SHORT_5_6_5, function _UploadBGRtoARGB() will not be called. 

About 30% CPU loading, the MX6 GA BSP release have an optimzaiton of such part code, the performance should be improved significantly.

View solution in original post

0 Kudos
11 Replies
157 Views
leroy_o
Contributor III

A comment on the former post,

I checked in our code, and GL_BGR(A) pixels or textures are never used. All along our program, gl functions use GL_RGB(A).

Does anyone know why _UploadBGRtoARGB, which accounts for 30 % of the CPU load in our application, is executed in libGAL.so in these conditions?

0 Kudos
158 Views
LorenHuang
Contributor IV

I believe the texture you are using is RGB888, right? Vivante GPU(not only vivante GPU, almost all GPU) doesn't support 24bit pixel format, so it need to convert it to 32bit pixel RGBX8888. Function _UploadBGRtoARGB() can also output RGBX8888. If the type of GL_RGB is GL_UNSIGNED_SHORT_5_6_5, function _UploadBGRtoARGB() will not be called. 

About 30% CPU loading, the MX6 GA BSP release have an optimzaiton of such part code, the performance should be improved significantly.

View solution in original post

0 Kudos
157 Views
leroy_o
Contributor III

With RGBA8888 and the MX6 GA BSP, the _UploadBGRtoARGB() function is not used, but instead, the gcoHARDWARE_UploadTexture() from libGAL-x11.so is used and still accounts for 30 % of the CPU load of our running application.

I don't know much things about GPUs, and I would like to ask:

why isn't the texture upload to the GPU done in the galcore kernel module by a DMA, instead of having it done by CPU in the libGAL-x11.so?

0 Kudos
157 Views
LorenHuang
Contributor IV

The optimization is for improving performance, not for reducing CPU loading. Normally, in such use case, cpu copy will have higher performance.

0 Kudos
157 Views
leroy_o
Contributor III

I have another question on the i.MX6 GPU. Does Vivante GPU support Pixel Buffer Objects (PBO) or Frame Buffer Objects (FBO)?

With these GPU controlled buffers, textures are sent to the GPU by the CPU but by DMA, therefore we wouldn't have these bottlenecks.

I searched in the GL header files, but I couldn't find:

- glGenBuffersARB

- glBindBufferARB

- glBufferDataARB ... symbols.

Can you confirm that Pixel Buffer Objects (PBO) and Frame Buffer Objects (FBO) are not supported by i.MX6 Vivante GPU presently or in the future?

0 Kudos
157 Views
LorenHuang
Contributor IV

Please double check the API you are using, not all standards has the concept and functions you mentioned.

And you can query the driver through GL_EXTENSIONS to check if the driver supports the extension you requirement.

0 Kudos
157 Views
leroy_o
Contributor III

Thanks for your reply. OpenGL ES 2.0 doesn't support PBOs and FBOs, this is clear.

For precision sake, here is the output of the driver query on the i.MX GA1 BSP:

GL_VENDOR: Vivante Corporation

GL_VERSION: OpenGL ES 2.0

GL_RENDERER: GC2000 core

GL_SHADING_LANGUAGE_VERSION: OpenGL ES GLSL ES 1.00

GL_EXTENSIONS: GL_OES_compressed_ETC1_RGB8_texture GL_OES_compressed_paletted_texture GL_OES_EGL_image GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_fragment_precision_high GL_OES_rgb8_rgba8 GL_OES_stencil1 GL_OES_stencil4 GL_OES_texture_npot GL_OES_vertex_half_float GL_OES_depth_texture GL_OES_packed_depth_stencil GL_OES_standard_derivatives GL_OES_get_program_binary GL_EXT_texture_format_BGRA8888 GL_IMG_read_format GL_EXT_blend_minmax GL_EXT_read_format_bgra GL_EXT_multi_draw_arrays GL_APPLE_texture_format_BGRA8888 GL_APPLE_texture_max_level GL_ARM_rgba8 GL_EXT_frag_depth GL_VIV_shader_binary GL_VIV_timestamp GL_OES_mapbuffer GL_OES_EGL_image_external GL_EXT_discard_framebuffer GL_OES_vertex_type_10_10_10_2 GL_EXT_texture_type_2_10_10_10_REV GL_EXT_texture_filter_anisotropic

GL_ALIASED_LINE_WIDTH_RANGE        1 - 8192(MIN:1 - 1)

GL_MAX_TEXTURE_SIZE                8192(MIN:64)

GL_MAX_VERTEX_ATTRIBS            16(MIN:8)

GL_MAX_VERTEX_UNIFORM_VECTORS    168(MIN:128)

GL_MAX_FRAGMENT_UNIFORM_VECTORS    64(MIN:16)

GL_MAX_VARYING_VECTORS            12(MIN:8)

GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS    4(MIN:0)

GL_MAX_TEXTURE_IMAGE_UNITS            8(MIN:8)

GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS            12

GL_MAX_RENDERBUFFER_SIZE            8192


0 Kudos
157 Views
LorenHuang
Contributor IV

Besides extension, please also check the spec.

FBO is not extension in ES2.0, it's a mandatory feature.

157 Views
rocwzp
Contributor II

I got the same GL_EXTENSIONS with GL_ARB_framebuffer_objectGL_EXTENSIONS in Ubuntu.

Vivante GPU in

0 Kudos
157 Views
LorenHuang
Contributor IV

i.IMX6 GLES2.0 driver supports FBO feature.

0 Kudos
157 Views
leroy_o
Contributor III

Yes, the texture I am using is RGB888. Thanks for your valuable answer. I was considering using RGBA8888, but based on your answer, I will rather try to use GL_UNSIGNED_SHORT_5_6_5 types. Thanks again.

0 Kudos