On 11/19/18 12:25 PM, Bas Nieuwenhuizen wrote:
On Mon, Nov 19, 2018 at 12:21 PM Samuel Pitoiset
<samuel.pitoi...@gmail.com> wrote:
On 11/19/18 11:56 AM, Bas Nieuwenhuizen wrote:
On Thu, Nov 15, 2018 at 10:51 AM Samuel Pitoiset
<samuel.pitoi...@gmail.com> wrote:
This has been initially added for a Sascha demo (ie. deferredshadows),
but as far I can tell this seems to no longer be needed.
No CTS changes on GFX9 and I didn't find a game that is affected.
Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
---
src/amd/vulkan/radv_cmd_buffer.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 8e0ed284d6..7940a8f128 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -2344,9 +2344,6 @@ radv_cmd_state_setup_attachments(struct radv_cmd_buffer
*cmd_buffer,
if ((att_aspects & VK_IMAGE_ASPECT_DEPTH_BIT) &&
att->load_op == VK_ATTACHMENT_LOAD_OP_CLEAR) {
clear_aspects |= VK_IMAGE_ASPECT_DEPTH_BIT;
- if ((att_aspects & VK_IMAGE_ASPECT_STENCIL_BIT)
&&
- att->stencil_load_op ==
VK_ATTACHMENT_LOAD_OP_DONT_CARE)
- clear_aspects |=
VK_IMAGE_ASPECT_STENCIL_BIT;
I think we should keep it, since it still saves bandwidth, but maybe
we want to only do the clear if we do the fastpath?
What do you mean by "it saves bandwidth"?
If we do a depth-only fast clear on a d+s surface, we have to do
read+mask+or+write. If we do a d+s fast clear we can just do the
write?
With the new fast clear on GFX9 yes, otherwise we will always do a slow
clear.
}
if ((att_aspects & VK_IMAGE_ASPECT_STENCIL_BIT) &&
att->stencil_load_op ==
VK_ATTACHMENT_LOAD_OP_CLEAR) {
--
2.19.1
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
