I don't know that anything actually guarantees this, but if we exceed the limits, we may end up overflowing and trashing random buffers that happen to be nearby in the VMA space, leading to rendering corruption, hangs, or worse.
We should really fix this properly. However, the pitfall has existed for ages, so for now we should at least detect it. Cc: "12.0" <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> --- src/mesa/drivers/dri/i965/brw_fs.cpp | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp b/src/mesa/drivers/dri/i965/brw_fs.cpp index f1a1c87..104c20b 100644 --- a/src/mesa/drivers/dri/i965/brw_fs.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp @@ -6001,7 +6001,21 @@ fs_visitor::allocate_registers(bool allow_spilling) * size linearly with a range of [1kB, 12kB] and 1kB granularity. */ prog_data->total_scratch = ALIGN(last_scratch, 1024); + + assert(prog_data->total_scratch < 12 * 1024); } + + /* We currently only support up to 2MB of scratch space. If we + * need to support more eventually, the documentation suggests + * that we could allocate a larger buffer, and partition it out + * ourselves. We'd just have to undo the hardware's address + * calculation by subtracting (FFTID * Per Thread Scratch Space) + * and then add FFTID * (Larger Per Thread Scratch Space). + * + * See 3D-Media-GPGPU Engine > Media GPGPU Pipeline > + * Thread Group Tracking > Local Memory/Scratch Space. + */ + assert(prog_data->total_scratch < 2 * 1024 * 1024); } } -- 2.8.3 _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
