glx/glvnd: Use bsearch() in FindGLXFunction instead of open-coding it

Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>

glx/glvnd: Fix dispatch function names and indices

As this array was not actually sorted, FindGLXFunction's binary search
would only sometimes work.

Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>

glx/glvnd: Don't modify the dummy slot in the dispatch table

Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>

anv/pipeline: Properly cache prog_data::param

Before we were caching the prog data but we weren't doing anything with
brw_stage_prog_data::param so anything with push constants wasn't getting
cached properly.  This commit fixes that.

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98012
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>

anv/pipeline: Put actual pointers in anv_shader_bin

While we can simply calculate offsets to get to things such as the
prog_data and the key, it's much more user-friendly if there are just
pointers.  Also, it's a bit more fool-proof.

While we're at it, we rework the pipeline cache API to use the
brw_stage_prog_data type directly.

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98012
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>

intel/blorp: Pass a brw_stage_prog_data to upload_shader

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98012
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>

intel/blorp: Use wm_prog_data instead of hand-rolling our own

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98012
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>

anv: Better handle return codes from anv_physical_device_init

The case where we just want the loop to continue is INCOMPATIBLE_DRIVER
because that simply means that whatever FD we opened isn't a supported
Intel chip.  Other error codes such as OUT_OF_HOST_MEMORY are actual errors
and we should be returning early in that case.

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>

vulkan/wsi/x11: Clean up connections in finish_wsi

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>

vulkan/wsi/x11: Better handle wsi_x11_connection_create failure

Without this fix, the function would still end up returning NULL but it
would put that NULL connection in the hash table which would be bad.

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>

android: avoid using libdrm with host modules

Note LOCAL_CFLAGS and LOCAL_SHARED_LIBRARIES in Android.common.mk
are used by both host and target modules. However, commit 112e988
moved libdrm related flags to common. It causes the errors like:

error: 'out/host/linux-x86/obj32/SHARED_LIBRARIES/libdrm_intermediates/export_includes',
needed by 'out/host/linux-x86/obj32/EXECUTABLES/mesa_gen_matypes_intermediates/import_includes',
missing and no known rule to make it

