glshim
- Thread starter lunixbochs
- Start date
ptitSeb
Serial Porter
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).
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:
ptitSeb
Serial Porter
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).
Without an fps counter, subjectively speaking, I'm unable to tell the difference.
@lunixbochs
As for TinyGLES, I can't start FO with either glshim (segfaults)
Last edited by a moderator:
- Joined
- Sep 18, 2011
- Messages
- 742
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.
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:
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
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
edgex004
Advanced Member
- Joined
- Jan 5, 2008
- Messages
- 1,222
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!
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!
ptitSeb
Serial Porter
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?
In short could some debug messages be of interest to you in case there's any room for improvement?
Last edited by a moderator:
ptitSeb
Serial Porter
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?
The browser however is spitting out tonnes of warning/error messages related to the issue. Care to look?
Last edited by a moderator:
- Joined
- Jan 18, 2010
- Messages
- 11,418
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:
ptitSeb
Serial Porter
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:
Yes, the whole command line is there in the wiki.
I begin wondering - should there be no effect at all then? (for scrolling or html rendering)
Last edited by a moderator:
ptitSeb
Serial Porter
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
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:
ptitSeb
Serial Porter
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)
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:
