docs/releasing: document post branch version bump

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

mesa: Bump version to 17.1.0-devel

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

radeonsi: reject invalid vertex element formats

This should fix a coverity defect.

Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>

radeonsi: don't forget to add HTILE to the buffer list for texturing

This fixes VM faults. Discovered by Samuel Pitoiset.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98975
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99450

Cc: 17.0 13.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>

st/vdpau: only send buffers with B8G8R8A8 format to X

PresentPixmap only works if the pixmap depth matches with the
window depth, otherwise it returns a BadMatch protocol error.
Even if the depths match, the result won't look correctly
if the VDPAU RGB component order doesn't match the X11 one so
we only allow the X11 format.
For other buffers we copy them to a buffer which is send to X.

v2: only send buffers with format VDP_RGBA_FORMAT_B8G8R8A8
v3: reword commit message
v4: add comment explaining the code

Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>

radeonsi: fix texture gather on stencil textures

At least on VI, texture gather doesn't work with a 24_8 data format, so
use 8_8_8_8 and a modified swizzle instead.

A bit of background: When creating a GL_STENCIL_INDEX8 texture, we select
the X24S8 pipe format because we don't support stencil-only render targets
properly. With mip-mapping this can lead to a setup where the tiling is
incompatible with stencil texturing, and a flushed stencil texture is
used. For the flushed stencil, a literal X24S8 is used because there were
issues with an 8bpp DB->CB copy.

Longer term, it would be good if we could get away from these workarounds,
i.e. properly support an S8 format for stencil-only rendering and flushed
stencil. Since stencil texturing is somewhat rare, it's not a high
priority.

Fixes GL45-CTS.texture_cube_map_array.sampling.

Cc: 17.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Edward O'Callaghan <funfunctor@folklore1984.net>

mesa/main: Fix FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE for NONE attachment type

When the attachment type is NONE (att->Type),
FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE should be NONE always.

Note that technically, the current behaviour follows the spec. From
OpenGL 4.5 spec, Section 9.2.3 "Framebuffer Object Queries":

   "If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is NONE, then
    either no framebuffer is bound to target; or the default
    framebuffer is bound, attachment is DEPTH or STENCIL, and the
    number of depth or stencil bits, respectively, is zero."

Reading literally this paragraph, for the default framebuffer, NONE
should be only returned if attachment is DEPTH and STENCIL without
being allocated.

But it doesn't makes too much sense to return DEFAULT_FRAMEBUFFER if
the attachment type is NONE. For example, this can happens if the
attachment is FRONT_RIGHT run on monoscopic mode, as that attachment
is only available on stereo mode.

With the current behaviour, defensive querying of the object type
would not work properly. So you could query the object type checking
for NONE, get DEFAULT_FRAMEBUFFER, and then get and INVALID_OPERATION
when requesting other pnames (like RED_SIZE), as the real attachment
type is NONE.

This fixes:
GL45-CTS.direct_state_access.framebuffers_get_attachment_parameters

v2: don't change the behaviour for att->Type != GL_NONE, as caused
    some ES CTS regressions
v3: simplify condition (Iago)

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>

radeonsi: Always leave poly_offset in a valid state

This commit makes si_update_poly_offset set poly_offset to NULL if
uses_poly_offset is false. This way poly_offset either points into the
currently queued rasterizer, or it is NULL.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99451
Cc: "13.0 17.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

mesa/main: fix meta caller of _mesa_ClampColor

Since _mesa_ClampColor properly checks for support of the API function
now, it's meta callers need to check support as well.

Fixes: 963311b71f ("mesa/main: fix version/extension checks in _mesa_ClampColor")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99401
Tested-by: Mark Janes <mark.a.janes@intel.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Cc: "17.0" <mesa-stable@lists.freedesktop.org>

mesa/glsl: move TransformFeedbackBufferStride to gl_shader

Here we remove the single use of this field in gl_linked_shader
which allows us to move the field out of gl_shader_info

While we are at it we rewrite link_xfb_stride_layout_qualifiers()
to be more clear.

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

glsl: exit loop early if we find xfb layout qualifers

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

glsl: set InnerCoverage directly in gl_program

Also move out of the shared gl_shader_info.

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

glsl: tidy up PostDepthCoverage shader field

