Some platforms don't support constructors that get called when the
shared library gets loaded. This results in the thread-local-storage
key to never be allocated. Instead we can check if it was allocated on
each use. Also prevent creating new 'current' state if it already
exists, and avoid pthreads undefined behavior.

Bug b/25629882

Change-Id: I5e2486f88185150b976d88d0144e4d13a349eb79
Reviewed-on: https://swiftshader-review.googlesource.com/10451Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

No behavior is modified in this cl. log2() was calling logarithm2()
with the wrong options, but logarithm2() currently ignores all
options, so this had no consequence. Fixing to prevent future errors.

Change-Id: I6518d9d90fc1f34cadab2de12657064b2510b463
Reviewed-on: https://swiftshader-review.googlesource.com/10429Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

The MemorySanitizer tool can't instrument JIT-compiled code, so it's
unaware that the vertex processing routine writes the clip flags before
they're being read by triangle setup. This false positive can be
silenced by zeroing the memory at allocation. For good measure, zero
out all intermediate buffers.

Bug chromium:737875

Change-Id: Ic37ff5c64cb63bbddb151744af1d7dff0a254c2d
Reviewed-on: https://swiftshader-review.googlesource.com/10431Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

We were only checking depth stencil surface height against
OUTLINE_RESOLUTION. Instead both color buffers and depth stencil
buffers should be checked against the GL implementation's limits.

Change-Id: I3784f80df4ea950760db7273185fb9312802bdd3
Reviewed-on: https://swiftshader-review.googlesource.com/10410Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

getGlobalInits() moves ownership of a unique_ptr<>, which we released
to obtain the raw pointer, but we didn't delete it afterwards. This is
fixed by keeping the unique_ptr<> and having it freed at the end of the
scope.

Bug chromium:732739

Change-Id: I4d8c9367f34790944daabc0417af08eb4b4c7c2e
Reviewed-on: https://swiftshader-review.googlesource.com/10409Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

The blitter aborts generating a Reactor routine when a less common
format is being used (causing fallback to statically compiled code). But
the intermediate Reactor and Subzero structures were not being freed. It
is fixed by deleting the global routine when the Function<> goes out of
scope and it hasn't been acquired yet.

Bug chromium:732691

Change-Id: I4904a467454e8e8d2ff0dbf64545823c9fd15802
Reviewed-on: https://swiftshader-review.googlesource.com/10408Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

eglMakeCurrent(display, EGL_NO_SURFACE, EGL_NO_SURFACE, context)
resulted in a null dereference. It should be supported and is a common
idiom for detaching the surfaces from the context before destroying
them.

Bug swiftshader:70

Change-Id: I5b4406c8d594bc5db34c51bd08371ce69bbd471b
Reviewed-on: https://swiftshader-review.googlesource.com/10389Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Change-Id: Ief18bd1e251f84128660fd559d997e0d094c7abf
Reviewed-on: https://swiftshader-review.googlesource.com/10348Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

This fixes two issues. We had a global 'blitter' instance which doesn't
get destroyed until the library us unloaded. This is reported as a
memory leak (albeit benign). Potentially worse is that the singleton was
shared between all threads, and the Routine cache isn't thread safe.

Bug chromium:732691

Change-Id: I7b90d7d2bc67b4a9f78cdf4f54a76fa2f798b7cc
Reviewed-on: https://swiftshader-review.googlesource.com/10128Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

This also removes binding an EGL surface to a 3D texture image, which
is not supported by the API and which is unreachable.

Change-Id: I4a6cd17d731c28769e976b21ac46fe855d1c7b1c
Reviewed-on: https://swiftshader-review.googlesource.com/8351Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

Change-Id: I97583d5b70bd0f9a2edf2e46943d6db58f326f68
Reviewed-on: https://swiftshader-review.googlesource.com/10328Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

It's undefined behavior when an application attempts to use a buffer
for which no data has been allocated yet, but this is trivial for us to
check for and produce a non-fatal error.

Bug chromium:736639

Change-Id: I795c22363ada1b5e325d1fb5061a9e7673609879
Reviewed-on: https://swiftshader-review.googlesource.com/10309Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Change-Id: I47fa608e8923605bd090d6216c9ccf7d5c4051e2
Reviewed-on: https://swiftshader-review.googlesource.com/10308Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

Bug swiftshader:65

Change-Id: I8454538d144ed37a56b98c46ed1e88ffdced387e
Reviewed-on: https://swiftshader-review.googlesource.com/10188Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

ANGLE and SwiftShader produce libraries with the same name, which causes
conflicts for Chrome on Mac OS when creating unstripped libraries and
dSYM debug information. Renaming them temporarily works around the build
tools issue.

Bug chromium:735920

