From: Dave Airlie Date: Tue, 17 Oct 2017 07:17:12 +0000 (+0100) Subject: radv/image: bump all the offset to uint64_t. X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=35c66f3e40177a97d74e614e2a324a03e2149c73;p=mesa.git radv/image: bump all the offset to uint64_t. So one of the CTS tests tries to allocate a 16384x1 2048 array texture. This overflows a bunch of calculations when we want it tiled as the heights goes to 128. addrlib returns us the correct size (16GB or so), but we mangle it in the htile calcs due to the 32-bit offset fields, then userspace gives us the reduced number and we try to allocate it on a heap and things blow up. We really need to give the app back the correct size for the image so we can blow up properly in memory allocation later. This should fix hangs in dEQP-VK.pipeline.render_to_image.core.1d_array.huge.width_layers.r8g8b8a8_unorm_d32_sfloat_s8_uint since Fixes: ad3d98da9f (radv: enable tc compatible htile for d32s8 also.) Now there's an open question if we should be enabling tc-compat htile at all for shallow textures like the above. This might cause some other wierd side effects in CTS even without the tc compat so: Cc: "17.2" Reviewed-by: Bas Nieuwenhuizen Signed-off-by: Dave Airlie --- diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h index ad9ea5ed673..ef0efae3674 100644 --- a/src/amd/vulkan/radv_private.h +++ b/src/amd/vulkan/radv_private.h @@ -1221,15 +1221,15 @@ struct radv_image { /* Set when bound */ struct radeon_winsys_bo *bo; VkDeviceSize offset; - uint32_t dcc_offset; - uint32_t htile_offset; + uint64_t dcc_offset; + uint64_t htile_offset; bool tc_compatible_htile; struct radeon_surf surface; struct radv_fmask_info fmask; struct radv_cmask_info cmask; - uint32_t clear_value_offset; - uint32_t dcc_pred_offset; + uint64_t clear_value_offset; + uint64_t dcc_pred_offset; }; /* Whether the image has a htile that is known consistent with the contents of