There is no reason for this to be in the shared gl_shader_info or
to copy it to gl_program at the end of linking (its already there).

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

mesa/glsl: move pixel_center_integer to gl_shader

This is only used by gl_linked_shader as a temp during linking
so use a temp there instead.

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

mesa/glsl: move origin_upper_left to gl_shader

This is only used by gl_linked_shader as a temp during linking
so use a temp there instead.

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

mesa/glsl: move uses_gl_fragcoord to gl_shader

This is only used by gl_linked_shader as a temp during linking
so use a temp there instead.

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

mesa/glsl: move redeclares_gl_fragcoord to gl_shader

This is never used in gl_linked_shader other than as a temp
during linking so just use a temp instead.

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

mesa/glsl: move ARB_fragment_coord_conventions_enable field

This is only used by gl_shader not gl_linked_shader so move it
there.

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

st/mesa/glsl: set early_fragment_tests directly in shader_info

We also move EarlyFragmentTests out of the gl_shader_info struct
as it is now only used by gl_shader.

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

mesa/glsl/i965: set and use tcs vertices_out directly

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

i965: get outputs_written from gl_program

There is no need to go via the pointer in nir_shader. This change
is required for the shader cache as we don't create a nir_shader.

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

gallivm: use #ifdef not #if for PIPE_ARCH_BIG_ENDIAN

This fixes the build on ppc/s390.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Cc: "17.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

mesa: don't always set _NEW_PROGRAM when linking

We only need to set it when linking was successful and the program
being linked is currently active.

The programs_in_use mask is just used as a flag for now but in
a future change we will use it to update the CurrentProgram array.

V2: make sure to flush vertices before linking (suggested by Marek)

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

mesa: change init subroutine defaults helper to work per gl_program

A later patch will result in SSO programs calling this helper
per gl_program rather than per gl_shader_program.

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

mesa/glsl: move ProgramResourceList to gl_shader_program_data

We also move NumProgramResourceList at the same time.

GLES does interface validation on SSO at runtime so we need to move
this to be able to switch to storing gl_program pointers in
CurrentProgram.

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

glsl: store number of explicit uniform loactions in gl_shader_program

This allows us to cleanup the functions that pass this count around,
but more importantly we will be able to call the uniform linking
functions from that backends linker without having to pass this
information to the backend directly via Driver.LinkShader().

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

glsl: create a new link_and_validate_uniforms() helper

Currently this just breaks up the linking code a bit but in the
future i965 will call this from the backend via Driver.LinkShader()
so that we can do NIR optimisations before assigning uniform
locations.

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

glsl: make a bunch of varying linking functions static

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

glsl: move more varying linking code to link_varyings.cpp

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

i965/blorp: Make post draw flush more explicit

Blits do not need any special treatment as the target buffer
object is added to render cache just as one does for normal draw.
Color clears and resolves in turn require explicit "end of pipe
synchronization". It is not clear what this means exactly but the
assumption is that render cache flush with command stream stall
should be sufficient.

Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>

i965/gen6: Issue direct depth stall and flush after depth clear

instead of calling unconditionally brw_emit_mi_flush() which
does:

   brw_emit_pipe_control_flush(brw,
                                PIPE_CONTROL_DEPTH_CACHE_FLUSH |
                                PIPE_CONTROL_RENDER_TARGET_FLUSH |
                                PIPE_CONTROL_CS_STALL);

   brw_emit_pipe_control_flush(brw,
                                PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE |
                                PIPE_CONTROL_CONST_CACHE_INVALIDATE);

Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>

i965: Make depth clear flushing more explicit

Current blorp logic issues unconditional "flush everything"
(see brw_emit_mi_flush()) after each render. For example, all
blits issue this unconditionally which shouldn't be needed if
they set render cache properly so that subsequent renders do
necessary flushing before drawing.

In case of piglit:

ext_framebuffer_multisample-accuracy all_samples depth_draw small

intel_hiz_exec() is always preceded by blorb blit and the
unconditional flush looks to hide the lack of stall and flushes
in depth clears. By removing the brw_emit_mi_flush() I get gpu
hangs.

This patch adds the stalls and flushes mandated by the spec
and gets rid of those hangs.

v2 (Jason, Ken): Document the rational for separating
                 depth cache flush and stall on Gen7.

Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>

