GitLab

Gallium's background as a Tungstend Graphics technology is no longer
significant; it's a historical detail. Besides, since Tungsten Graphics
were acquired by VMware more than a decade ago, the website no longer
exists.

While we're at it, replace the docs link with a link to the mesa docs,
and point to archive.org copy of the Tungsten Graphics paper.

Closes: mesa/mesa#2770

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Part-of: <mesa/mesa!10452>

For unsigned comparisons with zero these ops can be eliminated.

v2: Add comparison optimizations with -1 (Rhys Perry)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net> (v1)
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <mesa/mesa!10583>

NIR provides two helper macros to run transformation passes correctly,
NIR_PASS() and NIR_PASS_V(). So far we've seemingly been a bit haphazard
about when to use them.

Let's correct that, and consistently use the NIR helpers here. This
helps us in two ways:

1. We now run nir_validate_shader after each pass, ensuring we didn't
   break the shader
2. We now respect the NIR_PRINT environment variable for all NIR passes,
   making debugging much less surprising.

In addition, we had an OPT()-macro that doesn't seem to provide much
help other than to hiding some trivial details. But they make our code
different to other users of NIR, which doesn't seem ideal. So let's drop
that macro while we're at it.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <mesa/mesa!10585>

Just to make it consistent compared to ACO.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <!10432>

cores_per_L3 was uninitialized, so it was always disabled.
Remove the variable and do it differently.

Fixes: 11d2db17

 - util: rework AMD cpu L3 cache affinity code.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <!10526>

Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <mesa/mesa!10526>

This isn't needed anymore.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <mesa/mesa!9721>

This just moves to the common code in the compiler.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <mesa/mesa!9721>

This is ported from i965, but the interface is cleaned up
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <mesa/mesa!9721>

Step one to moving the ff_gs emitter to compiler for sharing,
move BRW_MAX_SOL_BINDINGS up so the keys are in same area
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <mesa/mesa!9721>

Part-of: <mesa/mesa!10597>

We've had about 1/day of the texelfetch group in the IRC flake reports
since apr 23, and tex-miplevel-selection that I marked before is actually
all the subtests it looks like.  Also, you can't include the ",Fail" if
you want to actually match a test name.

Part-of: <mesa/mesa!10597>

In the review, Roland says, "I think the unused nan behaviors was there
just for completeness, so it can easily go."
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <mesa/mesa!10532>

Since the second source is always a constant that is known to be a
number, this should have the same performance as
GALLIVM_NAN_BEHAVIOR_UNDEFINED.

A lofty goal is to eventually remove GALLIVM_NAN_BEHAVIOR_UNDEFINED.
There's still a lot of (mostly implicit) users, and I don't feel like
tackling that right now. :)
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <mesa/mesa!10532>

If it is known that one of the source must be a number, then the (more
efficient) GALLIVM_NAN_RETURN_OTHER_SECOND_NONNAN path can be used.

v2: s/know to be/known to be/.  Noticed by Roland.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <mesa/mesa!10532>

Like softpipe in mesa!10419, llvmpipe suffers from improper handling
of NaN in nir_op_fmax and nir_op_fmin.  nir_op_fsat is already handled
correctly.  OpenCL strictly requires the "NaN cleansing" behavior, so
all of the functionality is in place.  Just make the graphics APIs use
the OpenCL path.

The majority of the possible performance penalty incurred here should
be resolved in the next commit.

v2: Add updated checksum for bgfx/39-assao.rdc trace.  Rendering goes
from mostly garbage to looking correct to me.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <mesa/mesa!10532>