Change-Id: Icb4f484970ec75b8c5e7e784ce37e05ee4fbc7db
Reviewed-on: https://swiftshader-review.googlesource.com/10288Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

Since N MR1, gralloc1 is newly arrived. In order to use gralloc1, the
caller should retrieve its functions via the getFunction method.
GrallocModule now supports for the gralloc0 and gralloc1 mappers both.
Also it makes FrameBufferAndroid to use common GrallocAndroid
implementation.

Bug b/62897956
Test: no errors on locking and unlocking via gralloc1
Change-Id: I1dbb5acd9a36775c642e0282b9b5017ebcec99ec
Reviewed-on: https://swiftshader-review.googlesource.com/10248Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Jaesung Chung <jaesung@google.com>

Component builds automatically set the rpath to include dependent libraries,
but with a non-component build these are assumed to be linked statically so the
rpath of where to find the libraries to collect install_name info from is
missing. Thus we set the rpath explicitly.

Related articles and documentation:
https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html
http://log.zyxar.com/blog/2012/03/10/install-name-on-os-x
https://wincent.com/wiki/@executable_path,_@load_path_and_@rpath

Bug swiftshader:68

Change-Id: I0cfe0d26fccf80ff7911846ef013d47daaeb09fd
Reviewed-on: https://swiftshader-review.googlesource.com/10228Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

Fixing Issue swiftshader:31 makes the workarounds obsolete and since
they disabled some link-time optimizations they should be reverted.

This reverts commit 628a8496.
This reverts commit 158dcfc1.
This reverts commit ad675fa1.

Bug chromium:686980
Bug chromium:735508

Change-Id: I4c4e2466fdfcddd12854b87e5a62d6ec8c823a05
Reviewed-on: https://swiftshader-review.googlesource.com/10168Reviewed-by: Nicolas Capens <capn@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Nicolas Capens <capn@google.com>

On Mac OS there is no rpath to set for the executable to locate
libraries. Instead, dylibs themselves have an install_name which is the
path where executables can load them from (added to the executable at
link time).

Bug swiftshader:68

Change-Id: Ia72eba0076ec83fc4492a5c118b4f5420d03a640
Reviewed-on: https://swiftshader-review.googlesource.com/10208Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Nicolas Capens <capn@google.com>

Change-Id: Ic8e2360c044aac47447f6a7ae7071d4e3b181678
Reviewed-on: https://swiftshader-review.googlesource.com/10148Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

Create an OpenGL ES 2.0 context and verify the renderer string. This
ensures the expected libGLESv2 get loaded and initialized correctly.
Also add unittests to the Visual Studio solution.

Change-Id: I848079215434ce1fb9a18564ce47de5b598b21d2
Reviewed-on: https://swiftshader-review.googlesource.com/10108Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

gl::Surface is now the pure abstract interface for egl::Surface, which
can be used by libGLESv2 without requiring typeinfo.

Bug chromium:732667
Bug swiftshader:31

Change-Id: I7d8a5892c5b6186541f84c3cf39e72ac1d6c613d
Reviewed-on: https://swiftshader-review.googlesource.com/10129Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

Change-Id: Ia0ad3b10fc3e2617945fd0ca763f134ef7276fa4
Reviewed-on: https://swiftshader-review.googlesource.com/10088Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

Change-Id: I07d3125d0d3b48f18b5752cdb8bd11869324bff0
Reviewed-on: https://swiftshader-review.googlesource.com/10068Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

Bug swiftshader:63
Bug swiftshader:31

Change-Id: I59d08cbc8379e2c30984b9ec0ed4d49317633ce8
Reviewed-on: https://swiftshader-review.googlesource.com/10048Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

The egl::Image destructor synchronizes with the threads accessing that image.
However, that is too late because by the time ~Image runs, ImageImplementation
has already been destructed - concurrently with the other threads running, i.e.
data race. In particular, since those threads access virtual member functions on
Image, they may end up calling the base class ones (which are pure) instead of
the derived class ones.

So make sure to synchronize in ~ImageImplementation instead.

Bug: swiftshader:62

Change-Id: I91240d1dbb45dd126c65d86f9aecf77833b4488d
Reviewed-on: https://swiftshader-review.googlesource.com/10029Reviewed-by: Nicolas Capens <capn@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Nicolas Capens <capn@google.com>

Recent versions of CMake omit adding Info.plist to the application
bundle due to an error attempting to parse a symbolic reference as a
CMake one. It is fixed by adding escape characters.
Also set CMAKE_MACOSX_RPATH to silence a warning.

Bug b/62380447

Change-Id: I6464fce7e3d4812d872343806138e44c269dd2da
Reviewed-on: https://swiftshader-review.googlesource.com/10008Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

