Instead of baking in uvec2 for UBO and SSBO pointers and uint for push
constant and shared memory pointers, make it configurable.

This new pass is for lowering explicitly laid out memory coming in from
SPIR-V or a similar source.  It's quite a bit more complicated than the
normal lower_io because we have to be able to handle matrices.  The
way the stride information is stored for matrices is awkward and dealing
with row-major matrices is especially painful.

We already detect any incomplete deref chains (where the deref is used
for something other than another deref or a load/store) and flag the
variable as used thanks to deref_used_for_not_store.  All that's left to
do is to properly skip casts when cleaning up.

The code which constructs deref paths already gives you the path
starting at the nearest deref_cast or deref_var.  All we need to do is
handle the case where the start of the path isn't a deref_var.

This commit adds a new num_components value for intrinsic sources of -1
which means that it consumes everything and the number of components
effectively isn't validated.  This is useful for deref sources which
just take the result of the deref and we leave it up to the driver to
decide what that size should be.

Alejandro Piñeiro authored Oct 22, 2018 and Faith Ekstrand committed Nov 30, 2018

We need all the info when asking for the type, so we needed to call
type_decoration_cb earlier, in order to get the ArrayStride.

It is somewhat ugly to do this only for Array types, but we can't do
it before the switch as type_decoration_cb have some asserts to ensure
that the type and the decoration are compatible.

One alternative would be keep the call to type_decoration_cb at the
end, but create the glsl type for Arrays at the end, after calling
it. Again we are treating Arrays in a different way.

A full alternative to treat all types in the same way would be have a
first switch(opcode) that would fill the base_type, call
type_decoration_cb, and then a new switch(opcode) that would fill
extra data and create the glsl_type. That looks like an overkill
though.

Alejandro Piñeiro authored Oct 22, 2018 and Faith Ekstrand committed Nov 30, 2018

>From ARB_gl_spirv:
    "Mapping of layouts

      std140/std430  ->  explicit *Offset*, *ArrayStride*, and *MatrixStride*
                         Decoration on struct members"

That means that we would not have available any kind of layout info,
and we should use explicit array strides.

This commit adds explicit_array_stride. The default value is -1
meaning that it is not set (as with offset). That should be the
default value for GLSL.

In general, the default constructor is ok. We just need to be careful
with some array lowerings, as it should try to get the explicit array
stride when creating new types.

