GitLab

Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>

Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>

Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>

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>

so that it can be used in parallel IBs.

This also removes the SO_FILLED_SIZE hack.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

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

Fixes: 912a9c8d

Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Cc: 19.0 <mesa-stable@lists.freedesktop.org>

`EGLDisplay` variables (the opaque Khronos type) have mostly been
consistently called `dpy`, as this is the name used in the Khronos
specs.

However, `_EGLDisplay` variables (our internal struct) have been
randomly called `dpy` when there was no local variable clash with
`EGLDisplay`s, and `disp` otherwise.

Let's be consistent and use `dpy` for the Khronos type, and `disp`
for our struct.
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Acked-by: Eric Anholt <eric@anholt.net>

Until the kernel side matures and the full driver is upstreamed, to
avoid end-user surprises, Panfrost should only be built for the
adventurous.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Eric Anholt <eric@anholt.net>

I had a single function for "does this do float input unpacking" with two
major flaws: It was missing the most common thing to try to copy propagate
a f32 input nunpack to (the VFPACK to an FP16 render target) along with
several other ALU ops, and also would try to propagate an f32 unpack into
a VFMUL which only does f16 unpacks.

instructions in affected programs: 659232 -> 655895 (-0.51%)
uniforms in affected programs: 132613 -> 135336 (2.05%)

and a couple of programs increase their thread counts.

The uniforms hit appears to be a pattern in generated code of doing (-a >=
a) comparisons, which when a is abs(b) can result in the abs instruction
being copy propagated once but not fully DCEed.

Avoids a regression in
dEQP-GLES3.functional.shaders.derivate.fwidth.texture.* once we start
copy-propagating more input packs.

We want to be able to copy propagate our texture unpacks into the vfpack.

We were trying to print a NULL entry from the table.

If you only bound rt 1+, we'd still emit a write to the rt0 that isn't
present (noticed while debugging an
ext_framebuffer_multisample-alpha-to-coverage-no-draw-buffer-zero
regression in another change).

I was just leaving the other MRT targets than DATA0 out, by accident.

Fixes: cdc53fa8

Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Kristian H. Kristensen <hoegsberg@chromium.org>

Iris would like to use compact arrays for tesslevels and clip/cull
distances.  radeonsi will likely want to switch to these at some point,
since it'll be necessary for GL_ARB_gl_spirv support, but it's not ready
for them just yet.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

Today, st always sets LowerCombinedClipCullDistance, causing the GLSL IR
lowering to run, giving us vec4[2] arrays.  I would like to disable this
and instead run the NIR lowering so that we get compact float[] arrays
instead.

Calling the new pass is a noop if the GLSL IR pass has already run, so
it's safe to call the pass unconditionally.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

Compact arrays are used for special variables like clip and cull
distances, or tessellation levels.  Drivers using compact arrays
assume that these values will always be actual arrays.  We don't
want to turn a float[1] gl_CullDistance into a single float; that
would confuse drivers.

Today, i965 uses compact arrays, and Gallium drivers use
nir_lower_io_arrays_to_elements, so we haven't had any overlap
that would demonstrate the issue.  Iris will use both.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

A couple places in st/nir assume that cull distances have been lowered
away, so it will need to call this lowering pass for drivers which opt
out of the GLSL IR lowering.  The Intel backend also calls this pass,
for i965 and anv.  We need to only do it once.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

We have a GLSL IR pass to convert clip/cull distance float[] arrays
into vec4[2] arrays.  In ff281e62

, we attempted to skip this pass
if the GLSL IR lowering had already run.  But, that code was not quite
right, as we forgot to strip away the per-vertex IO array layer for
geometry and tessellation shader varyings.

If the GLSL IR pass has run, the variables will not be marked as
"compact".  So we can simply check that and bail.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

nir_lower_clip_cull_distance_arrays() marks the combined clip/cull
distance array as compact.  However, when translating in from GLSL
or SPIR-V, we were not marking the original float[] arrays as compact.

We should do so.  That way, we can detect these corner cases properly.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

radeonsi uses a system value for gl_FragCoord rather than an input var.
These get translated into load_frag_coord NIR intrinsics, which lose the
pixel_center_integer and origin_upper_left decorations.  To cope with
this, Tim added a shader_info field for pixel_center_integer, and made
glsl_to_nir set it accordingly.

prog_to_nir also needs to handle these fragcoord conventions.  Instead
of duplicating the logic to set the info field, just move it to
nir_lower_system_values so it'll happen regardless of who makes the NIR.

(For what it's worth, we don't need an info flag for origin_upper_left,
because radeonsi lowers origin conventions in nir_lower_wpos_ytransform
before nir_lower_system_values destroys the variable and qualifiers.)
Reviewed-by: Eric Anholt <eric@anholt.net>

