We can't map the CCS on this platform to initialize it into the
PASS_THROUGH state. This can cause issues with optimizations in the
driver that rely on this state.
For example, after rendering to a surface with AUX_NONE, we can then
render to it with AUX_CCS_E without an ambiguate in between (if the CCS
in the PASS_THROUGH state). If that state was incorrect and the aux was
actually compressed, there can be rendering corruption because the
contents may be misinterpreted on the second render.
Use a more accurate initial aux state to avoid these issues.
One notable change in behavior here is that aux surfaces can be created
with fast-cleared blocks even though the caller may specify a modifier
that doesn't support fast clears. This should be fine, so long as all HW
units that can access these surfaces can handle that bit-pattern. We
haven't seen an applicable restriction yet.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13555>
The assert was introduced in a function that allocated an auxiliary
surface BO, iris_resource_alloc_aux. After refactors, the function it's
in now, iris_resource_configure_aux, no longer does this allocation.
Drop the assert because its purpose is unclear and it's no longer
relevant for CCS on XeHP.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13555>
This parameter won't be used for XeHP, because we can't directly control
the row pitch of the CCS independently from the main surface.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13555>
The only depth/stencil aux usage that can actually use the BO is
ISL_AUX_USAGE_HIZ_CCS_WT. Even with that aux usage, iris may disable
sampling depending on the surface configuration.
Allocate the clear color BO when it'd be usable, not just when the
auxiliary surface size is non-zero on ICL+. This prepares for CCS on
XeHP, which won't have an auxiliary surface.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13555>
isl_dev.ss.clear_color_state_size is already zero on BDW and SKL. Drop
the redundant platform check and return the field directly.
We're going to have this function return zero more often and it will do
so uniformly using if-statements. We choose to remove the redundant
expression instead of adding a redundant if-statement.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13555>
To ease verification, place the assignment and reference of the aux BO
right before the same operations are done for the clear color BO. Also,
move the call to map_aux_addresses that's in the same if-block.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13555>
res->aux.bo and res->aux.surf will be NULL and zeroed, respectively, for
CCS on XeHP. Move and modify iris_resource_init_aux_buf to support this.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13555>
Have iris_resource_init_aux_buf compute the clear color state size
(with an iris_screen struct) instead of passing it in directly.
We're going to move the function call soon. This keeps us from having to
move a passed in variable along with it.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13555>
include it explicitly in the correct places
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14104>
This adds a bunch of other headers in, and adds mtypes.h to iris
for perf query object.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14104>
When targeting the blitter or compute engines, the destination is not
really a render target. But it's still useful to know whether we're
talking about the source or destination.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14094>
This capability is enabled for drivers supporting formatless image
writing in shader.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13409>
As described in "intel: Add intel_gem_create_context_engines", this
should make it easier to support an I915_ENGINE_CLASS_FOO engine in
the future. For example, maybe something like:
98c3bbd5b5
Reworks:
* Tweak engine counting logic (s-b Ken)
* Tweak init of engine_classes in iris_init_engines_context (s-b Ken)
* Add STATIC_ASSERT on engine_classes (Jordan)
* Paulo: Call iris_hw_context_set_unrecoverable() for engines context
* Rename to has_engines_context (s-b Paulo)
* Jordan: Handle creating a new engines context when the context needs
to be replaced.
* Ken: Tweak context destroy code paths.
* Call iris_lost_context_state on every batch. (s-b Ken)
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12692>
Kernel contexts can take two forms now. In the older case a kernel
context will have a single hardware context. With an "engines" based
context, the context can now have 1 or more hardware contexts.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12692>
We're going to add a second caller.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12692>
Drop the call to iris_resource_disable_aux in
iris_resource_configure_aux. With the previous patches, we no longer
create CCS surfaces and pick the AUX_NONE usage. As a result, if the aux
usage is NONE, all iris_resource fields already indicate that aux is
disabled.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12398>
Allow CCS_E on these formats on TGL+ for a couple reasons:
1) TGL doesn't have the option to fall back to CCS_D/fast-clears like
prior platforms do.
2) The CCS compression scheme on TGL improves to encode more than 3
levels of compression. This should help floating point formats.
In my measurements, enabling this on TGL results in a minor performance
improvement on Paraview (+0.06%) rather than a major regression like on
prior platforms. The improvement was measured by taking the average of 3
runs of: waveletvolume.py -d 256 -f 600.
Also, the Intel performance CI reports a 3.81% ±0.12% FPS improvement in
Bioshock Infinite.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12398>
ISL recently started allowing linear ASTC surfaces to be created. With
that in place, iris can perform GPU-based uploads to ASTC textures in
the same way it does so with other compressed surfaces.
We're not aware of any reason to continue special-casing ASTC texture
uploads, so we get rid of the code which does so.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13881>
This code was originally made for crocus by Dave Airlie.
Iris is also affected, so this commit ports the fix.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12993>
Now that we aren't short-circuiting most of the code, we should probably
reorganize it a little bit. Tagged with fixes just so we pull all the
refactors together as one group.
Fixes: b21e916a62 ("iris: Combine iris_use_pinned_bo and add_exec_bo")
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13808>
We need to perform cross-batch flushing if any batch writes to a BO
while others refer to it. We checked this case when recording a new
BO in the list which we'd never seen before. However, we neglected to
handle the case when we already read from a BO, but then began writing
to it. That new write may provoke a conflict between existing reads
in other batches, so we need to re-check the cross-batch flushing.
Caught by Piglit's copyteximage when forcing blits and copies to use
a new IRIS_BATCH_BLITTER that isn't upstream yet. But this bug could
be provoked by render/compute work today...we just hadn't noticed it.
Fixes: b21e916a62 ("iris: Combine iris_use_pinned_bo and add_exec_bo")
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13808>
This should have no functional change, but it's tagged with Fixes
anyway because it's needed for the bug fix in the next patch.
Fixes: b21e916a62 ("iris: Combine iris_use_pinned_bo and add_exec_bo")
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13808>
We had accidentally passed <x, y, z, l> instead of <l, x, y, z>.
Fixes: b8ef3271c8 ("iris: Move suballocated resources to a dedicated allocation on export")
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13815>
We're currently only calling it after creating the screen and the
bufmgr. There are a few cases where Iris checks for the DEBUG_BUFMGR
bit before we call brw_process_intel_debug_variable(), which means
intel_debug is 0 and so we don't run the debug code. Today, these are
all related to the creation of the workaround bo and its mmap.
I found this in a custom branch after I converted to INTEL_DEBUG an
environment variable that I had.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13780>
We don't current enable post sync operations, but it is probably
better to set them to "internal" MOCS than to remove the non-zero
checking for this genxml field.
Reworks:
* Fix COMPUTE_WALKER in cmd_buffer_trace_rays (s-b Jason)
Fixes: 7b78b2fcac ("intel/genxml: Assert that all MOCS fields are non-zero on Gfx7+")
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13624>
On GFX version 12.5+ with COMPUTE_WALKER, this is the limit based on the
size of the HW packet. On older HW, we can technically go a bit bigger
but there's not much point. Technically, some hardware can support a
scalar workgroup size up to 2048 but most apps don't go any bigger than
1024.
As discussed on the merge request page, the current limit assumes
SIMD32, but it is unclear if we want to encourage applications to use
SIMD32 if it may lead to additional register spilling in shader
programs. Many applications have likely tuned for a limit of 1024
based on the OpenGL minimum limit, so it might not gain much by
advertising more than 1024.
Reworks:
* Jordan: Use MIN2 and limit total invocations as well.
* Jordan: Add second paragraph to commit message based on merge
request discussion.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13538>
