nouveau: force luminance clear colors to have the same g/b values as r

Fixes the LUMINANCE_ALPHA formats of fbo-clear-formats piglit test.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>

i965: Enable INTDIV in SIMD16 mode.

All we need to do is decompose this to two SIMD8 instructions, like we
do in many other cases.  We even already have code for that.

I apparently just botched this last time I tried, and it was easy.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>

i965/fs: Drop "do dual source blending" generator parameter.

When dual source blending, the visitor already stores a flag in
brw_wm_prog_data (dual_src_blend) for the state upload code to use.
The generator also receives this, so there's no need to pass an
additional flag.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>

mesa/texstore: Don't use the _mesa_swizzle_and_convert if we need transfer ops

The _mesa_swizzle_and_convert path can't do transfer ops, so we should bail
if they're needed.

Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>

docs: update ARB_vertex_attrib_64bit status

I started this as well on top of my fp64 stuff.

Signed-off-by: Dave Airlie <airlied@redhat.com>

docs/GL3.txt: add GLES 3.1 section

This just cherry-pick the extensions into a list for GLES 3.1

I'm not actually sure if this list if complete or correct, maybe someone
else can tell me what I missed, and I'm not 100% sure on multi_draw_indirect.

Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

hud: don't overrun malloced arrays

==17630== Invalid read of size 4
==17630==    at 0x400AE10: memcpy (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==17630==    by 0x49024A2: u_upload_data (u_upload_mgr.c:253)
==17630==    by 0x49050E1: u_vbuf_draw_vbo (u_vbuf.c:980)
==17630==    by 0x487DE29: cso_draw_vbo (cso_context.c:1425)
==17630==    by 0x487DEA0: cso_draw_arrays (cso_context.c:1445)
==17630==    by 0x48A3B0E: hud_draw_colored_prims.constprop.6 (hud_context.c:123)
==17630==    by 0x48A4810: hud_draw (hud_context.c:266)
==17630==    by 0x48763F7: dri_flush (dri_drawable.c:483)
==17630==    by 0x4057510: dri2Flush.constprop.4 (dri2_glx.c:559)
==17630==    by 0x405789E: dri2SwapBuffers (dri2_glx.c:851)
==17630==    by 0x402C531: glXSwapBuffers (glxcmds.c:842)
==17630==    by 0x8049716: ??? (in /usr/bin/glxgears)
==17630==  Address 0x4426b2c is 4 bytes after a block of size 1,008 alloc'd
==17630==    at 0x4006B11: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==17630==    by 0x48A4CE7: hud_pane_add_graph (hud_context.c:625)
==17630==    by 0x48A68F0: hud_pipe_query_install (hud_driver_query.c:175)
==17630==    by 0x48A6A30: hud_driver_query_install (hud_driver_query.c:207)
==17630==    by 0x48A5835: hud_create (hud_context.c:791)
==17630==    by 0x48756CB: dri_create_context (dri_context.c:165)
==17630==    by 0x4871CD4: driCreateContextAttribs (dri_util.c:435)
==17630==    by 0x4871E06: driCreateNewContext (dri_util.c:464)
==17630==    by 0x4056A22: dri2_create_context (dri2_glx.c:223)
==17630==    by 0x402CF68: CreateContext (glxcmds.c:299)
==17630==    by 0x402D265: glXCreateContext (glxcmds.c:430)
==17630==    by 0x804B136: ??? (in /usr/bin/glxgears)

This is due to second vertex element being specified, and the upload
tries to fetch over the end. However the pane rendering only requires
a single vertex element, so specify only one.

Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

mesa: fix texstore with GL_COLOR_INDEX data

This got broken by 3dbf5bf6571e0c9d3e4febce01dea82be190d9d2.
GL_COLOR_INDEX data is still supported (in legacy contexts), but the new
texstore_swizzle path cannot handle it (and didn't detect this).
Unfortunately there's no piglit test trying to specify textures with a
GL_COLOR_INDEX source format, and I don't really understand how all the color
map stuff which is used by this works, but this caused conform failures
(with a reported mesa implementation error when trying to figure out the color
mapping).

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>

winsys/radeon: fix hawaii accel_working2 comment

accel_working2 returns 3 if the new firmware is used.

The comment wasn't updated in v3 of commit:
36771dc winsys/radeon: fix nop packet padding for hawaii

Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

r300g: Fix bug in build_loop_info()/compiler v2

Fixes piglit glean "do-loop with continue and break" on RS690

It's based on Tom Stellard patch and improved to handle CMP instruction.

[v2] handle CMP instruction

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: David Heidelberger <david.heidelberger@ixit.cz>

clover: Flush the command queue in clReleaseCommandQueue()

This is required by the spec.

Reviewed-by: Francisco Jerez <currojerez@riseup.net>
CC: "10.2" <mesa-stable@lists.freedesktop.org>

radeonsi/compute: Stop leaking the input buffer

We were leaking the input buffer used for kernel arguments and since
we were allocating it using si_upload_const_buffer() we were leaking
1 MB per kernel invocation.

CC: "10.2" <mesa-stable@lists.freedesktop.org>

radeonsi/compute: Whitespace fixes

CC: "10.2" <mesa-stable@lists.freedesktop.org>

radeonsi/compute: Call si_pm4_free_state() after emitting compute state

This will decrement the reference count for buffers referenced in the
command stream will prevent us from leaking them.

CC: "10.2" <mesa-stable@lists.freedesktop.org>

radeonsi/compute: Update reference counts for buffers in si_set_global_binding()

CC: "10.2" <mesa-stable@lists.freedesktop.org>

radeon/compute: Report a value for PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE

CC: "10.2" <mesa-stable@lists.freedesktop.org>

radeon/compute: Fix reported values for MAX_GLOBAL_SIZE and MAX_MEM_ALLOC_SIZE

There is a hard limit in older kernels of 256 MB for buffer allocations,
so report this value as MAX_MEM_ALLOC_SIZE and adjust MAX_GLOBAL_SIZE
to statisfy requirements of OpenCL.

CC: "10.2" <mesa-stable@lists.freedesktop.org>

ra: optimistically color only one node at a time

Before, when we encountered a situation where we had to optimistically
color a node, we would immediately give up and push all the remaining
nodes on the stack in the order of their index - which is a random, and
potentially not optimal, order. Instead, choose one node to
optimistically color in ra_select(), and then once we've optimistically
colored it, keep on going as normal in the hopes that we've opened up
more avenues for the normal select phase to make progress. In cases with
high register pressure, this helps make the order we push things on the
stack much better, and therefore increase the chance that we can allocate
successfully.

total instructions in shared programs: 4545447 -> 4545401 (-0.00%)
instructions in affected programs:     1353 -> 1307 (-3.40%)
GAINED:                                124
LOST:                                  6

Signed-off-by: Connor Abbott <connor.abbott@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

ra: don't consider nodes for spilling we don't need to

Previously, we would consider any optimistically colored nodes for
spilling. However, spilling any optimistically colored nodes below the
node that we failed to color on the stack wouldn't help us make
progress, since it wouldn't help with allowing us to find a color for
the node currently failing to get colored. Only consider nodes
which were above the failing node on the stack for spilling, which
simplifies the logic, and comment the code better so people know what's
going on here.

No shader-db changes with BRW_MAX_GRF reduced to 90 (or with the normal
number of GRF's).

Signed-off-by: Connor Abbott <connor.abbott@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

ra: make the p, q test more efficient

We can store the q total that pq_test() would've calculated in the node
itself, updating it when we add a node to the stack. This way, we only
have to walk the adjacency list when we push a node on the stack (i.e.
when the p, q test succeeds) instead of every time we do the p, q test.

No difference in shader-db run times, but I'm keeping this in because
the q total that it calculates will also be used in the next few commits.

Signed-off-by: Connor Abbott <connor.abbott@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

ra: cleanup the public API

Previously, there were 3 entrypoints into parts of the actual allocator,
and an API called ra_allocate_no_spills() that called all 3. Nobody
would ever want to call any of the 3 entrypoints by themselves, so
everybody just used ra_allocate_no_spills(). So just make them static
functions, and while we're at it rename ra_allocate_no_spills() to
ra_allocate() since there's no equivalent "with spills," because the
backend is supposed to handle spilling.

Signed-off-by: Connor Abbott <connor.abbott@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

nouveau: only try to get new storage if there are any levels

This would try to allocate 0-sized bo's when the max level was below the
base level.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>

nouveau: add emacs dir-locals file for tabs/8-space indents

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>

nvc0: increase GLSL level to 400 to enable ARB_gpu_shader5

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>

mesa/st: enable ARB_gpu_shader5 if the reported GLSL version >= 400

The ARB_gpu_shader5 extension is made up of a lot of small sub-parts.
Instead of adding PIPE_CAP's for each of these, just rely on the GLSL
version reported by the pipe driver. The remaining extensions lend
themselves naturally to being checked through a single CAP.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

android: add CleanSpec.mk

The file contains rules that are executed on incremental builds. This
way one can avoid doing a full clean and ensure that the new object
(library) is correctly build.

Inspired by the work of Chih-Wei Huang, from the Android-x86 project.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

android: megadriver_stub: prefix static libraries with libmesa_

Will make it easier on us as CleanSpec.mk comes along and improves
consistency across the Android build.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

android: loader: prefix static libraries with libmesa_*

Will make it easier on us as CleanSpec.mk comes along and improves
consistency across the Android build.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

android: dri/i9*5: remove used _INCLUDES variable

No longer needed as of last commit.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

android: drivers/dri: add $(mesa_top)/src to the includes list

Will allow us to nuke an include or two from the drivers.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

android: dri: use the installed libdrm headers

Saves us a few lines and brings us closer to the automake build.
Drop DRM_TOP as it's not longer used.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

android: gallium: use the installed libdrm headers

Saves us a few lines and brings us closer to the automake build.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

android: loader: use the installed libdrm headers

One step closer to the way we handle automake builds.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

android: egl/dri2: use the installed libdrm headers

Trying to get rid of the hardcoded dependency of DRM_TOP which
expects that mesa is localted in /external/drm. Will

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

android: dri/i915: do not build an 'empty' driver

The variable i915_C_FILES changed to i915_FILES with commit
34d4216e641 back in mesa 9.1/9.2. Yet we've missed to update the
the android build, essentially creating an dummy/empty driver that
can never work.

Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

automake: mesa: whitespace fixes

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>

mesa: guard better when building with sse4.1 optimisations

When the compiler is not capable/does not accept -msse4.1 while the target
has the instruction set we'll blow up as _mesa_streaming_load_memcpy is
going to be undefined.

To make sure that never happens, wrap the runtime cpu check+caller in an
ifdef thus do not compile that hunk of the code.

Fix the android build by enabling the optimisation and adding the define
where applicable.

v2: autoconf conditionals end with "fi" rather than endif.
v3: Wrap the definition and call to intel_miptree_{un,}map_movntdqa in
if defined(USE_SSE41). Spotted by Matt.

Cc: Matt Turner <mattst88@gmail.com>
Cc: Adrian Negreanu <adrian.m.negreanu@intel.com>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>

android: glsl: the stlport over the limited Android STL

The latter lacks various functionality used by mesa/glsl.

Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

android: drop HAL_PIXEL_FORMAT_RGBA_{5551,4444}

Upstream Android (system/core) has dropped these formats with commit
6bac41f1bf9(get rid of HAL pixelformats 5551 and 4444) yet does not
mention why.

These formats never really worked so we're safe to drop them as well.

Identical commit is available in the android-x86 external/mesa repo

    commit 06a2d36edcd1e2247440e5800e6bf3028f37aee6
    Author: Chih-Wei Huang <cwhuang@linux.org.tw>
    Date:   Wed Sep 25 01:16:57 2013 +0800

        android: get rid of HAL pixelformats 5551 and 4444

Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

android: gallium/auxiliary: drop log2/log2f redefitions

Recent versions of bionic has picked up support for these functions,
leading to build issues due to the redefition of the symbols.

Note: wrapping things in #ifdef does not cut it :\

Identical patch is available in chromium, android-x86 and perhaps other
projects.

    commit 66c1c789ce3407472de9ed620c9f815639058835
    Author: rmcilroy@chromium.org
    Date:   Wed Apr 02 10:59:34 2014 +0000

        Porting to x64 Android. Remove redefinitions of log2 and log2f.

        BUG=
        R=kbr@chromium.org

        Review URL: https://codereview.chromium.org/216773005

    commit 9cc0a0d2b0499556680b182888af86f29d4ec30b
    Author: Chih-Wei Huang <cwhuang@linux.org.tw>
    Date:   Sun Jul 21 23:04:19 2013 +0800

        android: remove log2, log2f

        The functions are already defined in the latest bionic.

Cc: Chia-I Wu <olvaffe@gmail.com>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Acked-by: Chia-I Wu <olvaffe@gmail.com>

android: targets/egl-static: add correct include for DRM headers

Android build never really installs the headers, as such we need to
explicitly add their location in the source tree otherwise it will
fail to find them.

v2: Android now installs the headers, so let's use that ;)

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

scons: group state-trackers' and targets' scons

Both share the identical dependencies, as such we can simplify
the scons script.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

android: reorder gallium SUBDIRS

To be closer to its automake counterpart.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

automake: handle gallium SUBDIRs in gallium/Makefile

Considering the way we've been consolidating things it makes
sense to add the final two (aux and tests) in here.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>

automake: compact gallium/target/Makefile into gallium/Makefile

Yet another makefile less to worry about.

v2: Add state_trackers and targets on a single SUBDIRS line.
Requested by Matt.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>

automake: merge gallium/state_trackers/Makefile into gallium/Makefile

One makefile less, with the potential of further compacting the
automake build.

v2: Rebase on top of vc4 changes.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>

automake: compact gallium/drivers and gallium/winsys makefiles

Rather than having two separate almost empty and identical makefiles,
compact them thus improving the configure and build time.
Additionally this makes the automake build symmetrical to the scons
and android one.

v2: Rebase on top of vc4, compact drivers + winsys on a single line.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>

android: egl/main: add/enable freedreno

For all everyone willing to give the freedreno driver
a go they can now build it under Android.

Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Cc: Rob Clark <robclark@freedesktop.org>
Cc: freedreno@lists.freedesktop.org
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

android: gallium/freedreno: add preliminary build

For all the people interested in testing the freedreno driver on
their Android devices. The next commit will hook these up within
the libEGL driver (via the gallium-egl backend).

There may be some rough edges but those can be sorted when a
willing builder/tester comes along.

v2:
 - s/freefreno/freedreno/. Spotted by Matt Turner.
 - Use the installed libdrm headers.

Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Cc: Rob Clark <robclark@freedesktop.org>
Cc: freedreno@lists.freedesktop.org
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

automake: gallium/freedreno: drop spurious include dirs

Rather than including two extra folders only for two headers,
just prefix the headers and be done with it.

Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Cc: Rob Clark <robclark@freedesktop.org>
Cc: freedreno@lists.freedesktop.org
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>

android: egl/main: resolve radeon linking issues

 - link against libdrm_radeon
 - link the r600 driver against libstlport
 - linkin the newly added libmesa_pipe_radeon library
required by r600 and radeonsi drivers

v2: Include pipe_radeon after pipe_r600/radeonsi.

Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
[Emil Velikov] Split up and add commit message.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

android: gallium/radeon: attempt to fix the android build

 - include the correct folders
 - add a new buildscript for the common radeon folder

v2: Use the installed libdrm headers over the DRM_TOP ones.

Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
[Emil Velikov] Split up and add commit message.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

android: egl/main: fixup the nouveau build

For a while the nouveau pipe driver has been a static library
and it has been using STL for even longer.
Correct add the link and cleanup the gallium_DRIVERS.

Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

android: gallium/nouveau: fix include folders, link against libstlport

nouveau uses STL for a while now thus we need to include
external/stlport/libstlport.mk in order to get the build
at least partially working.

v2: Use the installed libdrm headers over the DRM_TOP ones.

Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

egl/main: Bring in the Makefile.sources

Rather than having the sources list duplicated across all three
build systems, define it once and use it whenever needed.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>

nvc0: add BPTC format support

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>

mesa/st: add BPTC formats, expose ARB_texture_compression_bptc

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>

softpipe,llvmpipe: mark BPTC formats as unsupported

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>

gallium: add basic support for BPTC formats

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>

docs: add GL4.5 section

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>

configure.ac: drop enable_dri check in gallium_gbm

A while back we've mandated that gbm requires enable_dri,
thus this check is no longer required.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

configure.ac: bail out if building gallium_gbm without gallium_egl

The former is the only user of the latter. As such building gbm
without egl makes little to no sense.

Cc: "10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

st/dri: define GALLIUM_SOFTPIPE when building kms_swrast

To avoid unresolved symbols in the DRI modules with earlier commit we
wrapped the innards of dri_kms_init_screen() in a
DRI_TARGET/GALLIUM_SOFTPIPE ifdef.

At the same time we forgot to adds the defines to the st/dri build
systems, breaking kms_swrast and gnome-continuous.

Drop the DRI_TARGET define, we're already in st/DRI.

Reported-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reported-by: Vadim Rutkovsky <vrutkovs@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

configure: Fix --enable-XX-bit flags by moving LT_INIT where it should

Moving LT_INIT after setting completely (AM_)C(XX)FLAGS and LDFLAGS.
LT_INIT needs them as they are expected to be used all along
the compilation when the macro runs its tests to determine among other
things the host type.

For info, see http://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50754
Signed-off-by: Alexandre Demers <alexandre.f.demers@gmail.com>
Tested-by: Tapani Palli <lemody@gmail.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>

c11/threads: correct assertion

We should assert when either the function or the flag pointer
is null or we'll end up with a null reference a few lines later.

Currently unused by mesa thus it has gone unnoticed.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

docs: now distributing the GL/glcorearb.h header

Reviewed-by: Matt Turner <mattst88@gmail.com>

mesa: pull Khronos glcorearb.h header into include/GL/

Apps that only want to use core functionality should #include this
header.  This version covers everything up to OpenGL 4.5.

Reviewed-by: Matt Turner <mattst88@gmail.com>

vc4: Drop the dump_fbo() routine.

Now that eglkms is working, and some tests are working under
PIGLIT_PLATFORM=gbm, I don't think I need this any more.

vc4: Claim the GL 2.1 minimum for 3D textures.

We don't actually do them (or even fake them) currently, but it does get
us a bunch of unrelated glean glsl1 tests passing, which previously would
error out due to glean assuming the minimums on a 3D texture that 2 of the
subtests use.

vc4: Declare what vertex formats we actually support.

We will support more than this eventually, but for now this makes u_vbuf
format-convert a few things (32-bit snorm and scaled, doubles) for us.

vc4: Stash some debug code for format support checks.

This can be useful for looking at context init setup and texture format
choices, and there's no reason for the silly retval computation we do if
you're not going to have this code (mostly from freedreno) around.

vc4: Texture format support has nothing to do with VBO format support.

This was inherited from freedreno, but doesn't apply to us.

vc4: Fix off-by-one in texture maximum levels.

It's 2048x2048 that's the max, not 1024x1024.

vc4: Add support for the FLR opcode.

i965: Delete the Gen8 code generators.

We now use the brw_eu_emit.c code instead.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Matt Turner <mattst88@gmail.com>

i965: Never use the Gen8 code generators.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Matt Turner <mattst88@gmail.com>

i965: Switch to the EU emit layer for code generation on Broadwell.

Everything should be in place to unify code generation between Gen4-7
and Gen8+.  We should be able to drop the Gen8 generators at this point.

However, leave them hooked up for a brief moment, for testing and
comparison purposes.  Set GEN8=1 to use the old Gen8+ code generator
paths.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Matt Turner <mattst88@gmail.com>

i965: Retype atomics to UD in Gen8 code generation.

Kind of a moot point since we're deleting Gen8 code generation, but
this at least helps make it match the Gen4-7 code.  It's probably more
reasonable than using float.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Matt Turner <mattst88@gmail.com>

i965/vp: Use the sampler for pull constant loads on Gen7/7.5.

This improves performance in Trine 2 at 1280x720 (windowed) on "Very
High" settings by 30% (in the interactive menu) to 45% (in the forest
by the giant frog) on Haswell GT3e.

It also now generates the same assembly on Gen7 as it does on Gen8,
which always used the sampler for both types.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Matt Turner <mattst88@gmail.com>

i965/vec4: Drop gen <= 7 assertion in pull constant load handling.

I don't see any reason for this to exist.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Matt Turner <mattst88@gmail.com>

i965/eu: Set src0 file to IMM on Gen8+ flow control instructions.

According to the documentation, we need to set the source 0 register
type to IMM for flow control instructinos that have both JIP and UIP.
Out of paranoia, just make all flow control instructions use IMM;
there's no benefit to using ARF anyway, and it could trouble that's
difficult to diagnose.

See commit 9584959123b0453cf5313722357e3abb9f736aa7, which did the
analogous change in the gen8_generator code.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Matt Turner <mattst88@gmail.com>

i965/eu: Refactor brw_WHILE to share a bit more code on Gen6+.

We're going to add a Gen8+ case shortly, which would need to duplicate
this code again.  Instead, share it.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Matt Turner <mattst88@gmail.com>

i965/eu: Emulate F32TO16 and F16TO32 on Broadwell.

When we combine the Gen4-7 and Gen8+ generators, we'll need to handle
half float packing/unpacking functions somehow.  The Gen8+ generator
code today just emulates the behavior of the Gen7 F32TO16/F16TO32
instructions, including the align16 mode bugs.

Rather than messing with fs_generator/vec4_generator, I decided to just
emulate the instructions at the brw_eu_emit.c layer.

v2: Change gen >= 7 asserts to gen == 7 (suggested by Chris Forbes).
    Fix regressions on Haswell in VS tests due to type assertions.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Matt Turner <mattst88@gmail.com>

i965/vec4: Port Gen8 SET_VERTEX_COUNT handling to vec4_generator.

Broadwell requires the number of vertices written by the geometry shader
to be specified in a separate register, as part of the terminating
message's payload.

This also means GS_OPCODE_THREAD_END needs to increment mlen.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Matt Turner <mattst88@gmail.com>

i965/vec4: Switch to MOV, not OR, for GS_OPCODE_THREAD_END on Gen8.

Either should work.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Matt Turner <mattst88@gmail.com>

i965/vec4: Use MOV, not OR, to set URB write channel mask bits.

g0.5 has nothing of value to contribute to m0.5.  In both the VS and GS
payload, g0.5 contains the scratch space pointer - which is definitely
not of any use.  The GS payload also contains FFTID, but the URB write
message header doesn't want FFTID.

The only reason I used OR was because Eric originally requested it.
On Broadwell, I used MOV, and that's worked out fine.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Matt Turner <mattst88@gmail.com>

i965/fs: Don't set flag_subreg_nr = 1 on predicated FB write setup.

On Haswell, we implement "discard" via predicated SEND messages, using
f0.1 instead of f0.0.  To accomplish this, we set inst->flag_subreg to 1
on the FS_OPCODE_FB_WRITE.

Most instructions using fs_inst::flag_subreg expand to a single assembly
instruction.  However, FS_OPCODE_FB_WRITE can generate several MOVs for
setting up header information.  We don't want to set flag_subreg on
those, so override the default state back to 0.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>

i965/vec4: Respect ir->force_writemask_all in Gen8 code generation.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Cc: "10.2" <mesa-stable@lists.freedesktop.org>

i965/vec4: Set NoMask for GS_OPCODE_SET_VERTEX_COUNT on Gen8+.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Cc: "10.2" <mesa-stable@lists.freedesktop.org>

gallium/r300: Fix a link error in the tests

The link error occurs because the static libraries are linked in the wrong
order.  This fixes it.

Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82483
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>

i965: Return NONE from brw_swap_cmod on unknown input.

Comparing ~0u with a packed enum (i.e., 1 byte) always evaluates to
false. Shouldn't gcc warn about this?

Reported-by: Connor Abbott <cwabbott0@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

docs: Update release notes and GL3.txt for GL_ARB_texture_compression_bptc

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

mesa/meta: Support decompressing floating-point formats

Previously the Meta implementation of glGetTexImage would fall back to
_mesa_get_teximage if the texturing is not using an unsigned normalised
format. However in order to support the half-float formats of BPTC textures we
can make it render to a floating-point renderbuffer instead. This patch makes
decompression_state have two FBOs, one for the GL_RGBA format and one for
GL_RGBA32F. If a floating-point texture is encountered it will try setting up
a floating-point FBO. It will now also check the status of the FBO and fall
back to _mesa_get_teximage if the FBO is not complete.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

swrast: Enable GL_ARB_texture_compression_bptc

Enables BPTC texture compression on the software rasterizer.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

i965: Enable the GL_ARB_texture_compression_bptc extension

Enables the BPTC extension on Gen>=7 and adds the necessary format mappings to
get the right surface type value.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

mesa/main: Modify generate_mipmap_compressed to cope with float textures

Once we add BPTC texture support we will need to generate mipmaps for
compressed floating point textures too. Most of the code seems to already be
there but it just needs a few extra lines to get it to use GL_FLOAT instead of
GL_UNSIGNED_BYTE as the type for the temporary buffers.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

mesa: Add texstore functions for BPTC-compressed textures

This adds compressors for all four of the BPTC compressed-texture formats. The
compressor is written from scratch and takes a very simple approach. It always
uses a single mode of the BPTC format (4 for unorm and 3 for half-floats) and
picks the two endpoints by dividing the texels into those which have more or
less than the average luminance of the block and then calculating an average
color of the texels within each division.

It's probably not really sensible to try to use BPTC compression at runtime
because for example with the Nvidia offline compression tool it can take in
the order of an hour to compress a full-screen image. With that in mind I
don't think it's worth having a proper compressor in Mesa and this approach
gives reasonable results for a usage that is basically a corner case.

v2: Always use the custom compressor, even for the unorm formats. Fix the
    quantization step for the half-float format compressor. Fixed a typo which
    was breaking the right-hand edge of half-float textures with a width that
    isn't a multiple of four.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

mesa: Add texel fetch functions for BPTC-compressed textures

Adds functions to fetch from any of the four BPTC-compressed formats.

v2: Set the alpha component to 1.0 when fetching from the half-float formats
    instead of leaving it uninitialised. Don't linearize the alpha component
    when fetching from sRGB.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

mesa: Add the format enums for BPTC-compressed images

This adds the following four Mesa image format enums which correspond to the
four BPTC compressed texture formats:

 MESA_FORMAT_BPTC_RGBA_UNORM
 MESA_FORMAT_BPTC_SRGB_ALPHA_UNORM
 MESA_FORMAT_BPTC_RGB_SIGNED_FLOAT
 MESA_FORMAT_BPTC_RGB_UNSIGNED_FLOAT

It also updates the format information functions to handle these and the
corresponding GL enums.

v2: Also modify _mesa_get_format_color_encoding, _mesa_get_srgb_format_linear
    and _mesa_get_uncompressed_format

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

mesa/format_info: Add support for the BPTC layout

Adds the ‘bptc’ layout to get_channel_bits. The channel bits for BPTC depend
on the mode but as it only has to be an approximation this sets it to 8 for
the two UNORM formats and 16 for the two half-float formats. These represent
the minimum number of bits of variation that can be generated by the
interpolation of the two formats.

This doesn't quite match what we do for S3TC which only returns 4 even though
it can similarly generate 8 bits from the interpolation. However it does match
what we return for ETC2. For reference, NVidia seems to return 8 bits for the
UNORM formats and 32 bits for the half-float formats.

v2: Change the number of bits to 8/8/8/8 for the UNORM formats and 16/16/16
    for the half-float formats.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>