- 04 May, 2021 18 commits
-
-
Erik Faye-Lund authored
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>
-
Gert Wollny authored
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>
-
Erik Faye-Lund authored
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>
-
Samuel Pitoiset authored
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: <mesa/mesa!10432>
-
Marek Olšák authored
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: <mesa/mesa!10526>
-
Marek Olšák authored
Reviewed-by:
Dave Airlie <airlied@redhat.com> Part-of: <mesa/mesa!10526>
-
Dave Airlie authored
This isn't needed anymore. Reviewed-by:
Eric Anholt <eric@anholt.net> Part-of: <mesa/mesa!9721>
-
Dave Airlie authored
This just moves to the common code in the compiler. Reviewed-by:
Eric Anholt <eric@anholt.net> Part-of: <mesa/mesa!9721>
-
Dave Airlie authored
This is ported from i965, but the interface is cleaned up Reviewed-by:
Eric Anholt <eric@anholt.net> Part-of: <mesa/mesa!9721>
-
Dave Airlie authored
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>
-
Emma Anholt authored
Part-of: <mesa/mesa!10597>
-
Emma Anholt authored
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>
-
Ian Romanick authored
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>
-
Ian Romanick authored
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>
-
Ian Romanick authored
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>
-
Ian Romanick authored
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>
-
Ian Romanick authored
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>
-
Faith Ekstrand authored
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>
-
- 03 May, 2021 22 commits
-
-
Faith Ekstrand authored
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>
-
Rob Clark authored
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: <mesa/mesa!10599>
-
Rob Clark authored
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: <mesa/mesa!10599>
-
Adam Jackson authored
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: <mesa/mesa!10554>
-
Adam Jackson authored
Reviewed-by:
Eric Anholt <eric@anholt.net> Part-of: <mesa/mesa!10554>
-
Antonio Caggiano authored
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: <mesa/mesa!10462>
-
Chia-I Wu authored
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>
-
Chia-I Wu authored
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>
-
Chia-I Wu authored
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>
-
Chia-I Wu authored
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>
-
Chia-I Wu authored
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>
-
Chia-I Wu authored
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>
-
Chia-I Wu authored
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>
-
Chia-I Wu authored
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>
-
Chia-I Wu authored
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>
-
Chia-I Wu authored
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>
-
Chia-I Wu authored
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>
-
Chia-I Wu authored
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>
-
Chia-I Wu authored
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>
-
Connor Abbott authored
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>
-
Connor Abbott authored
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>
-
Connor Abbott authored
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>
-