I don't know what I was thinking when I wrote 939bf7a4 ("tgsi_exec:
Fix NaN behavior of min and max") and d1c0f62b

 ("tgsi_exec: Fix NaN
behavior of saturate").  I knew that C99 had fmin and fmax... I just
forgot to use them.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <mesa/mesa!10532>

There's a recently discovered HW bug affecting hardware at least as far
back as Skylake where, if the LOD is out-of-bounds for any SIMD lane,
then garbage may be returned in all SIMD lanes.  The easy solution is to
set lower_txs_lod so that we always have a constant LOD of 0 which we
know a priori is always in-bounds.  Fortunately, not many shaders
actually use textureSize() with LOD.

Shader-db results on Ice Lake:

    total instructions in shared programs: 19948537 -> 19948564 (<.01%)
    instructions in affected programs: 3859 -> 3886 (0.70%)
    helped: 0
    HURT: 7

One of the shaders is in Civilization: Beyond Earth, and the rest are
all in Civilization VI.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Cc: mesa-stable@lists.freedesktop.org
Part-of: <mesa/mesa!10538>

The source_depth_to_render_target flag can get set on old gen4-5 HW in a
few cases which are independent of the app writing gl_FragDepth.  It
should be safe to just use fetch_payload_reg in that case instead of
depending in interpolation setup.  This fixes a bug with certain very
simple shaders where we might end up not including the depth when we
should have.

While we're here, rework the logic around setting src_depth and add a
comment so it's more clear what's going on.

Fixes: 6d4070f3

 "intel/compiler: add support for fragment coordinate..."
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <mesa/mesa!10596>

Somehow this was missed, but when we emit a query start/stop we need
have something that will need to be flushed in the batch.

Detected due to TC assert, but this had the potential to cause problems
in the non-TC case as well.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <!10599>

Add a helper to both set batch->needs_flush and clear ctx->last_fence so
that the two related bits of state do not get out of sync.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <!10599>

The gallium driver doesn't support gen2, so let's make it possible to
keep both i915g and i830 drivers installed in parallel.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <!10554>

Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <mesa/mesa!10554>

Declare a meson dependency for libpanfrost and wrap some key functions
within an extern C block allowing proper compilation by C++ compilers.
Signed-off-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <!10462>

The extension list should be more correct now.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <mesa/mesa!10556>

We only do it on Android for now, to keep the driver working with older
renderers on X11.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <mesa/mesa!10556>

This also guarantees that physical_dev->extension_spec_versions[X] is
set when extension X is supported.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <mesa/mesa!10556>

Native extensions are those do not require direct renderer support.
Passthrough extensions are those require direct renderer support.

Native extensions usually require translation to other extensions that
the renderer supports.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <mesa/mesa!10556>

Add VN_EXTENSION_TABLE_INDEX for use with VK_ANDROID_native_buffer spec
version override.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <mesa/mesa!10556>

Split up into two functions, one initializes the renderer extension
table and one initializes the supported extension table.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <mesa/mesa!10556>

Mostly docs and cleanups, except that renderer_version is now also
capped by the xml version.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <mesa/mesa!10556>

Add vn_instance::renderer_version to indicate the maximum renderer
instance version we can use internally.  It is not all that useful
because we only use 1.1 instance features and VN_MIN_RENDERER_VERSION is
set to 1.1, but whatever.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <mesa/mesa!10556>

Rename renderer_version to renderer_api_version.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <mesa/mesa!10556>

Use VN_MAX_API_VERSION for the instance version such that we don't
suddenly advertise 1.3 when the header is updated to 1.3 for example.

Use it to cap the device version as well.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <mesa/mesa!10556>

When we fail, we should not close gem_handle when there is already a bo
with the same gem handle.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <mesa/mesa!10592>

Do not set mmap_size to info.size.  We do not track the size of the BO
anymore.

This fixes
dEQP-VK.api.external.memory.dma_buf.suballocated.device_only.fd_properties
where the test allocates a 1KB VkDeviceMemory, export and call
vkGetMemoryFdPropertiesKHR.  It can happen that bo->mmap_size is less
than the aligned info.size.

FWIW, the test fails because it violates a VU:

  VUID-vkGetMemoryFdPropertiesKHR-fd-00673
  fd must be an external memory handle created outside of the Vulkan API

Fixes: 88f481dd

 ("venus: make sure gem_handle and vn_renderer_bo are 1:1")
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <mesa/mesa!10592>

It was treated as VK_ERROR_OUT_OF_HOST_MEMORY because
vn_get_intercepted_attachments would return NULL.  This fixes various
dEQP tests.

Fixes: 174fca54

 ("venus: handle VK_IMAGE_LAYOUT_PRESENT_SRC_KHR transfer")
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <mesa/mesa!10592>

It won't exist for phi nodes because they are only partially constructed
beforehand. Move it into the switch arguments where we know it's needed.

Part-of: <mesa/mesa!10591>

Instead of using a separate outputs array, make the "end" instruction
(or chmask) take the outputs as sources. This works better for the new
RA, because it better models the fact that outputs are consumed all at
the same time. With the old model, each output collect would be assumed
dead after it was processed and subsequent collects could use it when
inserting shuffle code, which wouldn't work, and the new RA also deletes
collect instructions after lowering them to moves so the information
would be gone after RA.

Part-of: <mesa/mesa!10591>

We need a stable order in order to create phi instructions. In the
future we can make this more sophisticated in order to make manipulating
the CFG easier, but for now that only happens after RA, so we won't have
to worry about it.

Part-of: <mesa/mesa!10591>