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

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>

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>

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>

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>

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>

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>

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>

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

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

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>

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>

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>

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>

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

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: d1efa09d34 "util: import sha1 implementation from OpenBSD"
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>

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)

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>

v2: now it should be correct

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

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

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

Only vertex buffers use a separate bool flag.

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

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

the mutex lock is inside util_range_add.

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

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

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>

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>

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

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>

This reverts commit b7ac0f5671.

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>

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>

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>

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>

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>

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>

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>

The implementation was added with commit d085a5dff5 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 36b9976e1f "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>

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>

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>

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

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>

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>

v2: Rebase.

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

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>

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)

As described in commit 690ead4a13 ("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>

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>

Use the macro, rather than open-coding it.

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

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>

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>