From OpenGL 4.6, section 9.4.4 "Effects of Framebuffer Completeness on
Framebuffer Operations", page 332:
"An INVALID_FRAMEBUFFER_OPERATION error is generated by attempts to render
to or read from a framebuffer which is not framebuffer complete.
This error is generated regardless of whether fragments are actually read
from or written to the framebuffer. For example, it is generated when a
rendering command is called and the framebuffer is incomplete, even if
RASTERIZER_DISCARD is enabled."
Signed-off-by: Dmytro Nester <dmytro.nester@globallogic.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4833>
If you want to dump batch state, it needs to have the relocs processed
but the relocs don't get processed on the shadow batch.
Choose debugging over speed here.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4846>
static_assert without a message is only supported with C++17 and later.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Fixes: c99107ece0
('aco: add explicit padding for all Instruction sub-structs')
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4850>
This extends commit 2243f0cd for anv with additional
extensions for Pie and Q versions.
Fixes tests with 9_R11 CTS:
dEQP-VK.api.info.android#no_unknown_extensions
dEQP-VK.api.info.device#extensions.
v2: Use snake_case function name (Jason Ekstrand)
Drop Change-Id in commit (Kristian H. Kristensen)
v3: Resolve meson-clang error for ANDROID_API_LEVEL.
Signed-off-by: Nataraj Deshpande <nataraj.deshpande@intel.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4827>
Current Android dessert versions such as Pie, Q reject
vulkan version > 1.1. Clamp the vulkan versions to 1.1
for platforms running these Android desserts.
Fixes android.graphics.cts.VulkanFeaturesTest and
dEQP-VK.api.info.device#properties.
v2: Limit version with '!ANDROID' (Eric Engestrom and Tapani Pälli)
Signed-off-by: Nataraj Deshpande <nataraj.deshpande@intel.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4781>
The motivating factor is: this lowering may cause
nir_intrinsic_load_local_group_size intrinsics to be added to the
shader, and by moving this around we make possible for the drivers to
lower that intrinsic by themselves.
Iris will do just that in a later patch for implementing variable
group size.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4794>
Intrinsic to get the SIMD width, which not always the same as subgroup
size. Starting with a small scope (Intel), but we can rename it later
to generalize if this turns out useful for other drivers.
Change brw_nir_lower_cs_intrinsics() to use this intrinsic instead of
a width will be passed as argument. The pass also used to optimized
load_subgroup_id for the case that the workgroup fitted into a single
thread (it will be constant zero). This optimization moved together
with lowering of the SIMD.
This is a preparation for letting the drivers call it before the
brw_compile_cs() step.
No shader-db changes in BDW, SKL, ICL and TGL.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4794>
Adding this since Iris will handle variable group size parameters by
itself.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4794>
(Co-authored with Chris Wilson.)
Frequently, games create fences and later check them with a timeout of
0 to see if that work has completed yet. They do not want the work to
be flushed immediately upon fence creation.
This is what PIPE_FLUSH_DEFERRED does - it inhibits the flush at fence
creation time, but still guarantees that a flush will occur later on
once fence_finish() is called.
Since syncpts can only occur at batch boundaries, when deferring a
flush, we have to wait for the syncpt at the end of the batch being
constructed. This is later than desired, but safe if blocking. To
avoid extra delays, we additionally insert a PIPE_CONTROL to write an
availability bit at the exact point of the fence. We can poll this
on the CPU, allowing us to check whether the fence has gone by, even
if the batch hasn't completed. It can also let us skip kernel calls.
Improves performance in Bioshock Infinite by 10% on Icelake GT2 on
-ForceCompatLevel=5 settings. Thanks to Felix Degrood and Mark Janes
for helping notice the extraneous stalls and batches, Marek Olšák for
adding deferred flush support to Gallium to solve this issue, and
Chris Wilson for reworking a lot of the internals of this work.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3802>
Receiving a fence_server_sync (iris_fence_await) means that any future
work needs to wait for the fence. But previous work doesn't need to.
So flush it now, to avoid delaying it arbitrarily.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3802>
In the next patch, we will introduce deferred fences where we will need
to flush a fence later. To do this, we need to know which batch requires
flushing, so keep a 1:1 mapping between seqno[] and the associated
batch.
It's also substantially less confusing to have a 1:1 mapping.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3802>
By using the breadcrumbs we inject into the batch, we can build a
lightweight fence - that can be evaluated in userspace without having to
check in the kernel. In order to pass the fences between processes, and
to wait efficiently, we continue to track the syncobj for each batch and
use that as a terminator for the fence, and for passing coarse
scheduling decisions to the kernel on execbuf.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3802>
We can use seqno as a basic for fast userspace fences: where we can
check a value directly to test for fence completion without having to
query using the kernel. To do so we need to write a breadcrumb from the
batch and track those writes as the basis for our lightweight fences.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3802>
Batches are going to have an uploader in the next commit, so destroying
batches will destroy uploaders, which will unmap transfers, which will
return things to the slab allocator. So we need to reorder destroying
the slab allocator to the end to avoid crashing.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3802>
We're going to need it to create a uploader in the batch soon. We still
avoid storing it, to maintain the charade of separation, and make people
think twice about fetching random fields from there and intertwining
things even worse.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3802>
This is just a refcounted wrapper around a drm_syncobj. There is
enough terminology going on in the area of synchronization (sync
objects, sync files, ...) that I'd rather not invent our own.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3802>
Lets us drop some cut and pasted kernel header contents.
Linux 4.7 came out 4 years before we the first officially supported
release of this driver; iris won't run on kernels older than 4.16,
and 4.18.11+ is strongly recommended. So I suspect it's safe to
assume that a kernel header from 4.7 will exist at build time.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3802>
Avoids surprises where you set an OVERRIDE but it gets ignored and the
system PCI ID is used.
Also fixes the bug that the error of invalid platform name being
printed too early, even when the passed platform was a PCI ID (which
is also supported).
For the case where euid != uid, a warning was added but the behavior
wasn't changed: it is still going to fallback to system PCI ID.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4841>
gen12 does away with the single patch dispatch mode for tcs, and
increases some limits so that 8_patch mode can always work. Make the
necessary changes so we don't try to fall back to single patch mode.
Fixes KHR-GL46.tessellation_shader.single.max_patch_vertices and others
Fixes: 44754279ac ("intel/fs/gen12: Use TCS 8_PATCH mode.")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4843>
If you're going out of your way to do per-sample interpolation, you are
almost surely going to be doing so to an MSAA framebuffer. Should reduce
recompiles with MSAA enabled.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4562>
Now that we normalize our keys fairly well, build a variant at shader
state creation time so that hopefully you don't have to call the compiler
at draw time (as is now the case with glmark2 ES and most of the humus GL
demos).
Fixes: #2782
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4562>
We can remove a bunch of conditional code at key comparison time by
computing a bitmask of used key bits at ir3_shader creation time. This
also gives us a nice place to put additional key simplification to reduce
how many variants we create (like skipping rastflat if we don't read
colors in the FS, or skipping vclamp_color if we don't write colors).
It does mean walking the whole key to AND it, but the key is just 28 bytes
so far so that seems pretty fine.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4562>
We weren't filling in the tess mode of the key, or setting has_gs on GS
shaders, resulting in assertion failures when NIR intrinsics didn't get
lowered.
We have to make a guess at prim mode for TCS, but it should be better to
have some shader-db coverage than none, and it will avoid these failures
happening when we start precompiling shaders.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4562>