UInt4 -> Float4 already existed, but not UInt -> Float.

Added the scalar conversion code and used it in the
Blitter where appropriate.

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

Only libGLESv2 was clearing all the samples of a multisample buffer.
Since all known APIs always clear all the samples, this could be
handled in the Renderer.

Bug swiftshader:77

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

By default, in D3D, R, G or B channels default to 1 when no
value is assigned to them. In OpenGL, these channels default
to 0. Added an entry to Conventions to fix this issue.

In dEQP, this fixes all R and RG types tests from:
functional.texture.format.*

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

All texture formats, except YUV or sRGB formats, now have access
to the floating point path for texture filtering. High precision
filtering can be enabled using:
glHint(GL_TEXTURE_FILTERING_HINT_CHROMIUM, GL_NICEST)

Bug swiftshader:76

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

Integer formats are: UInt32/Int32/UInt16/Int16/UInt8/Int8
The 32 bit formats required using the floating point path for precision,
while the 16 bit and 8 bit formats were going through the short integer
path. Since all formats need to be treated as Int within a 32 bit Float
in the end, this cl unifies all integer formats under the same path.

Related dEQP tests are: functional.texture.format.sized.2d.*

Bug swiftshader:76

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

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

Modified the texture coordinate computation to use floating
point operations when sampling floating point textures to
increase accuracy and remove useless type conversions.

Bug swiftshader:76

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

Our approximation for log2() linearly interpolates between powers of
two. This is not accurate enough for some use cases. Squaring the input
effectively doubles the number of piecewise linear segments.

Bug swiftshader:71

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

A new extension will be added to SwiftShader in order to allow
Chromium to trigger high precision filtering when necessary.
This extension is documented in:
extensions/CHROMIUM_texture_filtering_hint.txt

Bug swiftshader:76

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

Sanitizer tools require type information to catch undefined behavior and
other issues. This wasn't available accross libraries due to the version
script giving them hidden visibility, leading to false positives.

Bug chromium:737384

Change-Id: Iab3e25f4da3672f694e32c1c89278a3fe677d51a
Reviewed-on: https://swiftshader-review.googlesource.com/10728Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Corentin Wallez <cwallez@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

This change is effectively noop by itself, but allows the
floating point path to read all texture formats (except YUV).
This is required by the floating point path to be able to
perform higher precision filtering on all formats (except YUV).

Bug swiftshader:76

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

Visual C++ 2015 provides an actual snprintf implementation, so we
shouldn't use _snprintf, which does not guarantee null-termination.

Bug swiftshader:75

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

Frac() should always produce results in the range [0.0, 1.0), and thus
never produce a 1.0. However, the current implementation uses
x - floor(x) and this returns 1.0 for very small negative values due to
catastrophic cancellation.

Bug swiftshader:74

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

The code to compute the final RGB565 conversion is now
generated once instead of being generated 4 times.

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

Currently in debug builds swiftshader is not thread safe because of this
tracking code. This change makes it safe to create/delete objects from
multiple threads.

Change-Id: I9c8d3efc370687891b1acc786499bda02c86ad01
Reviewed-on: https://swiftshader-review.googlesource.com/10528Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Ben Vanik <benvanik@google.com>

Fixes bug swiftshader:73.

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

Fixes bug swiftshader:72.

Change-Id: I4fcc6c47ec8561150c88fea200aeb6baf9534c00
Reviewed-on: https://swiftshader-review.googlesource.com/10511Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Ben Vanik <benvanik@google.com>

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

Android now also uses OWNERS files for commit approval in Gerrit (see
b/33166666). But they don't recognize the @chromium.org accounts. We
shouldn't need them for Chromium if we just use our @google.com
accounts, so they can be removed. Also use full account names instead
of aliases.

Bug b/63147516

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

eglGetCurrentDisplay() returned a pointer to the concrete egl::Display
object, instead of the opaque identifier obtained from eglGetDisplay.
This was a regression caused by
https://swiftshader-review.googlesource.com/10188

Bug chromium:738298

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

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>