<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 23/02/17 16:26, Jason Ekstrand
wrote:<br>
</div>
<blockquote
cite="mid:CAOFGe95rbN3Pe-m61AoCsiMeWSjnvV=79R=amMd7wZiPs8Afvw@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="auto">
<div>
<div class="gmail_extra">
<div class="gmail_quote">On Feb 23, 2017 8:03 AM, "Lionel
Landwerlin" <<a moz-do-not-send="true"
href="mailto:lionel.g.landwerlin@intel.com">lionel.g.landwerlin@intel.com</a>>
wrote:<br type="attribution">
<blockquote class="quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">I must
be missing something, but I'm struggling to see why this
patch change anything.<br>
Why does it matter if we write a clear color in
SURFACE_STATE?<br>
Shouldn't the usage of that color value only depend on
whether we enable 3DSTATE_PS.RenderTargetFastCle<wbr>arEnable
for instance?<br>
</blockquote>
</div>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">Because ISL will assert on us if it's a color
the surface state doesn't allow. In this particular case it
was a non-0/1 color which isn't even representable on
Broadwell.</div>
</div>
</blockquote>
<br>
Thanks! Makes sense now :)<br>
<br>
Reviewed-by: Lionel Landwerlin <a class="moz-txt-link-rfc2396E" href="mailto:lionel.g.landwerlin@intel.com"><lionel.g.landwerlin@intel.com></a><br>
<br>
<blockquote
cite="mid:CAOFGe95rbN3Pe-m61AoCsiMeWSjnvV=79R=amMd7wZiPs8Afvw@mail.gmail.com"
type="cite">
<div dir="auto">
<div dir="auto"><br>
</div>
<div dir="auto">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
-<br>
Lionel
<div class="elided-text"><br>
<br>
On 22/02/17 03:31, Jason Ekstrand wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Not all clear colors are valid. In particular, on
Broadwell and<br>
earlier, only 0/1 colors are allowed in surface
state. No CTS tests are<br>
affected outright by this because, apparently, the
CTS coverage for<br>
different clear colors is pretty terrible. However,
when multisample<br>
compression is enabled, we do hit it with CTS tests
and this commit<br>
prevents regressions when enabling MCS on Broadwell
and earlier.<br>
<br>
Cc: "13.0 17.0" <<a moz-do-not-send="true"
href="mailto:mesa-stable@lists.freedesktop.org"
target="_blank">mesa-stable@lists.freedesktop<wbr>.org</a>><br>
---<br>
src/intel/vulkan/anv_blorp.c | 5 +++--<br>
1 file changed, 3 insertions(+), 2 deletions(-)<br>
<br>
diff --git a/src/intel/vulkan/anv_blorp.c
b/src/intel/vulkan/anv_blorp.c<br>
index 4e7078b..8db03e4 100644<br>
--- a/src/intel/vulkan/anv_blorp.c<br>
+++ b/src/intel/vulkan/anv_blorp.c<br>
@@ -1198,9 +1198,10 @@
anv_cmd_buffer_clear_subpass(s<wbr>truct
anv_cmd_buffer *cmd_buffer)<br>
struct blorp_surf surf;<br>
get_blorp_surf_for_anv_image(i<wbr>mage,
VK_IMAGE_ASPECT_COLOR_BIT,<br>
att_state->aux_usage, &surf);<br>
- surf.clear_color =
vk_to_isl_color(att_state->cle<wbr>ar_value.color);<br>
if (att_state->fast_clear) {<br>
+ surf.clear_color =
vk_to_isl_color(att_state->cle<wbr>ar_value.color);<br>
+<br>
blorp_fast_clear(&batch, &surf,
iview->isl.format,<br>
iview->isl.base_level,<br>
iview->isl.base_array_layer, fb->layers,<br>
@@ -1224,7 +1225,7 @@ anv_cmd_buffer_clear_subpass(s<wbr>truct
anv_cmd_buffer *cmd_buffer)<br>
render_area.offset.x,
render_area.offset.y,<br>
render_area.offset.x +
render_area.extent.width,<br>
render_area.offset.y +
render_area.extent.height,<br>
- surf.clear_color, NULL);<br>
+
vk_to_isl_color(att_state->cl<wbr>ear_value.color),
NULL);<br>
}<br>
att_state->pending_clear_aspec<wbr>ts =
0;<br>
</blockquote>
<br>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>