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" <[email protected]>

Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>

1 files changed, 4 insertions, 4 deletions

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