Fixes OOMs in the CTS's packed_pixels.varied_rectangle.* tests -- the
series of texture uploads at the start before texturing occurred would end
up all sitting around as cached jobs for reuse.  By flushing immediately,
peak active BO usage goes from 150M to 40M.

We could maybe put some limits on how many jobs we keep around, but blits
seem particularly unlikely to get reused for other drawing.

This is the GLES 3.2 minmax, and also what the closed source driver does.
Avoids hitting OOMs in the CTS's
dEQP-GLES3.functional.texture.units.all_units.only_cube.1.

We don't want to pull the compiler into every include in the gallium
driver, so just make a new little header to store the limits.

We want one vector size per vector, not per component.

The compiler has its limits under V3D_* (like most V3D stuff), so sync up
with that.

Trivial.

From the vulkan spec 33.3 "Extension Dependencies":

"Any device extension that has an instance extension dependency that is
not enabled by vkCreateInstance is considered to be unsupported, hence
it must not be returned by vkEnumerateDeviceExtensionProperties for any
VkPhysicalDevice child of the instance."

Therefore we need to check whether the instance-level extensions are
actually enabled when deciding to support a device-level extension or
not.

Furthermore, we need to do this for all instance-level extensions of any
(transitive) device-level extension dependency, due to the following
paragraph:

"If an extension is supported (as queried by
vkEnumerateInstanceExtensionProperties or
vkEnumerateDeviceExtensionProperties), then required extensions of that
extension must also be supported for the same instance or physical
device."

Finally, because some of these vulkan extensions may be implicitly
promoted to future vulkan core API versions, we can also satisfy the
dependency if the vulkan API version is high enough.

Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>

From the vulkan spec 3.2 "Instances":

"Providing a NULL VkInstanceCreateInfo::pApplicationInfo or providing an
apiVersion of 0 is equivalent to providing an apiVersion of
VK_MAKE_VERSION(1,0,0)."

Fixes: ffa15861ef "radv: UseEnumerateInstanceVersion for the default version."
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>

Section 7.6.2.2 (Standard Uniform Block Layout) of the GL spec says:

    The base offset of the first member of a structure is taken from the
    aligned offset of the structure itself. The base offset of all other
    structure members is derived by taking the offset of the last basic
    machine unit consumed by the previous member and adding one.

The current code does not reflect this last sentence - it effectively
instead aligns up the next offset up to the alignment of the previous
member. This causes an issue in exactly one case:

layout(std140) uniform block {
    layout(offset=0) vec3 var1;
    layout(offset=12) float var2;
};

As per section 7.6.2.1 (Uniform Buffer Object Storage) and elsewhere, a
vec3 consumes 3 floats, i.e. 12 basic machine units. Therefore, `var1`
in the example above consumes units 0-11, with 12 being the first
available offset afterwards. However, before this commit, mesa
incorrectly assumes `var2` must start at offset=16 when using explicit
offsets, which results in a compile-time error. Without explicit
offsets, the shaders actually work fine, indicating that mesa is already
correctly aligning these fields internally. (Just not in the code that
handles explicit buffer offset parsing)

This patch should fix piglit tests:
ssbo-explicit-offset-vec3.vert
ubo-explicit-offset-vec3.vert

Signed-off-by: Niklas Haas <git@haasn.xyz>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>

Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>

This only implements the actual opcodes and does not implement support
for using them with specialization constants.

Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>

We handle forward declarations by creating the pointer type with it's
storage type based on storage class and just waiting to fill out the
actual deref type until we get the OpTypePointer.  Because any
composites using the forward declared type only care about the storage
type (i.e. uint64_t, uvec2, etc.) when creating their glsl_type, this
works fine and we can defer the actual deref_type as far as we need.

Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Karol Herbst <kherbst@redhat.com>

This was valid back when the only valid types of pointers were uint32
and uvec2.  Now that we're allowing more variety, it could be just about
anything so we'll just drop the assert.

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Karol Herbst <kherbst@redhat.com>

Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>

Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Karol Herbst <kherbst@redhat.com>

Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Karol Herbst <kherbst@redhat.com>

These are simple scalar addresses.

Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>

These correspond roughly to reading/writing OpenCL global pointers.  The
idea is that they just take a bare address and load/store from it.  Of
course, exactly what this address means is driver-dependent.

Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Karol Herbst <kherbst@redhat.com>

We want to have debug info as well if using
meson's debugoptimized when ndebug is off.

v2: use u_debug functions that do something
even if DEBUG is not set.