i965/blorp: Use the render cache mechanism instead of explicit flushing

by replacing brw_emit_mi_flush() with brw_render_cache_set_check_flush().
The latter splits the flush in two:

   brw_emit_pipe_control_flush(brw,
                               PIPE_CONTROL_DEPTH_CACHE_FLUSH |
                               PIPE_CONTROL_RENDER_TARGET_FLUSH |
                               PIPE_CONTROL_CS_STALL);

   brw_emit_pipe_control_flush(brw,
                               PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE |
                               PIPE_CONTROL_CONST_CACHE_INVALIDATE);

instead of

   int flags = PIPE_CONTROL_NO_WRITE | PIPE_CONTROL_RENDER_TARGET_FLUSH;
   if (brw->gen >= 6) {
      flags |= PIPE_CONTROL_INSTRUCTION_INVALIDATE |
               PIPE_CONTROL_CONST_CACHE_INVALIDATE |
               PIPE_CONTROL_DEPTH_CACHE_FLUSH |
               PIPE_CONTROL_VF_CACHE_INVALIDATE |
               PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE |
               PIPE_CONTROL_CS_STALL;
   }
   brw_emit_pipe_control_flush(brw, flags);

v2 (Jason): Check that destination exists before trying to add to
            render cache. Depth clears and resolves don't have it.

Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>

utils: really remove the __END_DECLS macro

Fixes: d1efa09d342 "util: import sha1 implementation from OpenBSD"
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>

utils: build sha1/disk cache only with Android/Autoconf

Earlier commit imported a SHA1 implementation and relaxed the SHA1 and
disk cache handling, broking the Windows builds.

Restrict things for now until we get to a proper fix.

Fixes: d1efa09d342 "util: import sha1 implementation from OpenBSD"
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>

util: import sha1 implementation from OpenBSD

At the moment we support 5+ different implementations each with varying
amount of bugs - from thread safely problems [1], to outright broken
implementation(s) [2]

In order to accommodate these we have 150+ lines of configure script and
extra two configure toggles. Whist an actual implementation being
~200loc and our current compat wrapping ~250.

Let's not forget that different people use different code paths, thus
effectively makes it harder to test and debug since the default
implementation is automatically detected.

To minimise all these lovely experiences, import the "100% Public
Domain" OpenBSD sha1 implementation. Clearly document any changes needed
to get building correctly, since many/most of those can be upstreamed
making future syncs easier.

As an added bonus this will avoid all the 'fun' experiences trying to
integrate it with the Android and SCons builds.

v2: Manually expand __BEGIN_DECLS/__END_DECLS and document (Tapani).

Furthermore it seems that some games (or surrounding runtime) static
link against OpenSSL resulting in conflicts. For more information see
the discussion thread [3]

Bugzilla [1]: https://bugs.freedesktop.org/show_bug.cgi?id=94904
Bugzilla [2]: https://bugs.freedesktop.org/show_bug.cgi?id=97967
[3] https://lists.freedesktop.org/archives/mesa-dev/2017-January/140748.html
Cc: Mark Janes <mark.a.janes@intel.com>
Cc: Vinson Lee <vlee@freedesktop.org>
Cc: Tapani Pälli <tapani.palli@intel.com>
Cc: Jonathan Gray <jsg@jsg.id.au>
Tested-by: Jonathan Gray <jsg@jsg.id.au>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Acked-by: Tapani Pälli <tapani.palli@intel.com> (v1)
Acked-by: Jason Ekstrand <jason@jlekstrand.net> (v1)

i965: Make brw_cache_item structure private to brw_program_cache.c.

struct brw_cache_item is an implementation detail of the program cache.
We don't need to make those internals available to the entire driver.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>

radeonsi: determine in advance which VBOs should be added to the buffer list

v2: now it should be correct

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

radeonsi: use fewer pointer dereferences in upload_vertex_buffer_descriptors

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

radeonsi: reject invalid vertex buffer indices at state creation

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

radeonsi: use a global dirty mask for shader pointers

Only vertex buffers use a separate bool flag.

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

radeonsi: use a bitmask-based loop in si_decompress_textures

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

radeonsi: skip an unnecessary mutex lock for L2 prefetches

the mutex lock is inside util_range_add.

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

radeonsi: si_cp_dma_prepare is a no-op for L2 prefetches

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

