GLES wrappers built with clang currently result in crashes in libhwui,
UI doesn't come up.
Force gcc for the wrappers until this is investigated and fixed
properly.
Bug: 18003438
Change-Id: I24a17ec019409930883da8040fe2fb05b0fea0c5
Signed-off-by: Bernhard Rosenkraenzer <Bernhard.Rosenkranzer@linaro.org>
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>
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>
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
Fix size of vertex_t on 64-bit architectures
Fix __get_tls casts, the TLS area is a void**
Cast through uintptr_t to store integers in a pointer
Use %zu to print size_t
Change-Id: I91079ec76025237e6d2081784c5348518b0ce122
This change makes GLConsumer use the EGL_ANDROID_image_crop extension when
available on a device. The crop rectangle is passed to the EGL driver when
creating EGLImages, allowing the crop to be performed by the driver rather than
using the texture transform matrix.
Bug: 10897141
Change-Id: I63e9a5d5c85067376abc420e3639154468346311
EGL now picks the buffer format out of a small set
of formats compatible with CPU consumers instead of
using the EGL_NATIVE_VISUAL_ID.
Bug: 10194508
Change-Id: If423cd29601b7a3ace8670f4c73004132cfc4b31
If the implementation eglCreateContext failed, we called
eglGetError(), so we could check that it set the EGL error properly.
But since we'd already called this, when the app called eglGetError()
it would get EGL_SUCCESS!
Bug: 10181333
Change-Id: Ic45d3a8fcb8c4421e04844c6d2f52761790b5948
We've had the extended behavior since Android 4.3, but the extension
hadn't been ratified by Khronos yet so we couldn't add it to the
extension string.
Bug: 9681677
Change-Id: I78842316a3ab7a3f66a0ac1a4742d837de664c4c
this means they only have access to the consumer end of
the interface. we had a lot of code that assumed consumers
where holding a BufferQueue (i.e.: both ends), so most of
this change is untangling in fix that
Bug: 9265647
Change-Id: Ic2e2596ee14c7535f51bf26d9a897a0fc036d22c
While currently untested, this should allow to move the
BuffereQueue in the consumer process and have everything
work as usual.
Bug: 9265647
Change-Id: I9ca8f099f7c65b9a27b7e7a3643b46d1b58eacfc
If there are two or more buffers pending that are ready for
immediate presentation, drop all but the last one.
Any code that didn't explicitly specify timestamps for buffers
was using the default value (auto-generated "now"). As a result,
surfaceflinger would drop frames whenever more than one buffer
was queued. We now use zero as the auto-generated timestamp,
and we don't set the timestamp in eglBeginFrame().
Change-Id: I187f42d33de227cd3411ff0dcd3b9ce1961457eb
Fallout from the Flattenable change, update all its uses.
Additionnaly, fix/tighten size checks when (un)flatten()ing
things.
Removed the assumption by some flattenables (e.g.: Fence)
that the size passed to them would be exact (it can
and will be larger in some cases)
The code in Parcel is a bit complicated so that we don't
have to expose the full implementation (and also to
keep the code smallish).
Change-Id: I0bf1c8aca2a3128491b4f45510bc46667e566dde
