Thank you Józef and Ilia for pointing this out!

I believe I have fully understood what's happening here and I'll send a final version of the fix soon.

On 9/7/18 7:47 PM, Józef Kucia wrote:
On Fri, Sep 7, 2018 at 6:44 PM Ilia Mirkin <imir...@alum.mit.edu> wrote:
On Fri, Sep 7, 2018 at 12:35 PM, Józef Kucia <joseph.ku...@gmail.com> wrote:
On Fri, Sep 7, 2018 at 4:42 PM Danylo Piliaiev
<danylo.pilia...@gmail.com> wrote:

@@ -1546,8 +1548,8 @@ update_image_surface(struct brw_context *brw,
              .format = format,
              .base_level = obj->MinLevel + u->Level,
              .levels = 1,
-            .base_array_layer = obj->MinLayer + u->_Layer,
-            .array_len = num_layers,
+            .base_array_layer = base_layer,
+            .array_len = num_layers - base_layer,
              .swizzle = ISL_SWIZZLE_IDENTITY,
              .usage = ISL_SURF_USAGE_STORAGE_BIT,
           };
This sets the "array_len" to the number of layers remaining in the
original texture. Shouldn't it take into account the number of layers
in the GL texture view?
Errr, right. Here is the logic in st/mesa, which I believe is correct.
(But convoluted. Because there are so many bits to it.)

https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/state_tracker/st_atom_image.c#n101
There is also view_num_layers in brw_update_texture_surface(). It
could be adapted.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to