darwin: Fix test for kCGLPFAOpenGLProfile support at runtime

Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Import eglextchromium.h from Chromium.

In order to support the (currently unregistered) Chromium-specific EGL
extension eglGetSyncValuesCHROMIUM on Intel systems, we need to import
the Chromium header that defines it.  The file was downloaded from

https://chromium.googlesource.com/chromium/chromium/+/trunk/ui/gl/EGL/eglextchromium.h

It is subject to the license found at

https://chromium.googlesource.com/chromium/chromium/+/trunk/LICENSE

I have imported the header file and added the license text to the top.
The only change was to fix the include guard on the Chromium header to
change the last line from a #define to a #endif, which makes the header
actually compile.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Cc: Jamey Sharp <jamey@minilop.net>
Cc: Ian Romanick <idr@freedesktop.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
egl: Add EGL_CHROMIUM_sync_control extension.

Chromium defined a new GL extension (that isn't registered with Khronos).
We need to add an EGL extension for it, so we can migrate ChromeOS on
Intel systems to use EGL instead of GLX.

http://git.chromium.org/gitweb/?p=chromium/src/third_party/khronos.git;a=commitdiff;h=27cbfdab35c601f70aa150581ad1448d0401f447

The EGL_CHROMIUM_sync_control extension is similar to the GLX extension
OML_sync_control, but only defines one function,
eglGetSyncValuesCHROMIUM, which is equivalent to glXGetSyncValuesOML.

http://www.opengl.org/registry/specs/OML/glx_sync_control.txt

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: Jamey Sharp <jamey@minilop.net>
Cc: Ian Romanick <idr@freedesktop.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
i965/fs: Assume fragment color clamping is off when precompiling.

Modern applications frequencly use both UNORM buffers and FLOAT buffers
with color clamping disabled.  (FLOAT with clamping explicitly enabled
and SNORM buffers appear to be less common.)  We don't need to emit
saturates in the fragment shader in either of the common cases.

Mesa sets ctx->Color._ClampFragmentColor to false if all the color
buffers are UNORM.  Also, for GL_FIXED_ONLY mode (the default in
legacy OpenGL), it will be false if any FLOAT buffers are bound.
Since the common case is false, that should be our default.

Thanks to Roland Scheidegger for pointing out some faulty logic
in v1 of this patch (unnecessary code and incorrect explanations).

v2: Drop superfluous code and reword commit message.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
nv50/ir: fix s32 x s32 -> high s32 multiply logic

Retrieving the high 32 bits of a signed multiply is rather annoying. It
appears that the simplest way to do this is to compute the absolute
value of the arguments, and perform a u32 x u32 -> u64 operation. If the
arguments' signs differ, then negate the result. Since there is no u64
support in the cvt instruction, we have the perform the 2's complement
negation "by hand".

This logic can come into use by the IMUL_HI instruction (very unlikely
to be seen), as well as from constant folding of division by a constant.
Fixes dolphin's divisions by 255.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
nv50/ir: fix constant folding for OP_MUL subop HIGH

These instructions can come in either through IMUL_HI/UMUL_HI TGSI
opcodes, or from OP_DIV constant folding.

Also make sure that the constant foldings which delete the original
instruction still get counted as having done something.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
nv50,nvc0: fix 3d blits with mipmap levels

Make sure to normalize the z coordinates as well as the x/y ones when
there are mipmaps present. Fixes 3d mipmap generation, which now uses
the blit path.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "10.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
tgsi: add GS_INVOCATIONS to property names array

In commit 4be146b1, I neglected to add the new property to the strings
array. This leads to the string '(null)' to be printed instead when
converting a GS shader to text.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "10.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
meta: Refactor _mesa_meta_setup_blit_shader() to avoid duplicate shader code

Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
meta: Use gl_FragColor to output color values to all the draw buffers

_mesa_meta_setup_blit_shader() currently generates a fragment shader
which, irrespective of the number of draw buffers, writes the color
to only one 'out' variable. Current shader rely on an undefined
behavior and possibly works by chance.

From OpenGL 4.0  spec, page 256:
  "If a fragment shader writes to gl_FragColor, DrawBuffers specifies a
   set of draw buffers into which the single fragment color defined by
   gl_FragColor is written. If a fragment shader writes to gl_FragData,
   or a user-defined varying out variable, DrawBuffers specifies a set
   of draw buffers into which each of the multiple output colors defined
   by these variables are separately written. If a fragment shader writes
   to none of gl_FragColor, gl_FragData, nor any user defined varying out
   variables, the values of the fragment colors following shader execution
   are undefined, and may differ for each fragment color."

OpenGL 4.4 spec, page 463, added an additional line in this section:
  "If some, but not all user-defined output variables are written, the
   values of fragment colors corresponding to unwritten variables are
   similarly undefined."

V2: Write color output to gl_FragColor instead of writing to multiple
    'out' variables. This'll avoid recompiling the shader every time
    draw buffers count is updated.

Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
rbug: add missing pipe->blit() entrypoint

Signed-off-by: Rob Clark <robclark@freedesktop.org>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
freedreno: use OUT_RELOCW when buffer is written

These aren't buffers we ever read back from CPU, so using incorrect
reloc fxn wasn't really harming anything.  But might as well be correct.

Signed-off-by: Rob Clark <robclark@freedesktop.org>
freedreno: update generated headers

Signed-off-by: Rob Clark <robclark@freedesktop.org>
freedreno/a3xx: fix depth/stencil GMEM positioning

In cases where there was no color buf bound, there were inconsistancies
in register settings related to position of depth/stencil inside GMEM.

Signed-off-by: Rob Clark <robclark@freedesktop.org>
i965: Ask the VBO module to actually use VBOs.

Note that this covers the Begin/End rendering path, but not user vertex
arrays (so we can't drop copy_array_to_vbo_array() code).  Improves
performance of isosurf GLVERTEX|TRIANGLES by 16.7506% +/- 4.98934%
(n=20). No difference on openarena (n=10), which was why this was reverted
back in cbde2765804a4fc62bcf092230a01376aedbf2cd.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
freedreno/a3xx: fix depth/stencil gmem restore

We already multiply by bytes per pixel for this, so f3ba7611 broke
mem2gmem for depth/stencil.  Drop the now-redundant mutiply by cpp.

Signed-off-by: Rob Clark <robclark@freedesktop.org>