mesa/main: Make get_hash.c values constant.

Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 53468dee0359a4ec3c9edd334656de0ddc47e477)
mesa: Make glGetIntegerv(GL_*_ARRAY_SIZE) return GL_BGRA.

Same as b026b6bbfe3f15c8a7296ac107dc3d31f74e401e, but
COLOR_ARRAY_SIZE/SECONDARY_COLOR_ARRAY_SIZE.

Ideally we wouldn't munge the incoming state, so that we wouldn't need
to unmunge it back on glGet*.  But the array size state is copied and
referred in many places, many of which couldn't take an GLenum like
GL_BGRA instead of a plain integer.  So just hack around on glGet*,
to ensure there is no risk of introducing regressions elsewhere.

This bug causes problems to Apitrace, resulting in wrong traces.  See
https://github.com/apitrace/apitrace/issues/261 for details.

Tested with piglit arb_vertex_array_bgra-get, which was created for this
purpose.

Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit e3e13d6b857b3083e2553457fe30ddfd4eddead4)
mesa/main: Prevent sefgault on glGetIntegerv(GL_ATOMIC_COUNTER_BUFFER_BINDING).

A recent ApiTrace change, that tries to dump more buffer state
causes Mesa from my distro (10.1.4) to segfaults here.

I haven't actually confirm this fixes it (I can't repro on master),
but it seems a good idea to be defensive here anyway.

Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit eb58aa9cf015e79a0fcf2e088676e6aa1d5dabce)
configure: error out when building opencl without LLVM

Cc: Tom Stellard <thomas.stellard@amd.com>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
(cherry picked from commit 93257a56b5b585e79e4ba9f95b38f5bd718e3959)
add megadriver_stub_FILES

So that android part can also use $(megadriver_stub_FILES)

Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Adrian Negreanu <adrian.m.negreanu@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
(cherry picked from commit eb3f80dbba3c7e6e33d9b98a6b88761550fddb97)
android: adapt to the megadriver mechanism

Fixes linker error:
  ld:
  .../libmesa_dri_common_intermediates/libmesa_dri_common.a(dri_util.o):
    in function globalDriverAPI:dri_util.c(.data.rel+0x0): error:
    undefined reference to 'driDriverAPI'

As an example, you can see that mesa_dri_drivers
also uses common/libmegadriver_stub (src/mesa/drivers/dri/Makefile.am)

The _stub part might be confusing, but
it actually provides the dri-driver shared lib constructor,
megadriver_stub_init, which will later on load the real
platform dependent part and call
l __driDriverGetExtensions_<platform>

Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Adrian Negreanu <adrian.m.negreanu@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
(cherry picked from commit aba0f152be5bbc9fa844a53014bde7c02f056e4f)
android: add libloader to libGLES_mesa and libmesa_egl_dri2

This fixes
  src/egl/drivers/dri2/platform_android.c:664: error: undefined reference to 'loader_set_logger'
  src/egl/drivers/dri2/platform_android.c:678: error: undefined reference to 'loader_get_driver_for_fd'

Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Adrian Negreanu <adrian.m.negreanu@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
(cherry picked from commit a49ebfab1d093475610e8504cf3400c054e300c0)
android: add src/gallium/auxiliary as include path for libmesa_dricore

This fixes:
In file included from
/home/adrian/workspace/mesa/mesa-master.git/src/mesa/vbo/vbo_exec_api.c:445:0:
/home/adrian/workspace/mesa/mesa-master.git/src/mesa/vbo/vbo_attrib_tmp.h:28:38:
fatal error: util/u_format_r11g11b10f.h: No such file or directory

Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Adrian Negreanu <adrian.m.negreanu@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
(cherry picked from commit 0048483f73c0cdd6015f1f8a65b9e9d0fce4e93b)
android, egl: add correct drm include for libmesa_egl_dri2

Fixes:
  src/egl/drivers/dri2/platform_android.c:38:
  include/GL/internal/dri_interface.h:51:17:
    fatal error: drm.h: No such file or directory

Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Adrian Negreanu <adrian.m.negreanu@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
(cherry picked from commit 4dc5545eff9f8fbf4e3d80bad5421821434605f9)
android, mesa_gen_matypes: pull in timespec POSIX definition

