glshim


Thanks, that was quick! You're an ace, luminace ;)
(last commit joke)

Up to now I've not used any custom CFLAGS when compiling glshim - does it even make sense to use any?
 
Last edited by a moderator:
It should not take much cpu, but some optim are always welcome. 
I compile on my side with -ffast-math -O3 -mcpu=neon (plus a few other switches) to make sure there is vectorisation (as some part are not hand optimised at all, like the texgen used in FoobillardPlus for example).
 
It should not take much cpu, but some optim are always welcome. 
I compile on my side with -ffast-math -O3 -mcpu=neon (plus a few other switches) to make sure there is vectorisation (as some part are not hand optimised at all, like the texgen used in FoobillardPlus for example).

Before you answered I'd tried -flto and it hasn't caused any problems either. I'll add -mfpu and -mcpu flags to see if it makes any noticable difference.

EDIT:
So, with vectorization and flto I can't say I see any diffrence - which game would be the most probable to exhibit some performance boost?
 
Last edited by a moderator:
It should not take much cpu, but some optim are always welcome. 
I compile on my side with -ffast-math -O3 -mcpu=neon (plus a few other switches) to make sure there is vectorisation (as some part are not hand optimised at all, like the texgen used in FoobillardPlus for example).

Before you answered I'd tried -flto and it hasn't caused any problems either. I'll add -mfpu and -mcpu flags to see if it makes any noticable difference.

EDIT:
So, with vectorization and flto I can't say I see any diffrence - which game would be the most probable to exhibit some performance boost?
FoobillardPlus should have a little boost. Anything heavy on Texgen and/list multiple call list should benefit from more optim (and foobillard is one of those).
 
Last edited by a moderator:
TinyGLES requires the tinygles branch of glshim (which is actually pretty old) due to different supported texture formats between tinygles and a real driver. I'll add an issue on github to make it work with the main branches.
 
Last edited by a moderator:
Oops, sorry, had no idea - there's not much info on usage. It became clear to me what I was supposed to do only after seeing the compiled library name :)

EDIT: I suggest adding a phrase like "a drop-in replacement" somewhere at the start of the readme
(interesting!)

Btw, on odroids, libs like gles(1,2) and egl are just symlinks to libMali and the former doesn't even have v1 in its name so the resulting file needs to be renamed.
 
Last edited by a moderator:
I know I would personally be interested to see an accelerated version of Chromium. Won't do much for the Pandora, unfortunately, as we are stuck with some very old and unstable builds of the browser.

From what I understand, building a more current version that is compatible with our libs would be a nightmare.

But I'm definitely holding out hope that this will be better on the Pyra!
 
Hi again,

Would it make any sense to try looking deeper into this? (accelerated Chromium browser)

http://forum.odroid.com/viewtopic.php?f=117&t=16328

Thx

I have issue with building Chromium for softfloat. It seems all the build system take ARM as a CrossCompile to Hardfloat... So I'll probably not be abble to test.

Anyway, you have to know that WebGL is based on GLES|2, and, for now, glshim is based on GLES 1.1. So, if you start Chormium (or anything else) with glshim, you create a GLES 1.1 context, so you will not have shaders (and the oposite is also true, if start a Qt5 program for example, that use GLES2, you cannot use glshim).