radeonsi: add SI_CPDMA_SKIP_BO_LIST_UPDATE

the next commit will use it in a clever way, because the CP DMA prefetch
doesn't need this.

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

radeonsi: use the correct target machine when building shader variants

If the shader selector is created with a different context than
the shader variant, we should use the calling context's target machine
for the shader variant.

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

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

radeonsi: move shader pipe context state into a separate structure

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

i965: Fix SURFACE_STATE to handle non-zero aux offsets

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Daniel Stone <daniels@collabora.com>

Revert "etnaviv: Fake occlusion query capability"

This reverts commit b7ac0f567123c96b5cd9e3485b963a5c0a0db66a.

This is a half baked solution needs some rework to fixes issues
with reported counter bits (GL_QUERY_COUNTER_BITS_ARB).
Also it enables PIPE_CAP_QUERY_TIME_ELAPSED accidently.

Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>

android: ac/debug: move sid_tables.h generation and IB decode to amd/common

This patch is the porting to android of the following commits:

b838f64 "ac/debug: Move sid_tables.h generation to common code."
0ef1b4d "ac/debug: Move IB decode to common code."

Fixes android building errors due to sid_tables.h
and ac_debug.c, ac_debug.h moved to amd/common

Tested by building nougat-x86

Acked-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>

android: gallium/auxiliary: fix building error in Android 7.0

Conditional libLLVMCore static library dependency is added,
for the case when MESA_ENABLE_LLVM is true

Fixes the following building error with Android 7.0:

In file included from
external/mesa/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp:62:
...
external/llvm/include/llvm/IR/Attributes.h:68:14: fatal error:
'llvm/IR/Attributes.inc' file not found
    #include "llvm/IR/Attributes.inc"
             ^
1 error generated.

Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

android: amd/common: fix LLVMInitializeAMDGPU* functions declaration

LLVMInitializeAMDGPU* functions need to be explicitly declared
and mesa expects them via <llvm-c/Target.h> header,
but LLVM needs to be instructed to invoke its own LLVM_TARGET(AMDGPU) macro,
or the functions will not be available.

A new llvm cflag (-DFORCE_BUILD_AMDGPU) serves this purpose,
the same mechanism is used also by other llvm targets e.g. FORCE_BUILD_ARM

A necessary prerequisite is to have AMDGPU target handled accordingly
in llvm config files i.e. {Target,AsmParser,AsmPrinter}.def
for llvm device build includes.

This avoids the following building errors:

external/mesa/src/amd/common/ac_llvm_util.c:43:2: error: implicit declaration of function 'LLVMInitializeAMDGPUTargetInfo' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
        LLVMInitializeAMDGPUTargetInfo();
        ^
external/mesa/src/amd/common/ac_llvm_util.c:44:2: error: implicit declaration of function 'LLVMInitializeAMDGPUTarget' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
        LLVMInitializeAMDGPUTarget();
        ^
external/mesa/src/amd/common/ac_llvm_util.c:45:2: error: implicit declaration of function 'LLVMInitializeAMDGPUTargetMC' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
        LLVMInitializeAMDGPUTargetMC();
        ^
external/mesa/src/amd/common/ac_llvm_util.c:46:2: error: implicit declaration of function 'LLVMInitializeAMDGPUAsmPrinter' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
        LLVMInitializeAMDGPUAsmPrinter();
        ^
Acked-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>

android: radeonsi: fix LLVMInitializeAMDGPU* functions declaration

LLVMInitializeAMDGPU* functions need to be explicitly declared
and mesa expects them via <llvm-c/Target.h> header,
but LLVM needs to be instructed to invoke its own LLVM_TARGET(AMDGPU) macro,
or the functions will not be available.

A new llvm cflag (-DFORCE_BUILD_AMDGPU) serves this purpose,
the same mechanism is used also by other llvm targets e.g. FORCE_BUILD_ARM

A necessary prerequisite is to have AMDGPU target handled accordingly
in llvm config files i.e. {Target,AsmParser,AsmPrinter}.def
for llvm device build includes.

This avoids the following building errors:

external/mesa/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c:129:2: error: implicit declaration of function 'LLVMInitializeAMDGPUTargetInfo' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
        LLVMInitializeAMDGPUTargetInfo();
        ^
