summaryrefslogtreecommitdiffstats
path: root/src/mapi/entry_ppc64le_tsd.h
diff options
context:
space:
mode:
authorDave Airlie <[email protected]>2017-10-17 08:17:12 +0100
committerDave Airlie <[email protected]>2017-10-17 08:28:48 +0100
commit35c66f3e40177a97d74e614e2a324a03e2149c73 (patch)
tree077dc15c50c51a33016ccb081afea187453e8c8d /src/mapi/entry_ppc64le_tsd.h
parent17201a2eb0b1b8538713691e6a46fb56d76cafe8 (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/mapi/entry_ppc64le_tsd.h')
0 files changed, 0 insertions, 0 deletions