32bits GLES?

[ptitSeb]

Is there a way to open a GLES (1) context with 32bpp?

My problem is, if my understanding is right, you can have only 1 context for GLES, so FBO share the same context as may screen.

If I want to create FBO with an alpha channel, I need a context with an alpha channel.

I tried many things but always fail to create a context with alpha, be it 8888, 5551 or even 4444. Only without alpha works.

Does someone as a solution?

 

[mjohansson]

Did you activate blending?

glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

glEnable(GL_BLEND);

 

[ptitSeb]

Bump on this subject.

When I create an OpenGLES context (being ES1 or ES2), I always get 5/6/5 colors bits and 0 alpha bits.

I tried to create a 8/8/8/8 but that fail. Whatever the driver, and with FB or X11.

Does any of you has an hint to get a 32bits Context and not a 16bits (or at least a 4/4/4/4 ?).

 

[bsp]

You don't need to choose an EGL config with alpha bits in order to render to an RGBA FBO.

A couple of months ago I wrote a test program that does just that (create RGBA texture, create framebuffer, attach texture to framebuffer, render color+alpha gradient to texture, then enable srcover alpha blending and use texture to render to window surface).

However, I also have not found a way to render to an ARGB32 (or RGB32) window surface, only RGB565 works. Setting EGL_RED/GREEN/BLUE_SIZE to 8 makes eglChooseConfig() fail.

From a technical point of view, there's no good reason for this restriction. It's perfectly possible to configure a 32bit xRGB or ARGB Linux framebuffer and render to it via CPU or DSP.

Related to this GLES issue is that the window surface always seems to be copied to the Linux framebuffer. This is OK when the surface is not fullscreen but if it is fullscreen, this is simply a waste of bandwidth (~44 MB/sec).

The native window handle parameter that I pass to eglCreateWindowSurface() is NULL but that just seems to select the root window.

Is there any way to do 24/32bit rendering with the SGX GLES (w/o changing the X11 config manually) ? Preferably with true hardware buffer swapping instead of copying ?

Maybe I'm missing something obvious here, any help would really be appreciated.

 

[sswam]

Is there a way to open a GLES (1) context with 32bpp?

My game Rescue uses 32bpp GLES with SDL.  I'm sure it's at least 24 bit color depth.  I'm using alpha blending with textures, but not FBO.


1. SDL_Init(SDL_INIT_VIDEO|SDL_INIT_AUDIO)


2. sdl_surface = SDL_SetVideoMode(vw, vh, 32, SDL_FULLSCREEN)


3. then normal gl init stuff from here:  http://sam.nipl.net/code/brace/lib/gles/gl.b


That code is basically C, although it looks different.


You can check sdl_surface->format->BytesPerPixel == 4


I think it uses hardware buffer swapping, not sure, I would have to check.


Hopefully that helps, or maybe I misunderstood what you are trying to do.

 

[ptitSeb]

I don't want 32bits GLES for FBO anymore, I changed project, but @bsp, did your test program was using GLES1 or GLES2. I have trouble with FBO on GLES1 (but they work fine on GLES2).

The game I want to port use "GL_DST_ALPHA" has the Source for the Blender, so it just doesn't work without alpha channel on screen (and I don't use an FBO to then blit the FBO, I think it will make thing slower than direct to screen).

@sswam: thanks for the code. But, are you sure the having an SDL Surface at 32bits makes the GLES Surface 32bits? What if, in your code, you uncomment the COLOURDEPTH_RED_SIZE GREEN and BLUE in the g_configAttribs array and you set the constant to 8/8/8 instead of 5/6/5 to force egl Context to 24 bits ?

 

[bsp]

@sswam: Thanks for replying but your code also just creates an RGB565 GLES surface. I just tried it out. You can easily confirm this by calling glGetInteger() with param GL_RED_BITS. Attempting to request EGL_RED/GREEN/BLUE_SIZE=8 in the EGL config attribs will result in no available configs.

It seems like the GLES driver overrides the SDL setup (btw, yes, the SDL surface pitch is 3200, i.e. 4*800, i.e. 32bit). I tried to render some pixels via SDL and SDL_UpdateRect() hangs (had to kill the process). It works when not creating the GLES surface.