Some drivers, such as radeonsi, use a system value for gl_FragCoord
rather than an input variable.  In this case, our Mesa IR will have
a PROGRAM_SYSTEM_VALUE register, which we need to translate.

This makes prog_to_nir work for Gallium drivers which expose the
PIPE_CAP_TGSI_FS_POSITION_IS_SYSVAL capability bit.
Reviewed-by: Eric Anholt <eric@anholt.net>

We can simply iterate the bits rather than using util_last_bit and
checking each one up until that point.
Reviewed-by: Eric Anholt <eric@anholt.net>

Acked-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Rob Clark <robdclark@gmail.com>
Tested-by: Eric Anholt <eric@anholt.net>

Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Rob Clark <robdclark@gmail.com>
Tested-by: Eric Anholt <eric@anholt.net>

We implement the basic VS and FS, as well as the VS that does layered
clears by writing gl_Layer from the vertex shader.  Drivers which need
a geometry shader for writing layer continue falling back to TGSI, as
I didn't need this and so didn't bother implementing it.  (We certainly
could, however, if people want to add it in the future.)
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Rob Clark <robdclark@gmail.com>
Tested-by: Eric Anholt <eric@anholt.net>

Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Rob Clark <robdclark@gmail.com>
Tested-by: Eric Anholt <eric@anholt.net>

This provides a native NIR version of the DrawPixels/Bitmap passthrough
vertex shader.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Rob Clark <robdclark@gmail.com>
Tested-by: Eric Anholt <eric@anholt.net>

The state tracker generates several built-in shaders in order to
perform scissored clears, upload/download PBOs, and so on.  These
are currently constructed using TGSI, using ureg and u_simple_shader.

I want to have NIR versions of these shaders, for my Gallium driver
that has a NIR backend but no TGSI support.  To that end, we'll want
a few helpers to help construct simple shaders.

This patch adds two new helpers:

- st_nir_finish_builtin_shader() takes a manually constructed NIR
  shader, applies lowering passes (like st_link_nir would do for GLSL),
  and constructs the pipe_shader_state.

- st_nir_make_passthrough_shader() makes a simple passthrough shader,
  which copies inputs to outputs.  This is similar to u_simple_shaders.

v2: Set info->fs.untyped_color_outputs for vc4/v3d (thanks Eric!).
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Rob Clark <robdclark@gmail.com>
Tested-by: Eric Anholt <eric@anholt.net>

I want to reuse this for built-in shaders.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Rob Clark <robdclark@gmail.com>
Tested-by: Eric Anholt <eric@anholt.net>

They are effectively (&x)[0] or *&x which does nothing.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

Ken's rework of mesa/st builtins to NIR means that we'll have more NIR
shaders with color output types that are mismatched with the render target
types.  Since this is behavior that GLSL doesn't require, add it as a
shader_info option so the driver can know that it needs to ignore the FS
output's base type in favor of the actual render target's.  This prevents
needing additional variants in several mesa/st paths (clear, pbo upload,
pbo download), given that the driver already has to handle the variants
for any TGSI being passed to it (from u_blitter, for example).
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Cc: Jason Ekstrand <jason@jlekstrand.net>
Fixes: 927ba12b

 ("anv/tests: Adding test for the state_pool padding.")
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com&gt;&lt;Paste>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>

gives me an performance boost of 0.2% in pixmark_piano on my gk106, gm204 and
gp107.

reduces the amount of generated convert instructions by roughly 30% in
shader-db.

v2: only for 32 bit operations
    move some common code out of the switch
    handle OP_SAT with modifiers
v3: only for registers and const memory
    rework if clauses
    merge isCvt into this patch
v4: merge isCvt into its use
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>

When Mesa is compiled for gallium-xlib using e.g.
./configure --enable-glx=gallium-xlib --disable-dri --disable-gbm
-disable-egl
and is used by an X server (usually remotely via SSH X11 forwarding)
that does not support MIT-SHM such as XMing or MobaXterm, OpenGL
clients report error messages such as
Xlib:  extension "MIT-SHM" missing on display "localhost:11.0".
ad infinitum.

The reason is that the code in src/gallium/winsys/sw/xlib uses
MIT-SHM without checking for its existence, unlike the code
in src/glx/drisw_glx.c and src/mesa/drivers/x11/xm_api.c.
I copied the same check using XQueryExtension, and tested with
glxgears on MobaXterm.

This issue was reported before here:
https://lists.freedesktop.org/archives/mesa-users/2016-July/001183.html

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Cc: <mesa-stable@lists.freedesktop.org>