i965: Add an option to not generate the SIMD8 fragment shader

For now, this can only be triggered with a new 'no8' INTEL_DEBUG option
and a new context flag.  We'll use the context flag later, but introducing
it now lets us bisect to this commit if it breaks something.

Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>

docs/autoconf: explicitly mention PKG_CONFIG_PATH for cross/multilib builds

... and squash a couple of typos.

Suggested-by: Eero Tamminen <eero.t.tamminen@intel.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

st/dri: Add __DRI2rendererQueryExtension support

The final step to get GLX_MESA_query_renderer working with gallium
drivers.

v2: Remove __DRI2_RENDERER_PREFERRED_PROFILE handling. It's already
handled in dri/common. Spotted by Marek.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

gallium/softpipe/llvmpipe: handle query_renderer caps

Both report 0xffffffff as both vendor and device id, and the maximum
amount of system memory as video memory.

v2: Use aux helper os_get_total_physical_memory().

Cc: Brian Paul <brianp@vmware.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

gallium/svga: handle query_rendered caps

All the values are are currently hardcoded. One could use
some heuristics to determine the amount of video memory if
a callback to the host is not available.

Do we what to advertise the driver as hardwar accelerated ?

Cc: Brian Paul <brianp@vmware.com>
Cc: José Fonseca <jose.r.fonseca@gmail.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

gallium/nouveau: handle query_renderer caps

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

gallium/vc4: handle query_renderer caps

Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

gallium/r300/r600/radeonsi: handle query_renderer caps

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

gallium/ilo: handle query_renderer caps

Implementation based on the classic driver with the following
changes:
 - Use auxiliarry function os_get_total_physical_memory to get the
total amount of memory.
 - Move the libdrm_intel specific get_aperture_size to the winsys.

Cc: Chia-I Wu <olvaffe@gmail.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

gallium/i915: handle query_renderer caps

Implementation based on the classic driver with the following
changes:
 - Use auxiliarry function os_get_total_physical_memory to get the
total amount of memory.
 - Move the libdrm_intel specific get_aperture_size to the winsys.

Cc: Stephane Marchesin <stephane.marchesin@gmail.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

gallium/freedreno: handle query_renderer caps

Provide the real vendor and and hardcode the device id as
0xffffffff as the devices currently using freedreno are non-pci.
The device features UMA.

Cc: Rob Clark <robclark@freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>

auxiliary/os: introduce os_get_total_physical_memory helper function

Cc: Alexander von Gluck IV <kallisti5@unixzen.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

gallium: add GLX_MESA_query_renderer caps

Namely vendor/device id, accelerated and UMA, which will be used to describe
the underlying renderer.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

dri/swrast: add GLX_MESA_query_renderer support

v2:
 - Drop __DRI2_RENDERER_PREFERRED_PROFILE case.
 - Cleanup return statements.

Cc: Brian Paul <brianp@vmware.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

dri/radeon: add GLX_MESA_query_renderer support

 - Create radeon{Vendor,GetRenderer}String helpers.
 - Drop __DRI2_RENDERER_PREFERRED_PROFILE case.
 - Cleanup return statements.

To be used by the upcomming GLX_MESA_query_renderer implementation.

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

dri/radeon: don't print TCL status on glGetString(GL_RENDERER)

Printing the TCL involves that context is available at the time of
query. The GLX_MESA_query_renderer states that glGetString(GL_RENDERER)
and glXQueryRendererStringMESA(GLX_RENDERER_DEVICE_ID_MESA) will have
the same format, thus removing the context dependenicy will help us
achieve that.

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

dri/nouveau: add GLX_MESA_query_renderer support

 - Create nouveau_{vendor,get_renderer}_string helpers.
 - Set correct max_gl*version.
 - Query the device PCIID via libdrm_nouveau/nouveau_getparam.

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

dri/common: Move __DRI2_RENDERER_PREFFERED_PROFILE handling to driQueryRendererIntegerCommon

Essentially all drivers would like to use to opengl core profile if
available, so avoid duplication by moving the code to a common fallback
within driQueryRendererIntegerCommon.

If a driver uses different approach they can handle it separately.

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