This fixes:
  include/c11/threads_posix.h: In function 'cnd_timedwait':
  include/c11/threads_posix.h:140:21: error: storage size of 'abs_time' isn't known

Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Adrian Negreanu <adrian.m.negreanu@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
(cherry picked from commit 6eb3888c863dfef249c3910dbe3fe1f2b251db05)
android, dricore: undefined reference to _mesa_streaming_load_memcpy

_mesa_streaming_load_memcpy is defined in main/streaming-load-memcpy.c
I'm adding it to the dricore lib

Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Adrian Negreanu <adrian.m.negreanu@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
(cherry picked from commit 357a8b6f334da9e78d9cadebb8d729a0d1d38c3d)
configure: Only check for OpenCL without LLVM when the latter is certain

LLVM is enabled by default for some architectures, but the test was failing
before that.

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>

Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 2d399bb1837e01856c8e489aa5ec439ce9a1fdbc)
i965: Set the fast clear color value for texture surfaces

When a multisampled texture is used for sampling the fast clear color value
needs to be programmed into the surface state. This was being left as all
zeroes so if the surface was cleared to a value other than black then it
wouldn't work properly. This doesn't matter for single-sample textures because
in that case the MCS buffer is resolved before it is used as a texture source.

https://bugs.freedesktop.org/show_bug.cgi?id=79729

Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 765efeef883cdbb86e052acd887e0c3c0e39b732)
mesa: Remove glClear optimization based on drawable size

A drawable size of 0x0 means that we don't have buffers for a drawable yet,
not that we have a zero-sized buffer.  Core mesa shouldn't be optimizing out
drawing based on buffer size, since the draw call could be what triggers
the driver to go and get buffers.  As discussed in the referenced bug report,
the optimization was added as part of a scatter-shot attempt to fix a
different problem.  There's no other example in mesa core of using the
buffer size in this way.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74005
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 7928b946adbcbbb835c0080967bbb538f6bd35dc)
clover: Prevent Clang from printing number of errors and warnings to stderr.

https://bugs.freedesktop.org/show_bug.cgi?id=78581

CC: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 0cc391f0136c1532701a04c9b2f3a4cc49f25e8c)
clover: Don't use llvm's global context

An LLVMContext should only be accessed by a single and using the global
context was causing crashes in multi-threaded environments.  Now we use
a separate context for each compile.

Reviewed-by: Francisco Jerez <currojerez@riseup.net>

CC: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 4aa128a123d7285677a527e724809339f15d33a7)
mesa: Copy Geom.UsesEndPrimitive when cloning a geometry program.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 96a95f48eaf8af2c6ace51531bdd5bfbcf71165e)
glx: Don't crash on swap event for a Window (non-GLXWindow)

Prior to GLX 1.3 there was the glxMakeCurrent() function that took a
single drawable handle. The Drawable could be either a bare XID for a
Window or an XID for a glxpixmap.

GLX 1.3 added glxMakeContextCurrent that takes 2 handles: one for
reading, one for writing. Nowadays the old glxMakeCurrent call is
implemented as a call to glxMakeContextCurrent with the single handle
duplicated.

Because of this it is allowed to use a plain-old Window ID as an
argument to glxMakeContextCurrent, although nobody really documents this
sort of thing. The manpage for the NEW call specifies the arguments as
GLXPixmaps, but the actual code accepts Window XIDs too, and handles
them correctly.

Similarly, the glxSelectEvents function can also take a bare Window XID.

The "piglit" tests all use GLXWindows and/or GLXPixmaps. You never
tested swap events with a bare Window XID. That is what my app was
doing.

The swap_events code worked with Window XIDs in mesa 7.x.y. The new code
added in versions 8, 9, and 10 assumes that all buffer swap events have
a GLXPixmap associated with them. Because of the historical quirks
above, this is not true. Swap events for bare Window XIDs do NOT have a
glxpixmap resulting in a segfault.

Any app that uses the old school glxMakeCurrent call with a Window XID
while trying to use swap_events will crash when the libs try to lookup
the nonexistent GLXPixmap associated with the incoming swap event.

I believe that the people who wrote the spec overlooked this, because
the "sbc" field comes from the OML_sync extension that is defined in
terms of glxpixmaps only.

v2 (idr): Formatting changes.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54372
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 86bd2196b4ccec50443e99e6c8bf1659e1df9f37)