There was no explicit support for x86/64 architecture in EGL/GLES wrappers.
This resulted either in failures or sub-optimal implementation of the wrapper functions.
Change-Id: I20d99d7372fbf642ee4b94a05c8cb971cba29988
Signed-off-by: Wajdeczko, Michal <michal.wajdeczko@intel.com>
in the common case this saves one instructions per jump
(which will help with the i-cache).
this change also gets rid of the "use slow tls" option,
which was useless. So at least now architectures that don't have
assembly bindings will perform much better.
Change-Id: I31be6c06ad2136b50ef3a1ac14682d7812ad40d2
* changes:
Symlink /system/lib/libGLESv3.so -> libGLESv2.so
Add ES3 support to libGLESv2 and tracing tools
Import OpenGL ES 3.0 headers from Khronos SVN
Since ES3 is backwards compatible with ES2, a new wrapper isn't
necessary, and the Khronos implementation guidelines recommend
supporting both versions with the same library.
Change-Id: If9bb02be60ce01cc5fe25d1f40c4e7f37244ebf6
The shell property debug.egl.trace can now be set to:
0
disables tracing
1
logs all GL calls
error
checks glGetError after every GL call, logs a stack trace on error
systrace
logs each GL call to systrace
Change-Id: I34a2a2d4e19c373fd9eaa1b0cd93e67c87378996
this simplify our EGL wrapper implementation a lot.
This wrapping is no longer needed now that we can only
support a single underlaying EGL implementation.
Change-Id: I8213df7ac69daac447f1fe6e37044b78aac4e9a9
This extension is always added to the GL_EXTENSIONS
extension string for the current GL context, regardless
of if it's supported by the h/w driver.
The extension itself will be handled by GLES_trace (eventually),
when GLES_trace is not enabled, it'll result to a no-op.
If the h/w implementation has this extension, we'll call that version
instead of our dummy version.
Change-Id: Ie5dd3387c4d45cd5ed5f03b73bda6045620a96bc
Merge commit '4eb1ad5e98c7b36f7ac4ec8c3270f9763afd107e'
* commit '4eb1ad5e98c7b36f7ac4ec8c3270f9763afd107e':
better fix for [3028370] GL get error should return a valid error if no context is bound.
it turns out that we cannot return INVALID_OPERATION from glGetError() because the
GL spec says that it must be called in a loop until it returns GL_NO_ERROR.
now, we always return 0 from GL functions called from a thread with no
context bound. This means that glGetError() will return NO_ERROR in this case,
which is better than returning a random value (which could trap the app in a loop).
if this happens in the main thread of a process, we LOG an error message once.
Change-Id: Id59620e675a890286ef62a257c02b06e0fdcaf69
glEGLImageTargetRenderbufferOES() pass the wrapped EGLImage
to the implementation, rather than the unwrapped one.
Change-Id: I149f9ed73e6ab9089110600e1db4311ba7a8c83a
Instead of using a different function pointer table for ES 1.x and ES 2.x,
we use a single one that is the union (sort|uniq) of both tables. Two
instances of this table are initialized with pointers to GL ES 1.x and GL ES 2.x
entry-points.
When a context is created, we store its version number and when it is bound to a
thread we set the approruiate table based on the stored version.
This introduce no penalty while dispatching gl calls to the right API version.
[Pending Dr No approval for MR1]