No reason to use libdrm with host modules.

Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Fixes: 112e988329b ("Android: move libdrm settings to top-level
Android.common.mk")
Signed-off-by: Chih-Wei Huang <cwhuang@linux.org.tw>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

glsl: compute lvalues of [in]out parameters before inlined function body

This is required when an out argument involves an array index that is either
a global variable modified by the function or another out argument in the
same function call.

Fixes the shaders/out-parameter-indexing/vs-inout-index-inout-* tests.

v2:
- modify the ir_dereference_array nodes in place
- use ir_hierarchical_visitor
v3: use base_ir (Ian Romanick)

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

radeonsi: fix BFE/BFI lowering for GLSL semantics

Fixes spec/arb_gpu_shader5/execution/built-in-functions/*-bitfield{Extract,Insert}

Cc: 13.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

tgsi: align the definition of BFI & [UI]BFE with GLSL

As previously written, these opcodes use the SM5 semantics which is
incompatible with GLSL when bits == 0, offset == 32.

At some point we may want to add BFI_SM5 etc. opcodes, but all users
currently either want (and expect!) the GLSL semantics or don't care.

Bitfield inserts are generated by the GLSL lower_instructions and
lower_packing_builtins passes with constant bits and offset arguments,
so any workaround code that drivers may have to emit to follow GLSL
semantics should be optimized away easily for those uses.

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

radv: expose xlib platform extension

I missed this when I added the xlib code, this allows
dolphin emu to start and crash later.

Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

intel: aubinator: print field values if available

Turning this :

sampler state 0
    Sampler Disable: false
    Texture Border Color Mode: 0
    LOD PreClamp Enable: 1
    Base Mip Level: 0.000000
    Mip Mode Filter: 0
    Mag Mode Filter: 1
    Min Mode Filter: 1
    Texture LOD Bias: foo
    Anisotropic Algorithm: 0

into this :

sampler state 0
    Sampler Disable: false
    Texture Border Color Mode: 0 (DX10/OGL)
    LOD PreClamp Enable: 1 (OGL)
    Base Mip Level: 0.000000
    Mip Mode Filter: 0 (NONE)
    Mag Mode Filter: 1 (LINEAR)
    Min Mode Filter: 1 (LINEAR)
    Texture LOD Bias: foo
    Anisotropic Algorithm: 0 (LEGACY)

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Sirisha Gandikota<sirisha.gandikota@intel.com>

intel: aubinator: load fields values from xml data

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Sirisha Gandikota<sirisha.gandikota@intel.com>

intel: aubinator: print boolean fields to true with colors

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Sirisha Gandikota<sirisha.gandikota@intel.com>

amd: fix a typo in PIXEL_PIPE_STAT_RESET definition

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

gallium/radeon: add enum radeon_micro_mode

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

gallium/radeon: make it clear that DRM 2.x.x fast clear constraint is CIK-only

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

gallium/radeon: remove r600_surface::level_info

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

gallium/radeon: add radeon_surf::is_linear

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

gallium/radeon: remove radeon_surf_level::pitch_bytes

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

gallium/radeon: don't call u_format helpers if we have that info already

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

gallium/radeon: replace radeon_surf_info::dcc_enabled with num_dcc_levels

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

radeonsi: add a driver query for counting CP DMA calls

CP DMA calls are synchronous with regard to shaders, but can be made
asynchronous if needed.

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

radeonsi: add a driver query for shader cache hits

This is an 8-month old patch.

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

gbm: set up the interop extension for egl/drm

breaking libgbm -> libEGL ABI?

Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

nvc0: do not duplicate similar performance metrics

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Pierre Moreau <pierre.morrow@free.fr>

docs: add news item and link release notes for 13.0.0

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

docs: add sha256 checksums for 13.0.0

Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit 405dd26860719d800ed6134f8f985f1525f25502)

docs: Update 13.0.0 release notes

Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit df1b0a5a86bab8cd138f504942198a300753b005)

anv/device: Return DEVICE_LOST if execbuf2 fails

This makes more sense than OUT_OF_HOST_MEMORY.  Technically, you can
recover from a failed execbuf2 but the batch you just submitted didn't
fully execute so things are in an ill-defined state.  The app doesn't want
to continue from that point anyway.

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965/gen8: Fix vertex attrib upload for dvec3/4 shader inputs

The emission of vertex attributes corresponding to dvec3 and dvec4
vertex shader input variables was not correct when the <size> passed
to the VertexAttribL* commands was <= 2.

This was because we were using the vertex array size when emitting vertices
to decide if we uploaded a 64-bit floating point attribute as 1 slot (128-bits)
for sizes 1 and 2, or 2 slots (256-bits) for sizes 3 and 4. This caused problems
when mapping the input variables to registers because, for deciding which
registers contain the values uploaded for a certain variable, we use the size
and type given to the variable in the shader, so we will be assigning 256-bits
to dvec3/4 variables, even if we only uploaded 128-bits for them, which happened
when the vertex array size was <= 2.

The patch uses the shader information to only emit as 128-bits those 64-bit floating
point variables that were declared as double or dvec2 in the vertex shader. Dvec3 and
dvec4 variables will be always uploaded as 256-bits, independently of the <size> given
to the VertexAttribL* command.

From the ARB_vertex_attrib_64bit specification:

   "For the 64-bit double precision types listed in Table X.1, no default
    attribute values are provided if the values of the vertex attribute variable
    are specified with fewer components than required for the attribute
    variable. For example, the fourth component of a variable of type dvec4
    will be undefined if specified using VertexAttribL3dv or using a vertex
    array specified with VertexAttribLPointer and a size of three."

We are filling these unspecified components with zeros, which coincidentally is
also what the GL44-CTS.vertex_attrib_binding.basic-inputL-case1 expects.

v2: Do not use bitcount (Kenneth Graunke)

Fixes: GL44-CTS.vertex_attrib_binding.basic-inputL-case1 test
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97287
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

radv: drop some unused cmask info members.

These were assigned but never used.

Inspired by similiar patch in radeonsi.

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

intel: aubinator: fix printing missing gen option

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

intel: aubinator: fix assumptions on amount of required data

We require 12 bytes of headers but in some cases we just need 4.

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

intel: aubinator: don't print out blocks twice

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965: Move gen8_disable_stages to brw_upload_initial_gpu_state

3DSTATE_WM_CHROMAKEY isn't programmed anywhere else.
3DSTATE_WM_HZ_OP is programmed, then cleared by blorp during a
HZ op, so repeatedly clearing it after every blorp execution is
redundant.

Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965: Program 3DSTATE_AA_LINE_PARAMETERS in upload_invariant_state

This packet is non-pipelined and doesn't ever change across emissions.

Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

st/omx/dec: disable tunnel for size different case

When the video coded size is different from frame size, we need the result
buffers are same as coded size, which are not size compatible with encode
required size, so that simply use no tunnel for this case instead of frame
by frame converting.

Signed-off-by: Leo Liu <leo.liu@amd.com>
Cc: 13.0 <mesa-stable@lists.freedesktop.org>

st/omx/dec: result buffers size should match codec decoder size

Otherwise fails the check of matching between decoder size and buffers
size in kernel.

Signed-off-by: Leo Liu <leo.liu@amd.com>
Cc: 13.0 <mesa-stable@lists.freedesktop.org>

swr: [rasterizer] added EventHandlerFile contructor

Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>

swr: [rasterizer core] Frontend dependency work

Add frontend dependency concept in the DRAW_CONTEXT, which
allows serialization of frontend work if necessary.

Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>

swr: [rasterizer core] Refactor/cleanup backends

Used for common code reuse and simplification

Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>

swr: [rasterizer core] Remove deprecated simd intrinsics

Used in abandoned all-or-nothing approach to converting to AVX512

Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>

swr: [rasterizer archrast] Add thread tags to event files.

This allows the post-processor to easily detect the API thread and to
process frame information. The frame information is needed to
optimized how data is processed from worker threads.

Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>

glsl: use a non-malloc'd storage for short ir_variable names

Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

glsl: use the linear allocator in opt_constant_propagation

Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

glsl: use the linear allocator in opt_copy_propagation

Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

glsl: use the linear allocator in opt_copy_propagation_elements

Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

glsl: use the linear allocator in opt_dead_code_local

Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

glsl: use the linear allocator in glsl_symbol_table

no ralloc_free occurences

Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

glsl: use the linear allocator for ast_node and derived classes

Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

glsl/lexer: use the linear allocator

Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

glcpp: use the linear allocator for most objects

v2: cosmetic changes

Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com> (v1)
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (v1)

ralloc: add a linear allocator as a child node of ralloc

v2: remove goto, cosmetic changes

Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com> (v1)
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

ralloc: remove memset from ralloc_size

only do it in rzalloc_size as it was supposed to be

Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com>

ralloc: use rzalloc where it's necessary

No change in behavior. ralloc_size is equivalent to rzalloc_size.
That will change though.

Calls not switched to rzalloc_size:
- ralloc_vasprintf
- glsl_type::name allocation (it's filled with snprintf)
- C++ classes where valgrind didn't show uninitialized values

I switched most of non-glsl stuff to rzalloc without checking whether
it's really needed.

Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

ralloc: add DECLARE_RZALLOC_CXX_OPERATORS

Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Kenneth Graunke <kenneth@whiteacpe.org>

nir: zero allocated memory where needed

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

i965/fs: fill allocated memory with zeros where needed

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

i965/vec4: zero allocated memory where needed

Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>

glsl/glcpp: initialize all fields of glcpp_parser_t on creation

this fixes some of the regressions with
"ralloc: remove memset from ralloc_size"

Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>

glsl: Fix reading of uninitialized memory

Switch to use memory allocations which zero memory for places
where needed.

v2: modify and rebase on top of Marek's series (Tapani)

Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>

glsl: initialize glsl_struct_field properly

don't rely on ralloc doing memset

Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Kenneth Graunke <kenneth@whiteacpe.org>

ralloc: don't memset ralloc_header, clear it manually

time GALLIUM_NOOP=1 ./run shaders/private/alien_isolation/ >/dev/null

Before (2 takes):

real    0m8.734s    0m8.773s
user    0m34.232s   0m34.348s
sys     0m0.084s    0m0.056s

After (2 takes):

real    0m8.448s    0m8.463s
user    0m33.104s   0m33.160s
sys     0m0.088s    0m0.076s

Average change in "real" time spent: -3.4%

calloc should only do 2 things compared to malloc:
- check for overflow of "n * size"
- call memset
I'm not sure if that explains the difference.

v2: clear "parent" and "next" in the caller of add_child.

Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net> (v1)
Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com> (v1)
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (v1)

clover: Implement clGetExtensionFunctionAddressForPlatform.

Add clGetExtensionFunctionAddressForPlatform (CL 1.2).

Reviewed-by: Francisco Jerez <currojerez@riseup.net>

clover: Introduce CLOVER_EXTRA_*_OPTIONS environment variables

The options specified in the CLOVER_EXTRA_BUILD_OPTIONS shell
variable are appended to the options specified by the OpenCL program
in the clBuildProgram function call, if any.
Analogously, the options specified in the CLOVER_EXTRA_COMPILE_OPTIONS
and CLOVER_EXTRA_LINK_OPTIONS variables are appended to the options
specified in clCompileProgram and clLinkProgram function calls,
respectively.

v2:
 * rename to CLOVER_EXTRA_COMPILER_OPTIONS
 * use debug_get_option
 * append to linker options as well

v3: code cleanups

v4: separate CLOVER_EXTRA_LINKER_OPTIONS options

v5:
 * fix documentation typo
 * use CLOVER_EXTRA_COMPILER_OPTIONS in link stage

v6:
 * separate in CLOVER_EXTRA_{BUILD,COMPILE,LINK}_OPTIONS
 * append options in cl{Build,Compile,Link}Program

Signed-off-by: Vedran Miletić <vedran@miletic.net>
Reviewed-by[v1]: Edward O'Callaghan <funfunctor@folklore1984.net>

v7 [Francisco Jerez]: Slight simplification.

Reviewed-by: Francisco Jerez <currojerez@riseup.net>

clover: Pass unquoted compiler arguments to Clang

OpenCL apps can quote arguments they pass to the OpenCL compiler, most
commonly include paths containing spaces.

If the Clang OpenCL compiler was called via a shell, the shell would
split the arguments with respect to to quotes and then remove quotes
before passing the arguments to the compiler. Since we call Clang as a
library, we have to split the argument with respect to quotes and then
remove quotes before passing the arguments.

v2: move to tokenize(), remove throwing of CL_INVALID_COMPILER_OPTIONS

v3: simplify parsing logic, use more C++11

v4: restore error throwing, clarify a comment

Signed-off-by: Vedran Miletić <vedran@miletic.net>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>

i965/fs/generator: Don't use the address immediate for MOV_INDIRECT

The address immediate field is only 9 bits and, since the value is in
bytes, the highest GRF we can point to with it is g15.  This makes it
pretty close to useless for MOV_INDIRECT.  There were already piles of
restrictions preventing us from using it prior to Broadwell, so let's get
rid of the gen8+ code path entirely.

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97779
Cc: "12.0 13.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>

radeonsi: fix behavior of GLSL findLSB(0)

12.0 and older need the same fix but elsewhere.

Cc: 13.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

radeonsi: set VGT_GS_ONCHIP_CNTL on CIK and later

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Cc: 11.2 12.0 13.0 <mesa-stable@lists.freedesktop.org>

i965: Fix make check after 66fcfa6894ab6

Commit 66fcfa6894ab6 changed the vec4 version of offset() to have 3
parameters instead of 2 but the vec4_cmod_propagation test was never
updated.

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>

glsl: Improve accuracy of alpha scaling in advanced blend lowering.

When blending with GL_COLORBURN_KHR and these colors:

   dst = <0.372549027, 0.372549027, 0.372549027, 0.372549027>
   src = <0.09375, 0.046875, 0.0, 0.375>

the normalized dst value became 0.99999994 (due to precision problems
in the floating point divide of rgb by alpha).  This caused the color
burn equation to fail the dst >= 1.0 comparison.  The blue channel would
then fall through to the dst < 1.0 && src >= 0 comparison, which was
true, since src.b == 0.  This produced a factor of 0.0 instead of 1.0.

This is an inherent numerical instability in the color burn and dodge
equations - depending on the precision of alpha scaling, the value can
be either 0.0 or 1.0.  Technically, GLSL floating point division doesn't
even guarantee that 0.372549027 / 0.372549027 = 1.0.  So arguably, the
CTS should allow either value.  I've filed a bug at Khronos for further
discussion (linked below).

In the meantime, this patch improves the precision of alpha scaling by
replacing the division with (rgb == alpha ? 1.0 : rgb / alpha).  We may
not need this long term, but for now, it fixes the following CTS tests:

ES31-CTS.blend_equation_advanced.blend_specific.GL_COLORBURN_KHR
ES31-CTS.blend_equation_advanced.blend_all.GL_COLORBURN_KHR_all_qualifier

Cc: currojerez@riseup.net
Cc: mesa-stable@lists.freedesktop.org
Bugzilla: https://cvs.khronos.org/bugzilla/show_bug.cgi?id=16042
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>

mesa: rename gl_client_array -> gl_vertex_array

The term "client array" is a legacy thing dating back to the pre-VBO
era when _all_ vertex arrays lived in client memory.

Nowadays, it only contains vertex array state which is derived from
gl_array_attributes and gl_vertex_buffer_binding.  It's used by the
VBO module and some drivers.

Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

mesa: code clean-up in _mesa_update_vao_client_arrays()

Init vars where declared, use const qualifiers.

Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

mesa: update comment on vertex_attrib_binding()

Was missed in an earlier renaming patch.

Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

mesa: rename gl_vertex_array_object::VertexBinding to BufferBinding

To be a little more understandable.

Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

vulkan/wsi/x11: Smplify implementation of vkGetPhysicalDeviceSurfaceFormatsKHR

This patch simplifies x11_surface_get_formats(). It is actually just a
readability improvement over the patch I provided earlier this week
(750d8cad72).

Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>

vulkan/wsi/x11: Fix behavior of vkGetPhysicalDeviceSurfacePresentModesKHR

x11_surface_get_present_modes() is currently asserting that the number of
elements in pPresentModeCount must be greater than or equal to the number
of present modes available. This is buggy because pPresentModeCount
elements are later copied from the internal modes' array, so if
pPresentModeCount is greater, it will overflow it.

On top of that, this assertion violates the spec. From the Vulkan 1.0
(revision 32, with KHR extensions), page 581 of the PDF:

    "If the value of pPresentModeCount is less than the number of
     presentation modes supported, at most pPresentModeCount values will be
     written. If pPresentModeCount is smaller than the number of
     presentation modes supported for the given surface, VK_INCOMPLETE
     will be returned instead of VK_SUCCESS to indicate that not all the
     available values were returned."

So, the correct behavior is: if pPresentModeCount is greater than the
internal number of formats, it is clamped to that many present modes. But
if it is lesser than that, then pPresentModeCount elements are copied,
and the call returns VK_INCOMPLETE.

This fix is similar (but simpler and more readable) than the one I provided
in 750d8cad72a for vkGetPhysicalDeviceSurfaceFormatsKHR, which was suffering
from the same problem.

Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>

i965: use memory context when creating passthrough tcs

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>

intel/blorp: remove stale comment

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>

drivers/meta: Accept GL_TEXTURE_3D as target for tex image decompression

An assert is currently raised, preventing decompression of a texture image into
a GL_TEXTURE_3D target. I have not found any spec wording that would explain
this, or implementation detail that would prevent it. And in any case, the
driver should not cause a crash upon user input arguments.

Fixes most failing subcases in CTS tests:
* GL44-CTS.gtf32.GL3Tests.packed_pixels.packed_pixels_pixelstore
* GL45-CTS.gtf32.GL3Tests.packed_pixels.packed_pixels_pixelstore

These tests were crashing the driver before. Now they just fail, but due
to an unrelated issue affecting 2 out of the 45 test subcases.

No regressions observed against piglit or CTS-GL.

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

intel/blorp: Rework our usage of ralloc when compiling shaders

Previously, we were creating the shader with a NULL ralloc context and then
trusting in blorp_compile_fs to clean it up.  The only problem was that
blorp_compile_fs didn't clean up its context properly so we were leaking.
When I went to fix that, I realized that it couldn't because it has to
return the shader binary which is allocated off of that context and used by
the caller.  The solution is to make blorp_compile_fs take a ralloc
context, allocate the nir_shaders directly off that context, and clean it
all up in whatever function creates the shader and calls blorp_compile_fs.

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Cc: "12.0, 13.0" <mesa-stable@lists.freedesktop.org>

intel/blorp: Rename compile_nir_shader to compile_fs

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

radv: split the device local memory heap into two

Advertise two device local memory heaps; one that is host visible
and one that is not.

This makes it possible for clients to tell how much host visible
vs. non-host visible memory is available.

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

radv: add a write-combining host-local memory type

Add the new memory type between the two device-local types. This makes
the list of supported memory types look like this:

1) DEVICE_LOCAL |              |               |
2)              | HOST_VISIBLE | HOST_COHERENT |
3) DEVICE_LOCAL | HOST_VISIBLE | HOST_COHERENT |
4)              | HOST_VISIBLE | HOST_COHERENT | HOST_CACHED

With this order a client that searches for a HOST_VISIBLE and
HOST_COHERENT memory type using the algorithm described in section
10.2 of the Vulkan specification (revision 32) will find the host-
local memory type first.

A client that requires the memory type to be HOST_VISIBLE and
HOST_COHERENT, but not DEVICE_LOCAL is most likely searching for
a memory type suitable for staging buffers / images.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>

i965/miptree: Remove the width/height < 32768 restrictions

These restrictions existed because intel_miptree_blit couldn't handle
surfaces bigger than 32k.  How that we're chopping blits up into chunks, it
can handle any size we throw at it so we can get rid of this restriction.
This improves the terrain tests in synmark by 25-30% on my Sky Lake gt3.

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reported-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965/blit: Break blits into chunks in intel_miptree_blit

This allows us to blit much larger images than if we use the blitter
directly.  In particular, it gives us an almost infinite image height
compared to the fairly limiting 32k.  We do, however, still have a
restriction on stride of the image because handling larger strides, while
possible, is fairly difficult.

v2: Properly handle linear blit alignment restrictions

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965/blit: Break blits into chunks in set_alpha_to_one

v2: Properly handle linear blit alignment restrictions

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965/blit: Remove a bogus assertion

This assertion, while valid for linear buffers, doesn't work properly for
tiled memory.  It used to work most of the time because the offset provided
was always to the left-hand edge of the image.  However, if you use a byte
offset to get to the inside of the image, the height * stride calculation
may actually end up being too large.

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965/miptree: Break miptree -> ISL tiling conversion into a helper

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965/miptree: Remove the stencil_as_y_tiled parameter from get_aligned_offset

The only actual user of this parameter was blorp and, since the conversion
to ISL, it no longer uses this function.

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

intel/blorp: Fix a couple asserts around image copy rectangles

With dealing with rectangles in compressed images, you can have a width or
height that isn't a multiple of the corresponding compression block
dimension but only if that edge of your rectangle is on the edge of the
image.  When we call convert_to_single_slice, it creates an 2-D image and a
set of tile offsets into that image.  When detecting the right-edge and
bottom-edge cases, we weren't including the tile offsets so the assert
would misfire.  This caused crashes in a few UE4 demos

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reported-by: "Eero Tamminen" <eero.t.tamminen@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98431
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Tested-by: "Eero Tamminen" <eero.t.tamminen@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>

anv/allocator: Assert that we have a valid gem handle in bo_pool_alloc

nvc0/ir: fix emission of IMAD with NEG modifiers

The emitter tried to emit sub instead of subr when src0 has
actually a NEG modifier.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "11.0 12.0 13.0" <mesa-stable@lists.freedesktop.org>

glsl: inspect interfaces in contains_foo()

When checking if a type contains doubles, integers, samples, etc. we
check if the current type is a record or array, but not if it is an
interface.

This commit also inspects if the type is an interface.

It fixes spec/arb_enhanced_layouts/compiler/transform-feedback-layout-qualifiers/xfb_offset/invalid-block-with-double.vert
piglit test.

Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>

i965/vec4: make offset() work in terms of a simd width and scalar components

So that it has the same semantics as the scalar backend implementation. The
helper will now take a simd width (which is always 8 in vec4 mode) and step
as many scalar components as specified by that width, respecting the size of
the scalar channels.

v2 (Curro):
  - Remove the assertion in offset(), byte_offset() has the same checks.
  - Use byte_offset() directly instead of add_byte_offset().
  - Make things more clear by explicitly including the vertical stride
    in the byte offset expression.

Reviewed-by: Francisco Jerez <currojerez@riseup.net>