For that, a glshim that use GLES|2 as backend is needed, but that is a huge work (I may try that, but I haven't yet).

Anyway, for Chromium, you should look at the compile flags and parameter, to try activated GLES2 acceleration instead of OpenGL, I think it exist too (for mobile).
 
Ok, you probably didn't read that link. There's no problem with GLES acceleration on C1 (32 bpp), only the Mali driver has alpha issues so it's preferable to use 24 or 16 bpp for everyday work. But because native acceleration doesn't work at 16bpp I found to my surprise that even though glshim is not gles v2 it'still able to provide a great speedup.

In short could some debug messages be of interest to you in case there's any room for improvement?
 
Last edited by a moderator:
Ok, you probably didn't read that link. There's no problem with GLES acceleration on C1 (32 bpp), only the Mali driver has alpha issues so it's preferable to use 24 or 16 bpp for everyday work. But because native acceleration doesn't work at 16bpp I found to my surprise that even though glshim is not gles v2 it'still able to provide a great speedup.

In short could some debug messages be of interest to you in case there's any room for improvement?

Well, I read it, but I don't understand. Is there some rendering issue with Chomium or not ?
If there are rendering issue, a screenshot can be helpfull.

If you want more speed, you can try LIBGL_BATCH=1 but I doubt it will be helpfull (chance are that it break the rendering in fact).
 
HTML rendering and scrolling seems to accelerated. The only pure GL stuff I've seen would be the WebGL demo and it doesn't work at all.

The browser however is spitting out tonnes of warning/error messages related to the issue. Care to look?



 
 
Last edited by a moderator:
HTML rendering and scrolling seems to accelerated. The only pure GL stuff I've seen would be the WebGL demo and it doesn't wok at all.

The browser however is spitting out tonnes of warning/error messages related to the issue. Care to look?



 

If I recall Chrome/Chromium has a blacklist of 3D accelerators that they don't officially support, there is a way of forcing WebGL on.  Just at work and can't dig into it at the moment.
 
Last edited by a moderator:
HTML rendering and scrolling seems to accelerated. The only pure GL stuff I've seen would be the WebGL demo and it doesn't wok at all.

The browser however is spitting out tonnes of warning/error messages related to the issue. Care to look?



 

This is what I (confusedly) explained. WebGL is based on GLES2. That means it will want an OpenGL 2.0+ hardware, with shader & co. And this is not supported right now on glshim, because it's based on GLES 1.1 (and both version are exclusive, you cannot have both at the same time, in the same rendering context). So WebGL will not work at all (same if you use a real OpenGL card that doesn't support Shaders).
 
Last edited by a moderator:

If I recall Chrome/Chromium has a blacklist of 3D accelerators that they don't officially support, there is a way of forcing WebGL on.  Just at work and can't dig into it at the moment.
Yes, the whole command line is there in the wiki.


This is what I (confusedly) explained. WebGL is based on GLES2. That means it will want an OpenGL 2.0+ hardware, with shader & co. And this is not supported right now on glshim, because it's based on GLES 1.1 (and both version are exclusive, you cannot have both at the same time, in the same rendering context). So WebGL will not work at all (same if you use a real OpenGL card that doesn't support Shaders).
I begin wondering - should there be no effect at all then? (for scrolling or html rendering)
 
Last edited by a moderator:

If I recall Chrome/Chromium has a blacklist of 3D accelerators that they don't officially support, there is a way of forcing WebGL on.  Just at work and can't dig into it at the moment.
Yes, the whole command line is there in the wiki.


This is what I (confusedly) explained. WebGL is based on GLES2. That means it will want an OpenGL 2.0+ hardware, with shader & co. And this is not supported right now on glshim, because it's based on GLES 1.1 (and both version are exclusive, you cannot have both at the same time, in the same rendering context). So WebGL will not work at all (same if you use a real OpenGL card that doesn't support Shaders).
I begin wondering - should there be no effect at all then?
Yeah, it should refuse the rendering. But I guess there is not the proper test to disable it?
(or is there a GL 1.x path for WebGL, I doubt it, but I haven't checked in the code to be honest, no on Chromium or in Firefox/PaleMoon)
 
I've tried using --use-gl=none and frankly I'm not sure any more. Scrolling and page rendering speed doesn't seem to differ much if at all.
Merde! ;)

EDIT:
There's probably nothing new to see here but please have a look so we can put the matter to rest.


View attachment 12240
 
Last edited by a moderator:
Mmmm, Error log contains only faillure to open a GLES2 context... So I guess it fall back to Software rendering, that seems to be faster?! (Ah ben zut alors!)
 
Thanks! I wasn't a chromium user before so I didn't immediately think it could be so much faster than firefox in pure software.

The funny stuff: with mesa rendering chromium is not much slower than FF :) (which means it does want to use OpenGL for some 2d operations indeed and trying to use glshim would be fully justified if it had GLES2 support)
 
Last edited by a moderator:
Back
Top