glx/drisw: add support for DRI2rendererQueryExtension

The extension is used by GLX_MESA_query_renderer, which
can be provided for by hardware and software drivers.

v2: Use designated initializers.
v3: Move drisw_query_renderer_*() to dri2_query_renderer.c

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

glx/dri2: use mapping table for dri2_convert_glx_query_renderer_attribs()

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

glx/drisw: Move private structure declarations to a header file

v2: Reff the correct file wrt copyright, spotted by Chia-I

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

mesa: check if GL_ARB_copy_image is enabled in _mesa_CopyImageSubData()

Generate a GL error and return rather than crashing on a null
ctx->Driver.CopyImageSubData pointer (gallium).  This allows apitraces
with glCopyImageSubData() calls to continue rather than crash.

Plus, fix a comment typo.

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

i965/blorp_clear: Use memcpy instead of assignment to copy clear value

Similar to the problem described in 2c50212b14da27de4e3, if we copy the clear
value through a regular assignment via a floating point value, then if an
integer clear value is being used that happens to contain a signalling NaN
value then it would get converted to a quiet NaN when stored via the x87
floating-point registers. This would corrupt the integer value. Instead we
should use a memcpy to ensure the exact bit representation is preserved.

This bug can be triggered on 32-bit builds with optimisations by using an
integer clear color with a value like 0x7f817f81.

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

r600g: Implement ARB_derivative_control

Requires Evergreen/Cayman

marek: update release notes

Signed-off-by: Glenn Kennard <glenn.kennard@gmail.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>

docs: Update relnotes for ARB_gpu_shader5

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

docs: Mark off ARB_gpu_shader5 for i965

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

i965: Enable ARB_gpu_shader5 on Gen7

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

i965/fs: Add support for nonconst sampler indexing in FS visitor

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

i965/fs: Add support for non-const sampler indices in generator

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

i965/fs: Refactor generate_tex in prep for nonconst sampler indexing

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

i965/fs: Use brw_adjust_sampler_state_pointer in fs generator too

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

i965/vec4: Add support for nonconst sampler indexing in VS visitor

V2: Set force_writemask_all on ADD; this *is* necessary in the VS case
too.

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

i965/vec4: Add support for non-const sampler indices in generator

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

i965: Generalize sampler state pointer mangling for non-const

For now, assume that the addressed sampler can be in any of the
16-sampler banks. If we preserved range information this far, we
could avoid emitting these instructions if the sampler were known
to be contained within one bank.

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

i965/vec4: Refactor generate_tex in prep for non-const samplers

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

i965: Extract helper function for surface state pointer adjustment

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

docs: Mark off ARB_gpu_shader5 UBO array indexing for i965

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>

i965/vec4: Add visitor support for nonconst ubo block indexing

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>

i965/vec4: Generate indirect sends for nonconstant UBO array access

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>

i965/fs: Add visitor support for nonconstant UBO indices

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>

i965/fs: Generate indirect sends for nonconstant UBO array accesses

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>

i965: Adjust set_message_descriptor to handle non-sends

We're about to be using this infrastructure to build descriptors in
src1 of non-send instructions, when preparing to do an indirect send.

Don't accidentally clobber the conditionalmod field of those
instructions with SFID bits, which aren't part of the descriptor.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>

i965: Add low-level support for indirect sends

This provides a reasonable place to enforce the hardware restriction
that indirect descriptors must be in a0.0

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>

i965/fs: Add pass to rename registers to break live ranges.

The pass breaks live ranges of virtual registers by allocating new
registers when it sees an assignment to a virtual GRF it's already seen
written.

total instructions in shared programs: 4337879 -> 4335014 (-0.07%)
instructions in affected programs:     343865 -> 341000 (-0.83%)
GAINED:                                46
LOST:                                  1

[mattst88]: Make pass not break in presence of control flow.
            invalidate_live_intervals() only if progress.
            Fix up delta_x/delta_y.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>

i965: Fix INTDIV math assertions on Broadwell.

