<div dir="ltr"><div><div>Randy, </div>I hadn't realized that we could get images in from EGL where we have a non-zero tile_x and tile_y offset for layer 0 mip 0. That explains things. In that case, I believe this is the correct patch. That said, I would like to see an "assert(tile_x == 0 && tile_y == 0)" right before we do the intel_miptree_get_tile_offset() in the case below. I don't think those can ever happen at the same time, but if they do, I want to know. </div>--Jason <div><div><div><div class="gmail_extra"> <div class="gmail_quote">On Tue, Oct 4, 2016 at 5:13 PM, Xu, Randy <<a href="mailto:randy.xu@intel.com" target="_blank">randy.xu@intel.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div link="blue" vlink="purple" lang="EN-US"> <div> Hi, Jason & Tapani Thanks for your review, let me introduce the dEQP failure first. In dEQP-EGL.functional.image.create.gles2_cubemap_negative_*_texture, 2D textures are generated from all 6 faces of a Cubemap texture (64x64), and then rendered through glDrawXXX. In brw_miptree_get_vertical_slice_pitch, the mt->qpitch is counted as 144. return h0 + h1 + (brw->gen >= 7 ? 12 : 11) * mt->valign; // 64+32+12*4 = 144 Take the face negative_x for example, the total offset in bo is 144(y)*64(x)*4(bpp) = 36864. It’s TILING_Y buffer, as the y (144) is not 32 aligned (mask_y = 31 from intel_region_get_tile_masks), the total bo offset is divided into two parts: 36864 = 32768 (offset 128*64*4) + 16(tile_y)*64*4 case I915_TILING_Y: *mask_x = 128 / cpp - 1; *mask_y = 31; Both the tile_y and offset are passed to texture2D in create_mt_for_dri_image, while the tile_y is not used to count the total offset in rendering path, that’s why I add this patch. Please check and comment more. Thanks, Randy From: Jason Ekstrand [mailto:<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>] Sent: Tuesday, October 4, 2016 11:59 PM To: Palli, Tapani <<a href="mailto:tapani.palli@intel.com" target="_blank">tapani.palli@intel.com</a>> Cc: Xu, Randy <<a href="mailto:randy.xu@intel.com" target="_blank">randy.xu@intel.com</a>>; <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a>; <a href="mailto:Xu@freedesktop.org" target="_blank">Xu@freedesktop.org</a> Subject: Re: [Mesa-dev] [PATCH 1/3] i965: solve cubemap negative x/y/z faces buffer offset issue in dEQP. <div> <div> <div> On Tue, Oct 4, 2016 at 8:55 AM, Tapani Pälli <<a href="mailto:tapani.palli@intel.com" target="_blank">tapani.palli@intel.com</a>> wrote:<div><div class="h5"> <blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"> <div> <div> <div> <div> On 10/04/2016 06:09 PM, Jason Ekstrand wrote: </div> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <div> <div> <div> On Thu, Sep 29, 2016 at 11:27 PM, Xu,Randy <<a href="mailto:randy.xu@intel.com" target="_blank">randy.xu@intel.com</a>> wrote: <blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"> Add the miptree level/slice x/y_offset when count the surface offset in brw_emit_surface_state. The surface offset has two parts, one is from mt->offset, which should be 32 aligned in width/height for tiled buffer; another is from mt->level[current_level].slice[current_slice]. x/y_offset. This fix will solve 12 deqp failure dEQP-EGL.functional.image.create.gles2_cubemap_negative_*_texture Signed-off-by: Xu,Randy <<a href="mailto:randy.xu@intel.com" target="_blank">randy.xu@intel.com</a>> --- src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c index 61a4b94..3a5c573 100644 --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c @@ -85,7 +85,8 @@ brw_emit_surface_state(struct brw_context *brw, unsigned read_domains, unsigned write_domains) { const struct surface_state_info ss_info = surface_state_infos[brw->gen]; - uint32_t tile_x = 0, tile_y = 0; + uint32_t tile_x = mt->level[0].slice[0].x_offset; + uint32_t tile_y = mt->level[0].slice[0].y_offset; </blockquote> <div> </div> <div> This isn't correct. First off, there are some fairly strict restrictions on what we can do with tile_x and tile_y and we can't just shove x/y_offset in there. We need to use intel_miptree_get_tile_offsets to get both a byte offset and an intratile offset. Second, we should already be taking slices into account for cube maps via base_array_layer where needed. </div> <div> Unfortunately, I'm not 100% sure what the correct patch is without a bit more information about what the test is doing that causes a problem. </div> </div> </div> </div> </blockquote> </div> </div> I did take a brief look and when running the set mentioned above (for example with ./deqp-egl --deqp-case=*EGL.functional.image.create.gles2_cubemap_negative_*_texture) what happens is that we never end up to the part of code calling intel_miptree_get_tile_offsets in that function (because surf.dim_layout != dim_layout condition does not trigger). This is just what I observed, should we just call intel_miptree_get_tile_offsets() unconditionally then? </div> </blockquote> <div> </div> <div> No. Very much no. The intel_miptree_get_tile_offsets() stuff is a hack that lets us convert non-2D things to 2D things and it comes with piles of restrictions. </div> <div> </div> <blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"> <div> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <div> <div> <div> <div> --Jason </div> <div> </div> <blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"> uint32_t offset = mt->offset; struct isl_surf surf; -- 2.7.4 _______________________________________________ mesa-dev mailing list <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> </blockquote> </div> </div> </div> <pre>_______________________________________________</pre> <pre>mesa-dev mailing list</pre> <pre><a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a></pre> <pre><a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a></pre> </blockquote> </div> </blockquote> </div></div></div> </div> </div> </div> </div> </blockquote></div> </div></div></div></div></div>