radv/image: bump all the offset to uint64_t.
authorDave Airlie <airlied@redhat.com>
Tue, 17 Oct 2017 07:17:12 +0000 (08:17 +0100)
committerDave Airlie <airlied@redhat.com>
Tue, 17 Oct 2017 07:28:48 +0000 (08:28 +0100)
commit35c66f3e40177a97d74e614e2a324a03e2149c73
tree077dc15c50c51a33016ccb081afea187453e8c8d
parent17201a2eb0b1b8538713691e6a46fb56d76cafe8
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" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
src/amd/vulkan/radv_private.h