Note that this means that for the ARB_gl_spirv case
std430_array_stride, std140_size etc are meaningless (unless you guess
the layout, something that you shouldn't).

v2: add missing glsl_full_array_type call, found while testing
    ARB_gl_spirv with borrowed tests (Alejandro)

Alejandro Piñeiro authored Oct 22, 2018 and Faith Ekstrand committed Nov 30, 2018

>From ARB_gl_spirv spec:

    "7.6.2.spv SPIR-V Uniform Offsets and Strides

    The SPIR-V decorations *GLSLShared* or *GLSLPacked* must not be
    used. A variable in the *Uniform* Storage Class decorated as a
    *Block* must be explicitly laid out using the *Offset*,
    *ArrayStride*, and *MatrixStride* decorations. If the variable is
    decorated as a *BufferBlock*, its offsets and strides must not
    contradict std430 alignment and minimum offset requirements.
    Otherwise, its offsets and strides must not contradict std140
    alignment and minimum offset requirements.

>From that paragraph, the first conclusion is that we can rely on the
content of the SPIR-V in order to compute the buffer sizes, as they
are mandatory. That would make the buffer size computation easier. The
second conclusion, from the last sentence, is that *we need* to do
that. As if just needs to not contradict alignments and minimum
offsets, providing a matrix stride of 16 when 8 is enough would be
valid.

This explicit matrix_stride is assumed to only be used on
ARB_gl_spirv. On GLSL there is no way to set it, and it is internally
handled and computed.

Alejandro Piñeiro authored Oct 22, 2018 and Faith Ekstrand committed Nov 30, 2018

To already existing fields on glsl_types. Specifically:
   * glsl_get_struct_field_offset
   * glsl_get_struct_field_matrix_layout
   * glsl_type_arrays_of_arrays_size

This simplifies our deref handling by emitting the actual NIR deref
instructions on-the-fly instead of of building up a deref chain and then
emitting them at the last moment.  In order for this to work with the
parts of the compiler that assume they can chase deref chains, we have
to run nir_rematerialize_derefs_in_use_blocks_impl to put the derefs
back in the right places in cases like loops where dominance may not
quite work out the way SPIR-V thinks it does.

Pipeline state pending bits should be taken into account when copying
results.

In the particular bug below, the results of the
vkCmdCopyQueryPoolResults() command was being overwritten by the
preceding vkCmdCopyBuffer() with a same destination buffer. This is
because we copy the buffers using the 3D pipeline whereas we copy the
query results using the command streamer. Those pieces of HW work in
parallel and the results are somewhat undefined.

v2: Unconditionally flush the pipeline before copying the results
    (Jason)

v3: Wrap & expressions (Jason)

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Suggested-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108894
Cc: mesa-stable@lists.freedesktop.org

I didn't mean to push this. I don't think it makes any difference.

This reverts commit f737fe00.

The calculated length of a line may be infinite, if the coords we
get are bogus. This leads to an infinite loop in line stippling.
To prevent this test for this explicitly (although technically
on at least x86 sse it would actually work without the explicit
test, as long as we use the int-converted length value).
While here also get rid of some always-true condition.

Note this does not actually solve the root cause, which is that
the coords we receive are bogus after clipping. This seems a difficult
problem to solve. One issue is that due to float arithmetic, clip w
may become 0 after clipping if the incoming geometry is
"sufficiently degenerate", hence x/y/z ndc (and window) coords will
be all inf (or nan). Even with w not quite 0, I believe it's possible
we produce values which are actually outside the view volume.
(Also, x=y=z=w=0 coords in clipspace would be not considered subject
to clipping, and similarly result in all NaN coords.) We just hope for
now other draw stages (and rasterizers) can handle those relatively
safely (llvmpipe itself should be sort of robust against this, certainly
converstion to fixed point will produce garbage, it might fail a couple
assertions but should neither hang nor crash otherwise).

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

Józef Kucia authored Nov 26, 2018 and Lionel Landwerlin committed Nov 29, 2018

Signed-off-by: Józef Kucia <joseph.kucia@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

Update to the internal master as of 2018-11-15.

This has a lot of gratuitous whitespace change, but on the plus
side it's built using the same tooling that's used for AMDVLK,
which should help going forward.

Our choices here are simply redundant as long as sin.flags is set
correctly.

(v2:
- remove unused function parameter)
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

v2:
- use SI_CONTEXT_REG_OFFSET

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

The ioctl.cap_3d member was never freed.

Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

Free the context after destruction.

Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

Viewport/scissor don't need to be updated for array textures.

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

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

If all layers are bound we can perform a fast color or depth clear
instead of iterating over all layers. This has the advantage
to avoid trashing the framebuffer for nothing if you we end up by
doing a fast clear when calling radv_clear_image_layer(), and
clearing all layers in one shot is obviously faster.

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

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

Currently only true if RADV_PERFTEST=dccmsaa is set.

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

For further optimisations.

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

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

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

The driver doesn't support DCC/CMASK for mipmapped textures.

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

Fix build error.

  CXXLD    pipe_msm.la
../../../../src/gallium/drivers/freedreno/.libs/libfreedreno.a(freedreno_batch.o): In function `batch_init':
src/gallium/drivers/freedreno/freedreno_batch.c:54: undefined reference to `fd_device_version'
src/gallium/drivers/freedreno/freedreno_batch.c:59: undefined reference to `fd_submit_new'
src/gallium/drivers/freedreno/freedreno_batch.c:61: undefined reference to `fd_submit_new_ringbuffer'
src/gallium/drivers/freedreno/freedreno_batch.c:64: undefined reference to `fd_submit_new_ringbuffer'
src/gallium/drivers/freedreno/freedreno_batch.c:66: undefined reference to `fd_submit_new_ringbuffer'
src/gallium/drivers/freedreno/freedreno_batch.c:70: undefined reference to `fd_submit_new_ringbuffer'

Fixes: b4476138 ("freedreno: move drm to common location")
Fixes: aa0fed10 ("freedreno: move ir3 to common location")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Rob Clark <robdclark@gmail.com>

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

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