diff options
author | Dave Airlie <[email protected]> | 2017-10-17 08:17:12 +0100 |
---|---|---|
committer | Dave Airlie <[email protected]> | 2017-10-17 08:28:48 +0100 |
commit | 35c66f3e40177a97d74e614e2a324a03e2149c73 (patch) | |
tree | 077dc15c50c51a33016ccb081afea187453e8c8d /src/gallium/state_trackers/va | |
parent | 17201a2eb0b1b8538713691e6a46fb56d76cafe8 (diff) |
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]>
Diffstat (limited to 'src/gallium/state_trackers/va')
0 files changed, 0 insertions, 0 deletions