Entry functions need to have default visibility instead of protected
visibility to allow symbol preemption during linking (i.e. when not
using dlsym() to explicitly obtain pointers to entry functions). See:
https://bugs.llvm.org//show_bug.cgi?id=30960

Bug swiftshader:64

Change-Id: Ia2d3ae8fb4faec9a75d811c643e3164bfb7d0423
Reviewed-on: https://swiftshader-review.googlesource.com/10028Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

We're already exporting the entry functions (eglGetPlatformDisplayEXT(), etc.).
Valid platform enums are defined by separate KHR_platform_* extensions.

Bug swiftshader:58

Change-Id: I1eb030f76cd800be9ecb37bad36dd004aceeb1af
Reviewed-on: https://swiftshader-review.googlesource.com/9953Reviewed-by: Nicolas Capens <capn@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Nicolas Capens <capn@google.com>

All build targets must depend on //build/config:exe_and_shlib_deps.

Bug chromium:723069
Bug swiftshader:54

Change-Id: I7aaecd681ece1ed773239a88a5c4c93a75f7cd1f
Reviewed-on: https://swiftshader-review.googlesource.com/9829Reviewed-by: Tom Anderson <thomasanderson@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

Sanitizer tools desire having the vtables of any class with non-pure
virtual methods, even when none of them are called in the current
linkage unit. Work around this by making the affected classes pure
abstract and implementing them in a derived class in the respective
library responsible for creating them.

Bug swiftshader:31

Change-Id: I40046f605731eb1cc3825c1ede2d8d9b5826d0f5
Reviewed-on: https://swiftshader-review.googlesource.com/9914Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

Sanitizer tools desire having the vtables of any class with non-pure
virtual methods, even when none of them are called in the current
linkage unit. In the case of sw::FrameBuffer, to work around this we can
make the class pure abstract by making the destructor pure virtual. Note
that the destructor still has a non-empty definition, since all non-
default destructors need a defintion, and it will get called as part of
the destructor chain.

Bug swiftshader:31

Change-Id: I7601b1a725c513ff484cd34a8965636b7f21513c
Reviewed-on: https://swiftshader-review.googlesource.com/9912Reviewed-by: Nicolas Capens <capn@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Nicolas Capens <capn@google.com>

These were already available for GLES3 and exposed as texturable
formats for GLES2 when the GL_EXT_texture_rg extension was exposed,
but it should also have enabled these formats as renderable formats.

Bug swiftshader:60

Change-Id: I598d7645b04737dae19dc88b4229fa3d7d231714
Reviewed-on: https://swiftshader-review.googlesource.com/9990Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

This is required by chromium tests. There is another cl
(https://swiftshader-review.googlesource.com/9952) which
will change internal uses of OUTLINE_RESOLUTION to adapt
to the rendertarget's height which will reduce the memory
usage increase caused by the current cl.

Change-Id: Iaabbbff07db9c3251ddf49cc534a1a91bab4e5f2
Reviewed-on: https://swiftshader-review.googlesource.com/9988Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

In EGLQueryString, it is now valid to query EGL_EXTENSIONS
with a display set to EGL_NO_DISPLAY, so the function
should proceed without returning an error in these cases.

Change-Id: I76ccd4f98f3d4180268b6b85b5b04a19bea59977
Reviewed-on: https://swiftshader-review.googlesource.com/9948Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

The extension was already implemented for GLES3, but simply required
a few cases to be added for support in GLES2.

Note that this extension is required to process filters using masks
with GLES2 in skia.

Change-Id: I196901ca19a4fd40a5a1ebd87040519b0de6eb5f
Reviewed-on: https://swiftshader-review.googlesource.com/9949Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

Change-Id: I60096b0e70049d490ba8bd3c7514f19e8de0017b
Reviewed-on: https://swiftshader-review.googlesource.com/9951Tested-by: Nicolas Capens <capn@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>

Bug chromium:729532

Change-Id: Ie10edb39fdc61557f394cddca981f55e89b63cc4
Reviewed-on: https://swiftshader-review.googlesource.com/9950Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>

Recently, ES3 specific getIntegerv queries were removed from ES2.
Unfortunately, GL_MAX_COLOR_ATTACHMENTS was moved to the ES3
section, but was still supposed to be in the ES2 section,
since the GL_EXT_draw_buffers exposes it.

Change-Id: I2272ccf282558e10ee6cfb1be9d124cc59df14fa
Reviewed-on: https://swiftshader-review.googlesource.com/9911Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Bug b/38514001

Change-Id: I6d2d891545840beee54db95a7456b6ede293d0eb
Reviewed-on: https://swiftshader-review.googlesource.com/9908Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <capn@google.com>
Tested-by: Nicolas Capens <capn@google.com>