Signed-off-by: Axel Davy <davyaxel0@gmail.com>

Fixes regression caused by
42d672fa6a
st/nine: Bind src not dst in nine_context_box_upload

Before that patch, for user provided textures,
when the texture was destroyed, the safety
check for pending uploads, which according to
the code "Following condition cannot happen currently",
was flushing the queue and thus triggering the upload.

After the patch, the texture destruction was delayed after
the upload. However the user frees the texture buffer,
as it thinks the texture released.

Instead of reverting the faulty patch,
this patch instead flushes the csmt queue right away
after queuing the upload for this type of textures.
This is more future-proof, as we may want to bind the
surface for other reasons in the future.

Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Cc: 18.3 <mesa-stable@lists.freedesktop.org>

Compilation of user-specified shaders with software fp64 works by
compiling on demand an "fp64-funcs" shader implementing various fp64
operations and then linking it into the "user shader".

In

   commit 64b8c86d37
   Author: Timothy Arceri <tarceri@itsqueeze.com>
   Date:   Thu Jan 17 17:16:29 2019 +1100

       glsl: be much more aggressive when skipping shader compilation

we changed the behavior of the shader cache to skip compilation earlier
when we get a cache hit.

After the aforementioned commit, compiling a user program using fp64
would store into the cache an entry for the fp64-funcs shader.
Subsequent compilations of uncached user shaders using fp64 would fail
in compile_fp64_funcs() after finding a cache entry for the fp64-funcs,
but being unprepared to read from the cache.

It's unclear to me how to retrieve the cached NIR of the fp64-funcs (if
it even is cached), so just call _mesa_glsl_compile_shader() with
force_recompile=true in order to ensure we generate the fp64-funcs
successfully.

Tested-by: Mark Janes <mark.a.janes@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Acked-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>

This allows creating a fd_screen with a renderonly object which will be
used to allocated scanout resources.

Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Reviewed-by: Eric Anholt <eric@anholt.net>
[slight tweak to fix uninitialized 'prsc' in debug print]
Signed-off-by: Rob Clark <robdclark@gmail.com>

Signed-off-by: Rob Clark <robdclark@gmail.com>

The semantic was removed in e6d9389366.

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

Fixes the following piglit test on my VEGA and matches the behaviour in the
tgsi backend.

tests/spec/glsl-1.10/execution/samplers/glsl-fs-shadow2D-clamp-z.shader_test

Fixes: 625dcbbc45 ("amd/common: pass address components individually to ac_build_image_intrinsic")

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

The util helpers were looking for a non-void channels in a non-mixed
format and returning its snorm/unorm state.  However, compressed formats
don't have non-void channels, so they always returned false.  V3D wants to
use util_format_is_[su]norm for its border color clamping workarounds, so
fix the functions to return the right answer for these.

This now means that we ignore .is_mixed.  I could retain the is_mixed
check, but it doesn't seem like a useful feature -- the only code I could
find that might care is freedreno's blit, which has some notes about how
things are wonky in this area anyway.

Reviewed-by: <Roland Scheidegger sroland@vmware.com>

Two typos, and missing one of the colorspaces.

Reviewed-by: <Roland Scheidegger sroland@vmware.com>

These tests don't need swrast, so we can always enable them when
build_tests is set.  Most of them run to successful completion quickly
(.9s on my SKL).

Reviewed-by: <Roland Scheidegger sroland@vmware.com>

Earlier commit aimed to remove unneeded function declarations. Namely
OpenGL entrypoints which are not applicable for OpenGLES*

Although it did not consider the shared glapi which needs all,
including hidden ones. Resulting in warning/errors like the following

../build/src/mapi/shared-glapi/glapi_mapi_tmp.h:26014:15:
error: no previous prototype for ‘shared_dispatch_stub_1414’ [-Werror=missing-prototypes]

This patch addressed that.

Cc: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reported-by: Eric Anholt <eric@anholt.net>
Fixes: 6148cce388 ("mapi: drop unneeded gl_dispatch_stub declarations")
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Acked-by: Eric Anholt <eric@anholt.net>

1ce5d757d0 dropped this limit.. which is probably the right thing to
do.  But it results in an extra tiled->linear blit for glReadPixels()
(ie. dEQP/piglit) which is hitting some intermittent corruption (looks
like cache) on a6xx, causing a lot of spurious fails.

Since we are getting close to 19.0 branchpoint, re-instate this limit
for now, until the blitter problems are resolved.

