Some RGP data showing that a large amount of NOPs might be a performance
concern.
Some data from a Granite demo repurposed as benchmark:
- with max_count = 16, actual draw count 1-4, the new path is ~5% slower
- with max_count = 2048, actual draw count 1-4, the new path is >2x as fast.
- with max_count = 16384, actual draw count 1-4, the new path is >7x as fast.
Due to the new path being slower in e.g. small cmdbuffers I added a heuristic.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25046>
cs->base.cdw here is the size of the last CS in the chain, but we are
passing in the first CS in the chain to begin decoding. Hence,
cs->ib_buffers[0].cdw is the correct size here.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25061>
SAMPLE_STREAMOUTSTATS requires PIPELINESTAT_START to be enabled,
otherwise the hw doesn't count anything.
This fixes
dEQP-VK.transform_feedback.primitives_generated_query.concurrent.pipeline_statistics_2.*
on GFX8. GFX6-9 are probably also affected by this bug, but with NGG
these queries are slightly different and don't use legacy streamout.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25049>
When we have MSAA copy/clear operation on the compute queue, use the
companion RCS command buffer to carry out copy/clear operations.
v2: (Sagar)
- Flush cache according to command buffer
- Invalidate AUX when we create new companion RCS command buffer if
platform support AUX TT.
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23661>
We need to synchronize main (CCS/BCS) and companion rcs batch, so let's
create an empty batch and make both the batches (CCS/BCS) and companion
RCS batch wait on empty sync batch and signal the fence.
Reason to execute the empty batch is we need to make sure the companion
RCS batch finish as soon as the CCS/BCS batch finish. Preemption could
prevent the companion RCS batch execution and we might end up destroying
the CCS/BCS batch before companion RCS finishes.
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23661>
In future patches, we will be creating a separate companion RCS engine
and each engine is created with it's own address space, and we really
don't want. CCS and RCS engine writes should be visible to each other in
order to get the wait/signal mechanism working.
v2:
- Move drm_i915_gem_context_create_ext_setparam out of if block (Lionel)
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23661>
This helper takes the main command buffer as input and then create a
companion RCS command buffer.
v2:
- Rename anv_get_render_queue_index helper to
anv_get_first_render_queue_index (Jose)
- Rename RCS command buffer to companion RCS command buffer (Lionel)
- Add early return in anv_get_first_render_queue_index (Lionel)
- Add lock around the function (Jose)
- Move companion rcs command pool creation in device create (Sagar)
- Reset companion RCS cmd buffer (Sagar)
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23661>
The condition
!param->type->is_vector() || !param->type->is_scalar()
alawys evaluates to true:
* type is not scalar or vector -> true
* type is vector, i.e. num_components > 1 -> num_components == 1 is
false and !is_scalar() == true
* type is scalar, i.e. num_components == 1 -> num_components > 1 is
false and !is_vector() == true
There is no comment explaining why such code has been written, therefore
this seems to be a mistake.
To maintain consistency with the surrounding code,
glsl_type_is_scalar_or_vector has been used instead of
replacing || with &&.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24914>
to avoid splitting renderpasses, this subdata optimization handles the usual
driver dance of staging buffer -> gpu copy
if the pbo stride doesn't match the image format's stride, however, then
a direct copy will yield broken pixels and the image will misrender. to avoid this,
detect stride mismatch and translate the single subdata call into a sequence
of non-overlapping subdata calls that the driver can magically figure out
while continuing to not split renderpasses
fixes#9589
cc: mesa-stable
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24849>
A single Vulkan state can map to multiple fields in different GPU
instructions. This change introduces the bottom half of a simplified
emission mechanism where we do the following :
Vulkan runtime state
|
V
Intermediate driver state
|
V
Instruction programming
This way we can detect that the intermediate state didn't change and
avoid HW instruction emission.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24536>
The goal of this change it to move away from a single batch buffer
containing all kind of pipeline instructions to a list of instructions
we can emit separately.
We will later implement pipeline diffing and finer state tracking that
will allow fewer instructions to be emitted.
This changes the following things :
* instead of having a batch & partially packed instructions, move
everything into the batch
* add a set of pointer in the batch that allows us to point to each
instruction (almost... we group some like URB instructions,
etc...).
At pipeline emission time, we just go through all of those pointers
and emit the instruction into the batch. No additional packing is
involved.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24536>