I think I remember having read that the GLES driver can run without X11, i.e. framebuffer device only. Maybe that way it's possible to create a 24bit or 32bit EGL surface ?

Does anyone know if/how this can be done?


@ptitSeb: Nope, rendering everything to an offscreen RGBA surface (FBO), which is then copied to another offscreen RGB surface (EGL window surface), which is then copied to the actual framebuffer by the GLES driver during eglSwapBuffers() will surely not make things go any faster

I initially started with a GLES1 test program, too, but also encountered issues with that driver (in particlar glReadPixels(), which only returned garbage for the FBO). I then moved on to GLES2, which works fine so far, except for aforementioned issues (32bit-not-working + copy-instead-of-exchange swap strategy).

 

[Cloudef]

I think I remember having read that the GLES driver can run without X11, i.e. framebuffer device only. Maybe that way it's possible to create a 24bit or 32bit EGL surface ?

Does anyone know if/how this can be done?

http://pandorawiki.org/SGX_drivers#Driver_operation_modes

https://github.com/Cloudef/glhck/blob/internal-restructure/3rdparty/pandora/src/pandorahck.c

 

[bsp]

^^ That's not a solution, either. I tried that before (use EGL_DEFAULT_DISPLAY and pass 0 as native window handle). Opening a fullscreen window solves the messed-up-desktop issue, of course.

It's still not possible to create a 32bit window surface, and even in fullscreen mode, eglSwapBuffers() copies data, instead of simply updating the hardware framebuffer address. To verify that, I modified my testcase to restrict GL rendering to one quarter of the screen (via GL_SCISSOR_TEST).

The wiki already says that 'in framebuffer mode the driver will fight with X for display' -- this wouldn't happen if the GL would use 'exchange'-style buffer swapping instead of 'copy'. At least the desktop would flicker when scrolling in a terminal while the 'framebuffer mode' GLES test is running.

Well, I also seem to remember that this topic once came up in a different thread and that someone mentioned that the only solution to this was to configure the framebuffer to 32bit at boot time, and modify xorg.conf to use 32bits (or was it 24?). Also not a viable solution.

 

[ptitSeb]

^^ That's not a solution, either. I tried that before (use EGL_DEFAULT_DISPLAY and pass 0 as native window handle). Opening a fullscreen window solves the messed-up-desktop issue, of course.


It's still not possible to create a 32bit window surface, and even in fullscreen mode, eglSwapBuffers() copies data, instead of simply updating the hardware framebuffer address. To verify that, I modified my testcase to restrict GL rendering to one quarter of the screen (via GL_SCISSOR_TEST).


The wiki already says that 'in framebuffer mode the driver will fight with X for display' -- this wouldn't happen if the GL would use 'exchange'-style buffer swapping instead of 'copy'. At least the desktop would flicker when scrolling in a terminal while the 'framebuffer mode' GLES test is running.


Well, I also seem to remember that this topic once came up in a different thread and that someone mentioned that the only solution to this was to configure the framebuffer to 32bit at boot time, and modify xorg.conf to use 32bits (or was it 24?). Also not a viable solution.

Yep, I remember that too, I wanted to search for it, to see if I could use that somehow.