Fixes: 1ce5d757d0 freedreno: core buffer modifier support
Signed-off-by: Rob Clark <robdclark@gmail.com>

Streamout buffers are emitted like push constants.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>

This reverts commits 00ad77b9f6 and
5334dafee2.

This avoids Appveyor build breakage due to Cygwin, but more importantly,
there are several problems with these patches, as highlighted to my
recent mesa-dev mail.  So better to revert for now, and pursue Cygwin
support after these have been address.

We need this include path to find nir/nir_xfb_info.h.

Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>

According to the loop implementation (in 'ctx_print_buffer' function),
which advances dword by dword over vertex buffer(vb),
the vb size should be aligned by 4 bytes too.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109449
Signed-off-by: Andrii Simiklit <andrii.simiklit@globallogic.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

It should be incremented by one according to
how it is calculated by 'emit_vertex_buffer_state':
  "\#if GEN_GEN < 8
      .BufferAccessType = step_rate ? INSTANCEDATA : VERTEXDATA,
      .InstanceDataStepRate = step_rate,
   \#if GEN_GEN >= 5
      .EndAddress = ro_bo(bo, end_offset - 1),
   \#endif
   \#endif"

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109449
Signed-off-by: Andrii Simiklit <andrii.simiklit@globallogic.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

This mirrors what autotools does in src/gallium/state_trackers/vdpau/Makefile.am
and src/gallium/targets/vdpau/Makefile.am:

  VDPAU_MAJOR = 1
  VDPAU_MINOR = 0
  libvdpau_gallium_la_LDFLAGS = -version-number $(VDPAU_MAJOR):$(VDPAU_MINOR)

Reported-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
Fixes: 68076b8747 "meson: build gallium vdpau state tracker"
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>

Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>

Accessing bo->map and then pool->center_bo_offset without a lock is
racy. One way of avoiding such race condition is to store the bo->map +
center_bo_offset into pool->map at the time the block pool is growing,
which happens within a lock.

v2: Only set pool->map if not using softpin (Jason).
v3: Move things around and only update center_bo_offset if not using
softpin too (Jason).

Cc: Jason Ekstrand <jason@jlekstrand.net>
Reported-by: Ian Romanick <idr@freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109442
Fixes: fc3f588320
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>

ICC tries to be helpful by not erroring when it sees something that it
doesn't understand, which is completely the opposite of helpful. Meson
0.49.0 does much better at handling this by really trying to make ICC
error, but there are some things in mesa that still get ignored until
0.49.1

v2: - Fix id check, which is 'intel' not 'icc'

Cc: 18.3 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> (v1)

This is a bit fragile, as the way this "fixes" the check is to move the
one that we know is correct before the one that is incorrectly reported
as working. In meson 0.49.1 (which isn't out yet) this is fixed that the
incorrect check is reported as a failure.

Fixes: e0b037d697
       ("meson: Build SWR driver")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109129
Acked-by: Eric Engestrom <eric.engestrom@intel.com>

There's a typo in one of the #defines that breaks compilation.

Fixes: e0b037d697
       ("meson: Build SWR driver")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109023
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>

LLVM uses the single instruction "FRINTI" to implement llvm.nearbyint.
Fixes the rounding tests of lp_test_arit.

Bug: https://bugs.gentoo.org/665570
Reviewed-by: Roland Scheidegger <sroland@vmware.com>

NEON (now called ASIMD) is available on all aarch64 CPUs. Our code was
missing an aarch64 path, leading to util_cpu_caps.has_neon always being
false on aarch64.

Reviewed-by: Eric Anholt <eric@anholt.net>

This fixes the drisw paths to use the new shm2 interface, so that
we don't trigger the X server overflow checks when the x offset is non-zero.

This just hides the versioning in drisw, and either passes the src_x
or adds the offset fixup for the fallback path.

Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>

v2: pass x,0 in as the offset coords at glx level not earlier

Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>

This adds a new interface to the swrast interface to fix an shm put image bug.

The current code adds the x,y src offsets into the offset parameters,
however if the x offset is > 0, and the put image copies up to the height
of the image, this can trigger an X server validation check to fail and
the renderering to get BadMatch.

This patch fixes it to pass the x offset coord in as a src x.

We cannot pass the Y coordinate due to the horrible code mangling the
image w/h vs stride in swrastXPutImage.

v2: drop srcx,y from api

Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>

We haven't have one in years, so just drop the code.

Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>

As of earlier commit, everyone has switched to the new script for the ES
dispatch.

Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>