Commit c66d928f2c9fa59e162c391fbdd37df969959718 ("i965: Enable INTDIV
in SIMD16 mode.") began using generate_math_gen6 to break SIMD16 INTDIV
into two SIMD8 operations.

generate_math_gen6 takes two registers - for unary operations, we pass
ARF null for the second operand.  Prior to Broadwell, real operands were
always GRF.  But now they can be IMM as well.

So, check for != ARF instead of == GRF.

+12 piglits.

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

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

This reverts commit af13cf609f4257768ad8b80be8cec7f2e6ca8c81, which
appears to cause huge performance problems on Ivybridge.  I'd missed
that the FFTID bits are in the low byte.  The documentation doesn't
indicate that the URB write message header actually wants FFTID - it
just labels those bits as "Reserved."  But it appears necessary.

This does slightly more than revert the original change: originally,
Broadwell had separate code generation, which used MOV, and this patch
only changed it for Gen4-7.  Now that both are unified, reverting this
also makes Broadwell use OR.  Which should be fine.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>

docs: Mark off ARB_derivative_control for i965.

Also update 10.3 relnotes to match.

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

i965: Enable ARB_derivative_control on Gen7+.

The extension says GL 4.0 is required. We'll meet the spirit
of that restriction by enabling on just those generations which will
soon support GL 4.0 (Gen7+), although it's technically supportable on
all generations.

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

i965/fs: Support fine/coarse derivative opcodes

The quality level (fine/coarse/dont-care) is plumbed through to the
generator as a constant in src1.

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

i965/vec4: Assert that fine/coarse derivative ops don't appear

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

glsl: Mark program as using dFdy if coarse/fine variant is used

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

nv50,nvc0: add support for fine derivatives

The quadop-based method we currently use on all chipsets already
provides the fine version of the derivatives.

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

mesa/st: add support for emitting fine derivative opcodes

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

gallium: add opcodes/cap for fine derivative support

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Marek Olšák <marek.olsak@amd.com> (v1)
Reviewed-by: Roland Scheidegger <sroland@vmware.com> (v1)
v2: Reuse opcode gaps as suggested by Marek

mesa/program: add new derivative unops to the unexpected list

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

glsl: add ARB_derivative control support

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

mesa: add ARB_derivative_control extension bit

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Matt Turner <mattst88@gmail.com>

mesa: add ARB_texture_barrier support

This extension is identical to NV_texture_barrier. Alias
glTextureBarrier to the existing glTextureBarrierNV and use the existing
NV_texture_barrier extension bit.

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

docs: document radeonsi BPTC support, sort extensions in 10.3 release notes

r600g: Implement BPTC texture support

Requires Evergreen/Cayman

Signed-off-by: Glenn Kennard <glenn.kennard@gmail.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>

i965: Rename intelValidateState to intel_update_state

This matches the name of the dd hook.  Also convert a couple of nearby
dd implementations to lowercase + underscore as is now the standard.

Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965: Assign PS kernel start pointers when we decide which kernels to use

Right now we decide which kernels to use and the GRF start offsets in
one place and emit the kernel pointers later.  The logic of how to map
8, 16 and 32 kernels to kernel start pointers follows the same logic as which
GRF start offsets to use, so lets figure out these two things in one place.

Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>

radeonsi: implement BPTC texture support

Passes all piglit tests.

v2: rebased

Signed-off-by: Marek Olšák <marek.olsak@amd.com>

radeonsi: fix buffer invalidation of unbound texture buffer objects

This maintains a list of all TBOs in a pipe_context.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

r600g: implement invalidation of texture buffer objects

This fixes piglit spec/ARB_texture_buffer_object/data-sync.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

r600g: fix constant buffer fetches

Somebody forgot to do this. It was uncovered by recent st/mesa changes.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82139

Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Tested-by: Andreas Boll <andreas.boll.dev@gmail.com>

r600g: clear constant buffer sizes at the beginning of CS

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

egl_dri2: fix EXT_image_dma_buf_import fds

The EGL_EXT_image_dma_buf_import specification was revised (according to
its revision history) on Dec 5th, 2013, for EGL to not take ownership of
the file descriptors.

Do not close the file descriptors passed in to eglCreateImageKHR with
EGL_LINUX_DMA_BUF_EXT target.

It is assumed, that the drivers, which ultimately process the file
descriptors, do not close or modify them in any way either. This avoids
the need to dup(), as it seems we would only need to just close the
dup'd file descriptors right after.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76188
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>

i965: fix compiler error in union initiliazer

gcc 4.6.3 chokes with the following error:

brw_vec4.cpp: In member function 'int brw::vec4_visitor::setup_uniforms(int)':
brw_vec4.cpp:1496:37: error: expected primary-expression before '.' token

Apparently C++ does not do named initializers for unions, except maybe
as a gcc extension, which is not present here.

As .f is the first element of the union, just drop it. Fixes the build
error.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Matt Turner <mattst88@gmail.com>

i965: Bail on FS copy propagation for scratch writes with source modifiers

Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>

i965: Bail on vec4 copy propagation for scratch writes with source modifiers

Fixes Khronos GLES3 CTS test:
dynamic_expression_array_access_vertex

Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>

glsl: Fixed vectorize pass vs. texture lookups.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82574
Reviewed-by: Matt Turner <mattst88@gmail.com>

ra: move declarations before code to fix MSVC build

Trivial.

svga: remove some unneeded INLINE qualifiers

Trivial.

docs/autoconf: update to better reflect reality

 * --enable-{32,64}-bit is done. Use --build and --host instead.
 * Configure does not add "-g -O2" to C{,XX}FLAGS.
 * Pkg-config has been mandatory for a while now.
 * Avoid using LDFLAGS, refer to pkg-config.
 * --with-expat is deprecated. Use pkg-config.

v2:
 * Note that CC/CXX will need to be set for multilib builds.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com> (v1)

scons: do not include headers from the sources lists

The SCons documentation is not explicit on the topic yet building mesa
with SCons and MSVC is known to have problems when headers are listed.
So be safe just drop them for now.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82534
Tested-by: Vinson Lee <vlee@freedesktop.org>
Acked-by: Emil Velikov <emil.l.velikov@gmail.com>

configure.ac: remove enable 32/64 bit hacks

These two were added ages ago, with an explicit comment "Hacks ..."
They have been insufficient for years and maintainers needed to
explicitly handle the build themselves.

Rather than lying and pretending that it works, just kill this hack and
let maintainers build things the way it should be done for their
distribution.

Document the removal in the release notes.

Suggested-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>

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

This reverts commit 2af28040d639dddbb7c258981a00eaf3dfcbcf03.

The commit was resolving an issue where libtool will not setup the
environment correctly when one explicitly provides --enable-{32,64}-bit
at configure time. It was caused due to the "-m32,64" C{,XX}FLAGS being
set too late relative to LT_INIT.

At the same time this cases the enable_static to be incorrectly set,
amongst others leading to build issues. Rather than being smart and
trying to handle 32/64 bit build ourselves it may be better to delegate
it to the builder/maintainer. The latter should now know better which is
the correct(most appropriate) method.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82536
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82546
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Tested-by: Brian Paul <brianp@vmware.com>

i965: Store uniform constant values in a gl_constant_value instead of float

The brw_stage_prog_data struct previously contained an array of float pointers
to the values of parameters. These were then copied into a batch buffer to
upload the values using a regular assignment. However the float values were
also being overloaded to store integer values for integer uniforms. This can
break if x87 floating-point registers are used to do the assignment because
the fst instruction tries to fix up invalid float values. If an integer
constant happened to look like an invalid float value then it would get
altered when it was copied into the batch buffer.

This patch changes the pointers to be gl_constant_value instead so that the
assignment should end up copying without any alteration. This also makes it
more obvious that the values being stored here are overloaded for multiple
types.

There are some static asserts where the values are uploaded to ensure that the
size of gl_constant_value is the same as a float.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81150
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

st/vdpau: add device reference counting

This fixes an issue with flash where it tries to destroy a decoder
after already destroying the device associated with the decoder.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=82517
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>

mesa: Make ARB_gpu_shader5 core-profile-only

Requires GLSL 1.50 or higher, which we only support in the core profile.

V2: Fix broken alignment

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

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>