For mutable format images, I don't think we can safely allow the clear
color to escape the render pass. Otherwise we'd have to do annoying
trickery to resolve with the correct format. We could do a bunch of
predicated resolves or we could emit an MI command to whack the surface
state. Neither of those sounds good. Sorry, that's not really a solution?
--Jason
On December 22, 2018 19:07:33 Lionel Landwerlin
<lionel.g.landwer...@intel.com> wrote:
The problem is a bit more annoying than I initially thought :(
Here is what the vkd3d test does :
1. Create image format R8G8B8A8_UNORM
2. Create image view format R8G8B8A8_SRGB
3. Clear the view through a sub pass to a particular color
4. Barrier on the image to from color attachment to source transfer
5. Copy the image into a linear buffer to check the content
The problem happens at step 4 because that's where we resolve the image.
Because the barrier command operates on images, it'll do a resolve in
the format of the image, not the view.
So we end up writing the clear color in the UNORM format hence the test
failure.
I'm not quite sure how to deal with this. The spec says those format
should be compatible, so no flags are required at image creation that
could hint to disable the compression so we avoid the resolve and don't
run into this issue...
Currently I'm thinking of storing an additional color field in the clear
color information so that gets loaded into the blorp shader and then can
apply some srgb conversion if needed.
Thoughts?
Thanks a lot,
-
Lionel
On 21/12/2018 13:13, Lionel Landwerlin wrote:
Looking at this, I think the issue is more in anv_blorp.c.
All of the mcs/ccs ops we're doing use the anv_image which can be a
different format from the anv_image_view we're dealing with.
In this particular bug, the image is R8G8B8A8_UNORM while the view is
R8G8B8A8_SRGB.
I think this might be the problem.
Currently looking at adding
anv_image_view_mcs_op/anv_image_view_ccs_op and see if that breaks the
world.
-
Lionel
On 21/12/2018 13:09, Jason Ekstrand wrote:
This isn't quite true. Fast-clear without CCS compression (also known
as CCS_D) is supported on gen9. There is, however, a bug with
blending and non-0/1 clear colors that we don't currently bother
handling in anv. See also:
https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/mesa/drivers/dri/i965/intel_mipmap_tree.c#L2672
On December 21, 2018 06:26:31 Samuel Iglesias Gonsálvez
<sigles...@igalia.com> wrote:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108911
Signed-off-by: Samuel Iglesias Gonsálvez <sigles...@igalia.com>
---
Lionel, I have doubts if this is only for gen9 or it should be gen9+.
Can you confirm on gen10 if the sRGB bug is happening there and if this
fixes it? (You would need to adapt the GEN_GEN == 9 to >=).
src/intel/vulkan/genX_cmd_buffer.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/intel/vulkan/genX_cmd_buffer.c
b/src/intel/vulkan/genX_cmd_buffer.c
index 93b5269c6ba..cb08ef8df1e 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -324,6 +324,10 @@ color_attachment_compute_aux_usage(struct
anv_device * device,
break;
}
+ /* Gen9 doesn't support fast clear on single-sampled SRGB
buffers */
+ if (GEN_GEN == 9 &&
isl_format_is_srgb(iview->planes[0].isl.format) &&
iview->image->samples == 1)
+ att_state->fast_clear = false;
+
/* Potentially, we could do partial fast-clears but doing so
has crazy
* alignment restrictions. It's easier to just restrict to
full size
* fast clears for now.
--
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
_______________________________________________
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