external/mesa/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c:130:2: error: implicit declaration of function 'LLVMInitializeAMDGPUTarget' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
        LLVMInitializeAMDGPUTarget();
        ^
external/mesa/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c:131:2: error: implicit declaration of function 'LLVMInitializeAMDGPUTargetMC' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
        LLVMInitializeAMDGPUTargetMC();
        ^
external/mesa/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c:132:2: error: implicit declaration of function 'LLVMInitializeAMDGPUAsmPrinter' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
        LLVMInitializeAMDGPUAsmPrinter();
        ^

Acked-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>

android: radeon: fix LLVMInitializeAMDGPU* functions declaration

LLVMInitializeAMDGPU* functions need to be explicitly declared
and mesa expects them via <llvm-c/Target.h> header,
but LLVM needs to be instructed to invoke its own LLVM_TARGET(AMDGPU) macro,
or the functions will not be available.

A new llvm cflag (-DFORCE_BUILD_AMDGPU) serves this purpose,
the same mechanism is used also by other llvm targets e.g. FORCE_BUILD_ARM

A necessary prerequisite is to have AMDGPU target handled accordingly
in llvm config files i.e. {Target,AsmParser,AsmPrinter}.def
for llvm device build includes.

This avoids the following building errors:

external/mesa/src/gallium/drivers/radeon/radeon_llvm_emit.c:121:2: error: implicit declaration of function 'LLVMInitializeAMDGPUTargetInfo' [-Werror=implicit-function-declaration]
  LLVMInitializeAMDGPUTargetInfo();
  ^
external/mesa/src/gallium/drivers/radeon/radeon_llvm_emit.c:122:2: error: implicit declaration of function 'LLVMInitializeAMDGPUTarget' [-Werror=implicit-function-declaration]
  LLVMInitializeAMDGPUTarget();
  ^
external/mesa/src/gallium/drivers/radeon/radeon_llvm_emit.c:123:2: error: implicit declaration of function 'LLVMInitializeAMDGPUTargetMC' [-Werror=implicit-function-declaration]
  LLVMInitializeAMDGPUTargetMC();
  ^
external/mesa/src/gallium/drivers/radeon/radeon_llvm_emit.c:124:2: error: implicit declaration of function 'LLVMInitializeAMDGPUAsmPrinter' [-Werror=implicit-function-declaration]
  LLVMInitializeAMDGPUAsmPrinter();
  ^

Acked-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>

nouveau: remove always false argument in nouveau_fence_new()

No point in having the extra argument considering that it's effectively
unused since the function was introduced.

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

egl/wayland: resolve quirky try_damage_buffer() implementation

The implementation was added with commit d085a5dff5b and effectively
provided a hidden dependency.

Namely: the codepath used was determined solely during build time. Thus
if we built again new wayland and then run against older (yet still
within the requirements, as per the configure) one will get undefined
symbols.

As of earlier commit 36b9976e1f9 "egl/wayland: Avoid race conditions
when on non-main thread" the required version was bumped to one which
provides the API, thus we can drop the quirky solution.

Cc: Derek Foreman <derekf@osg.samsung.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>

configure: error out when building static XOR shared

Current code warns out in such cases and falls-back to either static or
shared. That can be easily missed amongst the volume produced by our
configure script.

Replace the warning with an error such that one gets direct feedback
when they're doing something wrong.

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

configure: explicitly require shared glapi for enable-dri

We've been using and depending on it for at least a couple of years.
Make it obvious and error out, should one opt for it.

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

configure: factor out commom egl/gbm checks

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

configure: remove HAVE_EGL_DRIVER_DRI[23]

We have them for local purposes in configure, where we can use their
direct dependency.

With the only remaining instance in the makefile(s) being always true,
as it can be seen in the configure snippet.

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

configure: forbid static EGL/GBM

Both libraries implicitly require shared GLAPI which in itself mandates
shared libraries.

Stop pretending that one can use it and error out at configure stage.

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

configure: remove unused AC_SUBST variables

v2: Rebase.

Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (v1)

gallium: correctly manage libsensors link flags

We should be using LIBS rather than the LDFLAGS variable. Furthermore
try to keep the linking to the final stage, rather than intermetent
static library.

Cc: Steven Toth <stoth@kernellabs.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

egl/wayland: unify dri2_wl_create_surface implementations

