[Mesa-dev] [PATCH 1/3] i965: solve cubemap negative x/y/z faces buffer offset issue in dEQP.
jason at jlekstrand.net
Tue Oct 4 15:59:28 UTC 2016
On Tue, Oct 4, 2016 at 8:55 AM, Tapani Pälli <tapani.palli at intel.com> wrote:
> On 10/04/2016 06:09 PM, Jason Ekstrand wrote:
> On Thu, Sep 29, 2016 at 11:27 PM, Xu,Randy <randy.xu at intel.com> wrote:
>> 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].
>> This fix will solve 12 deqp failure
>> Signed-off-by: Xu,Randy <randy.xu at intel.com>
>> 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
>> 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 =
>> - uint32_t tile_x = 0, tile_y = 0;
>> + uint32_t tile_x = mt->level.slice.x_offset;
>> + uint32_t tile_y = mt->level.slice.y_offset;
> 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.
> 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.
> 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?
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
>> uint32_t offset = mt->offset;
>> struct isl_surf surf;
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
> mesa-dev mailing listmesa-dev at lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mesa-dev