Wrapper functions were broken on builds that forced -fno-omit-frame-pointer flag.
Change-Id: I5a80f9587fb3db821b4156af56acda59a0b4579b
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Yong Yao <yong.yao@intel.com>
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>
Enable ES 3.1 generation in glgen.py, and regenerate everything to add
support for that as well as these new extensions in the registry:
- EXT_copy_image
- EXT_draw_buffers_indexed
- EXT_geometry_shader
- EXT_gpu_shader5
- EXT_primitive_bounding_box
- EXT_shader_implicit_conversions
- EXT_shader_io_blocks
- EXT_tessellation_shader
- EXT_texture_border_clamp
- EXT_texture_buffer
- EXT_texture_cube_map_array
- EXT_texture_view
Bug: 15028495
Change-Id: I3f45a7ef5367c70e54ce6b36a8c030ae11033434
Import GLES headers from Khronos SVN r26322:
https://cvs.khronos.org/svn/repos/registry/trunk/public/gles/api
There are many non-functional whitespace and parameter name changes
included here. These were introduced upstream when converting from the
old .spec registry to the new XML registry.
There are also some new extensions added. Unfortunately there isn't a
version of the XML that matches the headers the previous versions of
the *.in files were generated from, so I can't separate out the
non-functional changes from the new extensions (other than temporarily
hacking them out of the XML). See below for a list.
Finally, I had to hack the official glext.h. Khronos hasn't updated
the official GLES1 headers since switching to the XML registry, and
there is one critical difference: a "const void**" parameter in the
official header is "const void* const*" in the registry. I changed the
header to avoid build errors with code generated from the registry.
Dependencies on the *.in files required manually updating some
GLES_trace/ files as well:
- gltrace_api.{h,cpp} must be manually re-generated using
tools/genapi.py.
- New GL prototypes must be manually added to gltrace.proto.
- gltrace.pb.{h,cpp} must be regenerated using aprotoc (see dev.make)
New GLES extensions in libs/GLES_CM/glext_api.in:
- GL_OES_byte_coordinates
- GL_EXT_map_buffer_range
- GL_APPLE_copy_texture_levels
- GL_APPLE_sync
New GLES2 extensions in libs/GLES2/gl2ext_api.in:
- GL_KHR_blend_equation_advanced
- GL_KHR_debug
- GL_OES_sample_shading
- GL_OES_texture_storage_multisample_2d_array
- GL_EXT_disjoint_timer_query
- GL_EXT_draw_buffers
- GL_EXT_draw_instanced
- GL_EXT_instanced_arrays
- GL_EXT_map_buffer_range
- GL_EXT_map_buffer_range
- GL_EXT_multiview_draw_buffers
- GL_EXT_separate_shader_objects
- GL_ANGLE_instanced_arrays
- GL_ANGLE_translated_shader_source
- GL_APPLE_copy_texture_levels
- GL_APPLE_sync
- GL_INTEL_performance_query
- GL_NV_blend_equation_advanced
- GL_NV_copy_buffer
- GL_NV_draw_instanced
- GL_NV_framebuffer_blit
- GL_NV_framebuffer_multisample
- GL_NV_instanced_arrays
- GL_NV_non_square_matrices
Bug: 15028495
Change-Id: I902517c23354e14f9c63b1584db286d682315bb5
There are many non-functional whitespace and parameter name changes
included here. These were introduced upstream when converting from the
old .spec registry to the new XML registry.
There are also some new extensions added. Unfortunately there isn't a
version of the XML that matches the headers the previous versions of
the *.in files were generated from, so I can't separate out the
non-functional changes from the new extensions (other than temporarily
hacking them out of the XML). See below.
Finally, I had to hack the official glext.h. Khronos hasn't updated
the official GLES1 headers since switching to the XML registry, and
there is one critical difference: a "const void**" parameter in the
official header is "const void* const*" in the registry. I changed the
header to avoid build errors with code generated from the registry.
Dependencies on the *.in files required manually updating some
GLES_trace/ files as well:
- gltrace_api.{h,cpp} must be manually re-generated using
tools/genapi.py.
- New GL prototypes must be manually added to gltrace.proto.
- gltrace.pb.{h,cpp} must be regenerated using aprotoc (see dev.make)
New GLES extensions in libs/GLES_CM/glext_api.in:
- GL_OES_byte_coordinates
- GL_EXT_map_buffer_range
- GL_APPLE_copy_texture_levels
- GL_APPLE_sync
New GLES2 extensions in libs/GLES2/gl2ext_api.in:
- GL_KHR_blend_equation_advanced
- GL_KHR_debug
- GL_OES_sample_shading
- GL_OES_texture_storage_multisample_2d_array
- GL_EXT_disjoint_timer_query
- GL_EXT_draw_buffers
- GL_EXT_draw_instanced
- GL_EXT_instanced_arrays
- GL_EXT_map_buffer_range
- GL_EXT_map_buffer_range
- GL_EXT_multiview_draw_buffers
- GL_EXT_separate_shader_objects
- GL_ANGLE_instanced_arrays
- GL_ANGLE_translated_shader_source
- GL_APPLE_copy_texture_levels
- GL_APPLE_sync
- GL_INTEL_performance_query
- GL_NV_blend_equation_advanced
- GL_NV_copy_buffer
- GL_NV_draw_instanced
- GL_NV_framebuffer_blit
- GL_NV_framebuffer_multisample
- GL_NV_instanced_arrays
- GL_NV_non_square_matrices
Bug: 15028495
Change-Id: Ib3fa700a146adf7f1487a93e459b1e6df0dcdc42
We weren't using gl2_api.in, since gl3_api.in was a superset. And
gl3ext_api.in was empty, and Khronos has decided to keep it that way
(any GLES2/3/... extensions will be in gl2ext.h).
Since libGLES2.so will have all future backwards-compatible GLES APIs,
it makes sense to just use gl2_api.in and gl2ext_api.in to build its
contents. This changes renames gl3_api.in to gl2_api.in and updates
uses of it, and removes gl3ext_api.in and references.
Bug: 15028495
Change-Id: I0745eda27ec91ee625f03e957e4fdb22035dd781
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
This change has been made in Khronos SVN for GLES2 already, however it
is mildly controversial and discussion is on-going.
This change is necessary for Android because otherwise applications
cannot include both GLES2/gl2.h and GLES3/gl3.h as the glShaderSource()
prototype mismatches. Native programs may include framework headers
(which now include GLES3 headers only) but already have included GLES2
headers, creating an incompatibility.
Change-Id: I70a4075e079ee063e76cef5a227abb0ae70aebb4
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]
