If a PBO is bound, then the pointer argument is a relative offset from
the start of the PBO, not an absolute address.
Fixes b/17063439
Change-Id: I39629ce6c9bb3cb6bac5c9b0311287628306ddd4
(cherry picked from commit 0ad707f2f3)
Since the new TI SGX DDK 1.12 has fixed support for RGBA8888,
the workaround can be reverted. This may help with CTS issues.
Bug: 14995811
This reverts commit 6e79cb81d0.
Change-Id: Id8160ebe577d7009d2dd5eb4501ec40356a4274d
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: I35acb473cba2433b9aeb95d1b8bfbdcfadf22532
This extension hasn't been published yet, so it isn't in the public
registry. That will change before the next platform release to AOSP.
Bug: 15028495
Change-Id: Iadafe0f776b5b9be4f81c4279a89c57ae02293e4
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
Someone fixed these in the generated code, so re-generating even with
no other changes caused diffs. Better to just fix it at the source.
Bug: 15028495
Change-Id: I248f9796d4e3d904c4c0dc15be5f8de231df7285
These are left over from an early (not finished?) GL debugging
facility that morphed into GLES_trace. Most of the rest of it has
already been removed, these few pieces were still hanging aroung.
Bug: 15028495
Change-Id: Ib7c03eb8d0db30112e1b83e5262bba03006770de
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
Bug: 13927881
'twas useful and perhaps should be always enabled (please?)
but not like this, so reverting.
This reverts commit db4488565a.
Change-Id: I9a78c6d6e48342ef6ca1f2f7b5303ca47ccc6086
Bug: 13745587
Temporarily turn on callstack logging for gl_no_context() to
try and track down font cache corruption
Change-Id: I657ee85e811746441c5ce0ffe5adbfb3fb011d4c
These tests call android_createDisplaySurface() to get a
FramebufferNativeWindow that is passed to EGL. This relies on the
existence of the framebuffer HAL, which is not supported on many
recent devices.
This change adds a new "window surface" object that the tests
can use to get a window from SurfaceFlinger instead. All tests
except for the HWC tests now appear to do things.
The HWC tests don't do anything useful, but they no longer depend
on the android_createDisplaySurface() function.
Bug 13323813
Change-Id: I2cbfbacb3452fb658c29e945b0c7ae7c94c1a4ba
EGLObjectHandle.<init>(int) and int EGLObjectHandle.getHandle()
have now been deprecated and replaced with variants that take
and return java longs.
bug: 13181704
Change-Id: Ie88e591c288d6de5655364b4cd673f61cce68d7d
This will allow eglGetDisplay(int) to work on both 32-bit
and 64-bit systems when EGL_DEFAULT_DISPLAY is passed as
a parameter.
Change-Id: I0d7e9ca5410b0dd893eacc02aac40956908e4f25
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
EGL classes in frameworks/base have to be updated to support
64-bit platforms. Key changes in the EGL classes include
[x] EGLObjectHandle class - EGLObjectHandle class has two public
methods (constructor and getHandle) that assume handles are
32-bit. They have not been changed. Instead, two new hidden
methods (EGLObjectHandle(long) and getNativeHandle) have been
added.
[x] EG14 class - Two public methods eglGetDisplay and
eglCreatePbufferFromClientBuffer assume that handles are 32-bit.
They have been changed to throw unsupported operation exception
on non 32-bit machines. Two new methods eglGetDisplay(long)
and eglCreatePbufferFromClientBuffer(...long buffer..) have
been added to support 64-bit handles.
To allow the above changes in frameworks/base EGL classes,
corresponding code generation mechanism in frameworks/native has
been updated.
Change-Id: I5d0a62e10c20ccf05f610d6608b8dfb6414b5116
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Patch from synergydev with commit-id 01994c79 changed
core/jni/com_google_android_gles_jni_GLImpl.cpp in the
frameworks/base. However the corresponding code snippet
in frameworks/native was not updated. This patch addresses
the issue.
Change-Id: I89c3d88de832efc8cbbe682c8a7ff7dfbef99db3
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Patch from Takeshi Aimi with commit-id f9337377 changed
core/jni/android_opengl_EGL14.cpp in the frameworks/base.
However the corresponding code snippet in frameworks/
native was not updated. This patch addresses the issue.
Change-Id: I40bcc43d36d7ab4e0db4a73556a4f7480c7431c1
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
They were replaced with correct bindings a while back, but the
broken methods weren't hidden.
Also, pick up two changes that were made to the generated code
rather than the source.
Bug 6006380
Change-Id: Ibfe9a5f2e13e745f8d82116d1b4d8c2d025ac830
GLES_trace passes some pointers back to the host. Encode them
using int64's rather than int32's
This fix requires an update to the host tool to look at pointers
as 64 bit, and if not found, then fall back to 32 bit integers.
Change-Id: I11ff2ca51290f05913c1b9143cecee1caf015543