Rather than having two almost identical codepaths (one for HW/wl_drm and
another for SW/wl_shm), just factorise and reuse in both places.

v2: Rebase
v3: Rebase

Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com> (v2)

egl/wayland: use the destroy_window_callback for swrast

As described in commit 690ead4a135 ("egl/wayland-egl: Fix for segfault
in dri2_wl_destroy_surface.") if we attempt to destroy a EGL surface
attached to already destroyed Wayland window we'll get a segfault.

v2: set the correct callback alongside the window->private. (Dan)

Cc: Daniel Stone <daniels@collabora.com>
Cc: "12.0 13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>

glx: unify GLX_SGIX_pbuffer aliased declarations

No point in having an identical code in two places.

Not to mention that the Apple one incorrectly uses GLXDrawable as pbuf
type. This change is both API and ABI safe since the header uses the
correct GLXPbufferSGIX and both types are a typedef of the same
primitive XID.

Cc: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Jeremy Sequoia <jeremyhu@apple.com>

glx: use GLX_ALIAS for glXGetProcAddress

Use the macro, rather than open-coding it.

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

mesa: make use of HAVE_FUNC_ATTRIBUTE_ALIAS macro

We must make sure that xserver has an equivalent one-line
change to its configure.ac as the glx/glapi headers get copied over.

Then again, xserver does _not_ seem to set HAVE_ALIAS to begin with so
one might want to look into that first.

Cc: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>

android: set HAVE_FUNC_ATTRIBUTE_ALIAS

Analogous to previous two commits.

Strictly speaking it's not be applicable for Android since we don't
build GLX and related code.

Regardless keep things consistent with the other build systems.

Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>

scons: set HAVE_FUNC_ATTRIBUTE_ALIAS

Analogoust to the previous commit were we did so for autotools

Cc: Jose Fonseca <jfonseca@vmware.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

configure: use standard check for attribure alias

Currently we have two macros - HAVE_ALIAS and GLX_ALIAS_UNSUPPORTED.
To make it even better former of which is explicitly cleared in some
cases while not in others.

Clear all that up by using a single macro properly set during configure.

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

glx: remove always false ifdef GLX_NO_STATIC_EXTENSION_FUNCTIONS

Quick search through git history (of both mesa and xserver) hows no
instances where this was ever set.

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

etnaviv: Fake occlusion query capability

This enables the PIPE_CAP_OCCLUSION_QUERY capability without adding an
occlusion query type.

This is necessary to get Mesa to report desktop GL 2.0 support (to run
exciting things such as ioq3's OpenGL 2 renderer), and should be valid
because exposing the capability does not guarantee that any
counters are actually implemented.

Signed-off-by: Wladimir J. van der Laan <laanwj@gmail.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

etnaviv: add flags parameter to texture barrier

Fixes compile warning introduced by commit a1c848.

Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>

etnaviv: handle PIPE_CAP_TGSI_FS_FBFETCH

Fixes compile warning introduced by commit ee3ebe.

Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>

gallivm: (trivial) fix copy/paste bug with big endian code

8bd67a35c50e68c21aed043de11e095c284d151a introduced using undefined variable
on big endian archs due to copy/paste bug.
(compile hack tested only)

configure.ac: Revert recent HAVE_LLVM changes.

This reverts changes 903eb09b5fb78d47d0f8a4bdf826a113ca2aff40..1a0aa468f354f0ee94dd383cd40ae915584624aa:

  Tobias Droste (5):
    configure.ac: Rename MESA_LLVM to FOUND_LLVM
    configure.ac: Only set LLVM_LIBS if LLVM is used
    configure.ac: Only define HAVE_LLVM if LLVM is used
    configure.ac: Set and use HAVE_GALLIUM_LLVM define
    configure.ac: Don't check LLVM version in gallium_require_llvm

They break scons build, and I'm not convinced this is the right fix.  In
particular changing HAVE_LLVM in the C code is something I'd rather
avoid no matter what.  So it's better to discuss without the pressure of
broken builds.

docs: Fix GLSL compiler link

The doc wasn't update since we moved the glsl compiler to src/compiler/glsl.
I also updated the description of the standalone compiler.

v2:
 - Mention that just-log argument removes headers/separators.
 - Mention that version argument is mandatory.
Since version argument is mandatory, add --version to the command line
example.

Signed-off-by: Elie Tournier <tournier.elie@gmail.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>

vulkan: automake: do not use EXTRA_DIST in a conditional

Otherwise the file might not end up in the tarball.

Fixes: dbd677efb42 "vulkan: add API registry"
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>

configure.ac: Respect LLVM_CFLAGS in LLVM version detection

When compiling LLVM headers, including llvm-config.h, we need to respect
LLVM_CFLAGS. This is especially crucial if LLVM is located in a
non-standard location and it happens that llvm-config.h includes another
header. In such case the detection would fail due to missing header,
because the path is provided in LLVM_CFLAGS.

Let's add LLVM_CFLAGS to global CFLAGS for the time of detection and then
restore the original flags, as done in other places of the script.

Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

configure.ac: Don't check LLVM version in gallium_require_llvm

This is actually not needed because the version is checked later.

Line 2609:
if test "x$enable_gallium_llvm" == "xyes"; then
    llvm_require_version $LLVM_REQUIRED_GALLIUM "gallium"
    llvm_add_default_components "gallium"

    HAVE_GALLIUM_LLVM=xyes
    DEFINES="${DEFINES} -DHAVE_GALLIUM_LLVM"
fi

Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

configure.ac: Set and use HAVE_GALLIUM_LLVM define

Gallium code used HAVE_LLVM to check if it needs to compile code for
LLVM in header and source files.

With the new logic HAVE_LLVM is always set. Use extra define to figure
out if LLVM is used.

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

Signed-off-by: Tobias Droste <tdroste@gmx.de>

configure.ac: Only define HAVE_LLVM if LLVM is used

Make sure that HAVE_LLVM compiler define is only set if LLVM is
actually used.

Signed-off-by: Tobias Droste <tdroste@gmx.de>
v2 [Emil] fold within the existing conditional
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

configure.ac: Only set LLVM_LIBS if LLVM is used

This renames llvm_check_version_for to llvm_require_version and let it
set a variable to mark that LLVM will be used.

Use this to make a usefull configure output and to only check if the
libs are found in LLVM if it is actually used.

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

Signed-off-by: Tobias Droste <tdroste@gmx.de>

configure.ac: Rename MESA_LLVM to FOUND_LLVM

This renames MESA_LLVM to FOUND_LLVM and updates the config.log report
to say if LLVM is found or not, to make clear that this does not mean
that it is used.

There are no MESA_LLVM users so drop the AC_SUBST.

v2 [Emil]
 - Polish test: -a over && test, = over ==, unquiote xyes
 - other ?

Signed-off-by: Tobias Droste <tdroste@gmx.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

gallivm: Cleanup USE_MCJIT.

Split USE_MCJIT macro dual nature into a separate constant time define
and a run-time variable.

Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

i965: Don't map/unmap in brw_print_program_cache on LLC platforms.

We have a persistent mapping.  Don't map it a second time or try to
unmap it.  Just use the pointer.

This most likely would wreak havoc except that this code is unused
(it's only called from an if (0) debug block).

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>

i965: Move program cache printing to brw_program_cache.c.

It makes sense to put a function which prints out the entire contents
of the program cache in the file that implements the program cache.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>

i965: Make a helper for finding an existing shader variant.

We had five copies of the same "walk the cache and look for an
existing shader variant for this program" code.  Now we have one
helper function that returns the key.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>

glsl: Make copy propagation not panic when it sees an intrinsic.

A number of games have large arrays of constants, which we promote to
uniforms.  This introduces copies from the uniform array to the original
temporary array.  Normally, copy propagation eliminates those copies,
making everything refer to the uniform array directly.

A number of shaders in "Deus Ex: Mankind Divided" recently exposed a
limitation of copy propagation - if we had any intrinsics (i.e. image
access in a compute shader), we weren't able to get rid of these copies.

That meant that any variable indexing remained on the temporary array
rather being moved to the uniform array.  i965's scalar backend
currently doesn't support indirect addressing of temporary arrays,
which meant lowering it to if-ladders.  This was horrible.

According to Marek, on radeonsi/GCN, "F1 2015" uses 64% less
spilled-temp-array memory.

On i965/Skylake:

total instructions in shared programs: 13362954 -> 13329878 (-0.25%)
instructions in affected programs: 43745 -> 10669 (-75.61%)
helped: 12
HURT: 0

total cycles in shared programs: 248081010 -> 245949178 (-0.86%)
cycles in affected programs: 4597930 -> 2466098 (-46.37%)
helped: 12
HURT: 0

total spills in shared programs: 9493 -> 9507 (0.15%)
spills in affected programs: 25 -> 39 (56.00%)
helped: 0
HURT: 1

total fills in shared programs: 12127 -> 12197 (0.58%)
fills in affected programs: 110 -> 180 (63.64%)
helped: 0
HURT: 1

Helps Deus Ex: Mankind Divided.   The one shader with hurt spills/fills
is from Tomb Raider at Ultra settings, but that same shader has a
-39.55% reduction in instructions and -14.09% reduction in cycle counts,
so it seems like a win there as well.

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

i965: Make DCE set null destinations on messages with side effects.

(Co-authored by Matt Turner.)

Image atomics, for example, return a value - but the shader may not
want to use it.  We assigned a useless VGRF destination.  This seemed
harmless, but it can actually be quite harmful.  The register allocator
has to assign that VGRF to a real register.  It may assign the same
actual GRF to the destination of an instruction that follows soon after.

This results in a write-after-write (WAW) dependency, and stall.

A number of "Deus Ex: Mankind Divided" shaders use image atomics, but
don't use the return value.  Several of these were hitting WAW stalls
for nearly 14,000 (poorly estimated) cycles a pop.  Making dead code
elimination null out the destination avoids this issue.

This patch cuts one shader's estimated cycles by -98.39%!  Removing the
message response should also help with data cluster bandwidth.

On Skylake:

(instruction counts remain identical)

total cycles in shared programs: 255413890 -> 248081010 (-2.87%)
cycles in affected programs: 12019948 -> 4687068 (-61.01%)
helped: 24
HURT: 10

v2: Make can_omit_write independent of can_eliminate (Curro).

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

i965: Combine some dead code elimination NOP'ing code.

In theory we might have incorrectly NOP'd instructions that write the
flag, but where that flag value isn't used, and yet the instruction
either writes the accumulator or has side effects.

I don't believe any such instructions exist, so this is mostly a
code cleanup.

Curro pointed out that FS_OPCODE_FB_WRITE has a null destination and
actually writes the flag on Gen4-5 to dynamically decide whether to
write some payload data.  The hunk removed in this patch might have
NOP'd it, except that we don't actually mark flags_written() in the
IR, so it doesn't think the flag is touched at all.  That's sketchy,
but it means it wouldn't hit this today (though there are likely other
problems!).

v2: Properly replace the inst->regs_written() check in the second
    hunk with the flag being live (mistake caught by Curro).

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

i965: Make DCE explicitly not eliminate any control flow instructions.

According to Matt, the dead code pass explicitly avoided IF and WHILE
because on Sandybridge, these could have conditional modifiers and
null destination registers.  Normally, those instructions use BAD_FILE
for the destination register.  Nowadays, we don't do that anymore, so
we could technically drop these checks.

However, it's clearer to explicitly leave control flow instructions
alone, so change it to the more generic !inst->is_control_flow().

This should have no actual change.

[This patch implements review feedback from Curro and Matt.]

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

radv: disable vertex reuse when writing viewport index

This fixes some issues we'd hit later if using viewport
indexes.

Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>

radv: add support for layered clears (v2)

Just always use the layer clear pipelines,
the overhead of emitting the layer shouldn't be
too large.

v2: Bas suggested we always use it.

Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>

radv/ac: split part of llvm compile into a separate function

This is needed to have common code for gs copy shader emission.

Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>

radv/ac: switch an if to switch

makes it easier to add other shader stages.

Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>

radv: add support for writing layer/viewport index (v2)

This just adds the infrastructure to allow writing layer
and viewport index. It's just a first patch out of the geom
shader tree, and doesn't do much on its own.

v2: add missing if statement change (Bas)

Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>

ac/debug: Decrease num_dw for type 2 NOP's.

Otherwise we read past the end of the buffer.

Signed-off-by: Bas Nieuwenhuizen <basni@google.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

radeonsi: for the tess barrier, only use emit_waitcnt on SI and LLVM 3.9+

Cc: 17.0 13.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>