Subject: [E-devel] [Patch] Evas gl shader use binary shader
I make patch related with evas gl binary shader.
The concept of binary shader is compile shader only once.
Some people want to use binary shader because of performance issue.
In current evas gl engine, every application have to compile shader each
time.
But I modify code , so only first running application need compile shader.
Other application use already compiled shader(binary shader)
The binary shader is made under HOME/.evas/gl_common_shaders directory.
Binary shader is created according to GL vendor,GL renderer, GL version and
Module_arch.
The basic flow is
1. First running application which use gl engine check binary shader
directory, but it can't find binary shader.
2. After compiling shader, It saves compiled shaders..
3. Other application checks shader directory, it can use binary
shaders.
In mobile target, using binary shader, I can save 150ms. (that time, there
is 11 shaders).
If there is more shaders and more applications, this flow maybe save more
total time.
(the above is now in, changelog coming, with change to using ~/.cache,
some formatting fixes, make ity do the desktop gl one right with the
retrievable hint parameter ont he program etc. - doesn't break desktop
gl at least. yay. a,so fixes to mke it compile at all).
SVN revision: 59167
Thanks to Brian Wang for the report.
This happened because we were querying for the index of the wrong fi,
this became especially visible after we started caching fi.
SVN revision: 59152
Only call eina_threads_shutdown when thread are dead and not before.
Release and destroy thread lock before calling evas_async_events_process
as you should never have a lock taken in the main loop when calling it.
SVN revision: 59119
All thread debugging facility, including lock debug, on by turning --enable-debug-threads
at configure time of eina.
When threads check are disable, make sure that all lock/release are called
from the main loop only. And in all case, eina_lock_new/eina_lock_delete should be
called from the main loop.
Remove static initialization as it is not portable under Windows.
SVN revision: 59118
Subject: evas_gl_api_get patch.
Here's a patch that simply overrides the GL functions for Evas_GL
except for two functions that I provide on my own. It may have some symbol
resolving warnings but that'll all go away eventually when we do everything
via dlsym or getProcAddress.
You can apply the patch to the latest revision of evas. (I've just
updated them) I'm also attaching a sample GLES program that uses
evas_gl_api_get. You don't need to link it to -lGL.
SVN revision: 59092
some fundamental errors there. don't go replacing pthread locks with
wrappers unless you know full well what u are doing. havnig threads
only work while "threads are initted" and then init/shtudown the thread
thing every time u spawn a thread.. is pretty silly. what if a thread
ends in the background WHILE u have a lock.. u try unlock.. u know
what ? your unlock DOES nothing. so you retain a lock. next time u
want to lock once a thread is around.. u have a deadlock issue.
even better - the checking if threads are initted and up is not
locked, so it can come up while it is being checked. more race
conditions. u need to clokc the init/shutdown AND lock the checking of
the value... and even then u STILl have problem #1 above. so that code
is now gone.
also trylock trturn inverse logic to the original pthread func and the
macros in evas that used it were not changed accordingly! aaagh!
i've also added backtrace debug ability to eina threads if compiled in
- u can get a bt of who last locked something. i had to do this just to
begin to grasp what on earth was going on. it's off by default.
also... the locks are error check locks to trylock can detect
deadlocks. speacil "2" return for now. better than a poke in the eye
with a sharp stick until we decide what to do. for now i hopew i have
killed this thread lock bug.
SVN revision: 59085
Carsten Haitzler
Jiyoun Park
Tom Hacohen
Cedric BAIL
Vincent Torri
Sung W. Park