| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Starting with Gen11, we have two indirect clear colors: An unconverted
float/int version which is us used for rendering and a converted pixel
value version which is used for texturing. Because the one used for
texturing is stored as a single pixel of that color, it works no matter
what format is being used. Because it's a simple HW indirect and
doesn't involve copying surface states around, we can use it in the
sampler without having to worry about surface states having out-of-date
clear values. The result is that we can now allow any clear color when
texturing.
This cuts the number of resolves in a RenderDoc trace of Dota2 by 95%
on Gen11+ (you read that right) and improves perf by 3.5%. It improves
perf in a handful of other workloads by < 1%.
Reviewed-by: Rafael Antognolli <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4393>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we tried to treat color image layouts as a special case
during render passes. This is largely an artifact of history as our
initial understanding of Vulkan placed much more emphasis on render
passes than our current understanding. The only real practical use for
magic layouts in the middle of a render pass, as far as I can tell, is
to allow more clear colors to get passed through to input attachments.
However, most apps aren't very creative with their clear colors and very
few of them (none coming from DXVK) actually use render passes in any
interesting way. Therefore, the risk of being able to pass fewer clear
colors through to input attachments should be minimal.
There are, however, three very big advantages to this change:
1. We are now consistent in our handling of aux usage and layouts
between color and depth/stencil.
2. We are now actually following the layout guidelines from the app and
aren't nearly as likely to see strange behavior due to us overriding
the image layouts manually.
3. It's more obviously correct. While I think our old render pass code
was probably correct, it was full of corner cases and it's very
possible that it was behaving badly in weird ways. This follows the
Vulkan API much more blindly and, as such, is more likely to be
correct and behave the same as other implementations.
Reviewed-by: Rafael Antognolli <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4393>
|
|
|
|
|
|
|
|
| |
In particular, we split out an anv_can_fast_clear_color_view helper
which only cares about fast-clear and not aux_usage itself.
Reviewed-by: Rafael Antognolli <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4393>
|
|
|
|
|
|
|
|
|
|
| |
Instead of making it a function that pretends to choose aux usage (which
isn't what it does at all), make it a function which returns whether or
not we want to do a fast clear. This is far more accurate to the
purpose of the function.
Reviewed-by: Rafael Antognolli <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4393>
|
|
|
|
|
|
|
|
| |
This commit just renames some things so that we use names for temporary
variables which are more consistent with other places in the code-base.
Reviewed-by: Rafael Antognolli <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4393>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we bent over backwards to allow non-zero clear colors input
attachments whenever we could. However, very few apps use input
attachments and very few use non-zero clear colors. Getting rid of
support for non-zero clear colors input attachments will allow us to
treat them identically to textures which should help us simplify things
a good bit.
Reviewed-by: Rafael Antognolli <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4393>
|
|
|
|
|
|
|
|
|
|
|
| |
In order to actually hit this case you have to be using a very odd
color/view combination. The common cases of clear-to-zero and 0/1 clear
colors with an sRGB view don't require any re-interpretation. This is
probably better than always resolving whenever we have a format mismatch
like we are today because that hits the sRGB case every time.
Reviewed-by: Rafael Antognolli <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4393>
|
|
|
|
|
| |
Reviewed-by: Rafael Antognolli <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4393>
|
|
|
|
|
|
|
|
|
|
| |
Instead of allocating surface states for attachments in BeginRenderPass,
we now allocate them in begin_subpass. Also, since we're zeroing
things, we can be a bit cleaner about or implementation and just fill
out all those passes for which we have allocated surface states.
Reviewed-by: Rafael Antognolli <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4393>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit splits genX(cmd_buffer_setup_attachments)() into three
functions: one which sets up cmd_buffer->state.attachments, one which
allocates surface states, and one which fills out the surface states.
While we're here, we make both functions take the framebuffer (if any)
as an argument instead of pulling it from the command buffer so it's
more clear what things are inputs to the functions. We also make the
render pass and framebuffer parameters const as those are immutable
objects. The only functional change here should be that we now
vk_zalloc the attachments which should be a bit safer.
Reviewed-by: Rafael Antognolli <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4393>
|
|
|
|
|
|
|
|
|
| |
This makes a lot more sense than marking them written in begin_subpass
since, at that point, we haven't written them yet. This should reduce
the chances of accidental extra resolves.
Reviewed-by: Rafael Antognolli <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4393>
|
|
|
|
|
| |
Reviewed-by: Rafael Antognolli <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4393>
|
|
|
|
|
| |
Reviewed-by: Rafael Antognolli <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4393>
|
|
|
|
|
|
|
|
| |
It's a pointless micro-optimization that just makes compute_aux_usage
unnecessarily entangled with setting up surface states.
Reviewed-by: Rafael Antognolli <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4393>
|
|
|
|
|
|
|
|
|
|
|
| |
The subpass usage flags are supposed to always be one bit and never
multiple bits. However, when adding in TRANSFER_SRC usage for resolve
attachments we were adding it to the subpass bits and not the render
pass bits. This potentially is causing issues where images aren't
getting marked written properly.
Reviewed-by: Rafael Antognolli <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4393>
|
|
|
|
|
| |
Reviewed-by: Rafael Antognolli <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4393>
|
|
|
|
|
|
|
|
|
|
| |
Doom Eternal explicitly allows overallocation via this extension
but that shouldn't change anything because it's the default RADV
behavior.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4785>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By default, RADV supports overallocation by the sense that it doesn't
reject an allocation if the target heap is full.
With VK_AMD_overallocation_behaviour, apps can disable overallocation
and the driver should account for all allocations explicitly made by
the application, and reject if the heap is full.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4785>
|
|
|
|
|
|
| |
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4785>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the mask value 0x80000000, the other operand must be 32-bit. This
fixes failures in
dEQP-VK.subgroups.ballot_mask.ext_shader_subgroup_ballot.*.gl_subgroupgemaskarb_*
tests from Vulkan 1.2.2 CTS.
Checking one of the tests, it appears that the tests are doing 64-bit
iand with 0x0000000080000000, then comparing the result with zero.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2834
Fixes: 88eb8f190bd ("nir/algebraic: Simplify logic to detect sign of an integer")
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4770>
|
|
|
|
|
|
|
|
|
|
| |
In particular, we specifically don't want to let the base change between
passes, as it could end up conflicting with registers assigned in the
first pass.
Mostly-closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2838
Signed-off-by: Rob Clark <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4780>
|
|
|
|
|
| |
Signed-off-by: Rob Clark <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4780>
|
|
|
|
|
| |
Signed-off-by: Rob Clark <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4780>
|
|
|
|
|
| |
Signed-off-by: Rob Clark <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4780>
|
|
|
|
|
|
|
|
| |
Just something I hacked together to help figure out which instructions
can fold in a wideing/narrowing conversion.
Signed-off-by: Rob Clark <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4780>
|
|
|
|
|
| |
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4789>
|
|
|
|
|
| |
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4789>
|
|
|
|
|
| |
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4789>
|
|
|
|
|
|
|
| |
Only if both ports (<==> registers) same.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4789>
|
|
|
|
|
| |
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4789>
|
|
|
|
|
|
|
| |
Also used for fcmp16
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4789>
|
|
|
|
|
| |
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4789>
|
|
|
|
|
|
|
| |
Outputs u32.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4789>
|
|
|
|
|
| |
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4789>
|
|
|
|
|
| |
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4789>
|
|
|
|
|
| |
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4789>
|
|
|
|
|
| |
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4789>
|
|
|
|
|
| |
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4789>
|
|
|
|
|
| |
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4789>
|
|
|
|
|
| |
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4789>
|
|
|
|
|
|
|
| |
No purpose.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4789>
|
|
|
|
|
| |
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4789>
|
|
|
|
|
| |
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4789>
|
|
|
|
|
| |
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4789>
|
|
|
|
|
| |
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4789>
|
|
|
|
|
|
|
| |
Likewise.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4789>
|
|
|
|
|
|
|
| |
Not all but enough to see the pattern.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4789>
|
|
|
|
|
|
|
| |
Chain twice for full 64-bit CSEL.
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4789>
|
|
|
|
|
| |
Signed-off-by: Alyssa Rosenzweig <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4789>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reason behind this is that FMASK requires CMASK and also that
FMASK for non color attachments looks unnecessary. It's currently
much easier to add this simple check because the driver tries to
always enable DCC first and if we enable FMASK only if CMASK, we
might loose some FMASK compressions.
This helps fixing some new robustness2 tests which fails because
only FMASK is enabled.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4783>
|