About the swap/blit for the SwapBuffer, once in FB mode (that is, Display=EGL_DEFAULT_DISPLAY and Window=NULL when you create the eglContext), Notaz mentionned that if you put an "powervr.ini" in your folder (which one, I'm not sure, so I put the file in both current and "lib" folder of my PND) containing that


[default]
WindowSystem=libpvrPVR2D_FLIPWSEGL.so

It will use Swap instead of Blit, and I think it do work (even if I cannot prove it).

 

[Cloudef]

strace -e open to see where it tries to open that file. It's documented in PVR SGX docs (and all the possible variables).

Xorg configuration should have nothing to do with SGX bit depth (at least in framebuffer mode).

You might need to play around with fbset perhaps.

 

[ptitSeb]

strace -e open to see where it tries to open that file. It's documented in PVR SGX docs (and all the possible variables).


Xorg configuration should have nothing to do with SGX bit depth (at least in framebuffer mode).


You might need to play around with fbset perhaps.

Yep, I guess so lsof | grep mysoftware on a SSH terminal might also do the trick.

About fbset, of I take a look. I tried ofbset earlier, but you cannot define bitdepth. But fbset looks fine.

 

[Cloudef]

http://tiprocessors.com/index.php/GSG:_OMAP35x_Graphics_SDK_Additional_Procedures#Testing_the_support_for_ARGB8888_in_Frame_Buffer_Driver

Related, you need to reload the module after fbset. No idea if it works though, good luck.

If you manage to get it working though, note that performance most likely will be a lot worse.

Yep, I guess so lsof | grep mysoftware on a SSH terminal might also do the trick.

Not really, the file most likely isn't always open and it won't show the locations where it tried to open.In this case you most likely don't want to override the default /etc/powervr.ini for example, but check if the driver tries to open powervr.ini from the executable directory.

 

[bsp]

I copied your powervr.ini to /etc (and renamed the old one).

Now I see X11 flicker (as expected), i.e. HW buffer swapping is used (including implicit vsync, logically).

Can't say whether GLES continues to use offscreen buffers (except for the real backbuffer / invisible part of the framebuffer) for rendering, but one wouldn't expect it to do so. If real 'page flipping' is used now, there should be a measurable performance improvement (will have to verify that later).

@Cloudef: Thanks, but changing the boot (+fbdev, +Xorg) config is not an option.

 

[ptitSeb]

http://tiprocessors.com/index.php/GSG:_OMAP35x_Graphics_SDK_Additional_Procedures#Testing_the_support_for_ARGB8888_in_Frame_Buffer_Driver


Related, you need to reload the module after fbset. No idea if it works though, good luck.


If you manage to get it working though, note that performance most likely will be a lot worse.

Yep, I guess so lsof | grep mysoftware on a SSH terminal might also do the trick.

Not really, the file most likely isn't always open and it won't show the locations where it tried to open.
In this case you most likely don't want to override the default /etc/powervr.ini for example, but check if the driver tries to open powervr.ini from the executable directory.

Yep, it works !


From a SSH terminal I did


fbset -depth 32 -rgba 8/16,8/8,8/0,8/24

which imediatly break the X window display (doesn't mater, I'm on SSH )


and then I did


sudo /etc/init.d/pvr-init stop
sudo /etc/init.d/pvr-init start

and launch my game, and it works ! I had the effect (but fbgrab doesn't work well in 32bits!)


But I had to type my Password for the sudo, and I cannot launch that stat/stop without that. Is there another way to have that ?

 

[bsp]

Cool, that really works. Without any boot config modification!

A bit useless, though, since SDL (for input handling..) requires X11 (just segfaults w/o it)

EDIT: although wait... X is still running..

 

[Cloudef]

A bit useless, though, since SDL (for input handling..) requires X11 (just segfaults w/o it)

X most likely is still there, just skrewed. You can fix this by using fbdev xorg driver on 32bit mode, as IIRC the omapfb xorg driver doesn't work on this mode.

But I had to type my Password for the sudo, and I cannot launch that stat/stop without that. Is there another way to have that ?

Not really.. You could create C binary with SUID attribute that runs those two commands (doesn't need sudo then) and ask it to be included in firmware, but that's about it.Or, do it in the way other stuff in pandora has been done and request that script to be added in sudoers. Not that good for security, but oh well. It's pandora

 

[ptitSeb]

Cool, that really works. Without any boot config modification!


A bit useless, though, since SDL (for input handling..) requires X11 (just segfaults w/o it)


EDIT: although wait... X is still running..

Yep, X is running, just you have to be sure to put back an fbset -depth 16 when exiting the game... Plus you need sudo password, no not very convenient for now.

h34r: 'd by Cloudef

 

[bsp]

yep, this is very nice. I just did a quick GLES_32bit+SDL test and wrote me two scripts for switching back and forth between 32/16 bit Thanks!