for single library:
/vendor/lib/egl/GLES.so
for multiple libraries:
/vendor/lib/egl/EGL.so
/vendor/lib/egl/GLESv1_CM.so
/vendor/lib/egl/GLESv2.so
EGL_BOARD_CONFIG as well as egl.cfg are not needed anymore.
To facilitate the transition, the loader will also look
for the older naming scheme.
Bug: 8631636
Change-Id: Id4b113468df29bae72b323f76598229914e1c7a1
the code intended to filter out the software-renderer, but the
test as written was essentially a no-op.
the problem didn't happen most of the time because we had
updated egl.cfg to not even list the software renderer.
the test as written didn't generate a compile-time error
because String8 has a const char* cast operator; but the
end result was to compare pointers instead of the string
itself.
http://code.google.com/p/android/issues/detail?id=54606
Change-Id: I739dd1c838fbc24c5643a631fae19713a8ef1717
this allows us to enable h/w acceleration on low-end
devices while keeping memory usage down.
Bug: 6557760
Change-Id: I8af2de3038dc2579360b8b73aa452cb7a0e506a9
this is possible now that we support only a single
EGL implementation. this allows a large code simplification.
Change-Id: I7a6b9db4c5d60f4407c6061e7a68729af63d5242
from now on, the system can only have one EGL
implementation. this means the software and h/w renderer
cannot be used at the same time on a device. Of course, the
h/w renderer is always prefered; in its absence we
default to the software renderer.
Change-Id: Ib579f58055dd0ce4c4a99144131efa11c16ca3d3
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
This patch provides a framework for tracing GLES 1.0 and 2.0
functions. It is missing a lot of features, but here are the
things it accomplishes:
- Stop building the glesv2dbg library, and build the
glestrace library instead.
- Replace the hooks for glesv2dbg with the ones for glestrace.
- Add the basics for the trace library. Currently, this
traces all GL functions, but not all required data is
sent for all the functions. As a result, it will not
be possible to reconstruct the entire GL state on the
host side.
The files gltrace.pb.* and gltrace_api.* are both generated
using the tools/genapi.py script.
Change-Id: Id60a468f7278657f008bc6ea1df01f9bdfecfdd3
This patch modifies the library loaded in libEGL.so to
handle the case of GLES emulation as follows:
- if we detect that we run inside the emulator, check the
GPU emulation status through ro.kernel.qemu.gles, which
will be set to 1 if supported, or 0 otherwise.
When trying to run on an older version of the emulator,
the kernel parameter will not be defined at all.
- if GPU emulation is supported, use egl.cfg as usual.
It will contain a line like "0 0 emulation" that will
load libEGL_android.so appropriately.
- nothing is changed if we don't run inside the emulator.
NOTE: Ideally, we would modify libEGL_emulation.so to
redirect all calls to libEGL_android.so in this case.
However, this turns out to be extremely tedious to implement
(too many functions with different signatures).
As such, it is much simpler to make the check before
loading the library.
Change-Id: I9930bc168d9013cc8700feedc57b979384467c37
Send VBO related commands to client, which tracks the state.
Maintain index buffer content and vertex attrib pointer/buffer state on server.
During glDrawArrays/Elements, send user memory data to client.
Change-Id: Ia920e90479329b301ae4b5735e833eeb20293c94
Signed-off-by: David Li <davidxli@google.com>
Use debug.egl.debug_proc property to match process cmdline.
Binds to TCP:5039 and waits for client connection.
Sends function call parameters, textures and shaders using Protobuf.
Java Eclipse client plug-in is next.
Change-Id: I183b755263663f87e86dde1ad12f527d0445fd57
Signed-off-by: David Li <davidxli@google.com>
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]
we now look for a config file in /system/lib/egl/egl.cfg that describes the association of a display to a driver.
these drivers are named: /system/lib/egl/lib{[EGL|GLESv1_CM|GLESv2] | GLES}_$TAG.so
