From 058faf5a4bd448e1c188042ea017f8fbfd565b9e Mon Sep 17 00:00:00 2001 From: Alyssa Rosenzweig Date: Tue, 4 Feb 2020 14:15:27 -0500 Subject: [PATCH] panfrost: Update comment about magic number relating to barriers It's a complicated story. But from what I can tell, in GL compute without barriers, the blob is able to redistribute the workgroups in various ways (that are not yet understood), whereas with barriers it cannot redistribute anything, which accounts for erratic workgroup packing without barriers. Signed-off-by: Alyssa Rosenzweig Part-of: --- src/panfrost/encoder/pan_invocation.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/panfrost/encoder/pan_invocation.c b/src/panfrost/encoder/pan_invocation.c index 093cd62bfc6..d86b16a2643 100644 --- a/src/panfrost/encoder/pan_invocation.c +++ b/src/panfrost/encoder/pan_invocation.c @@ -86,8 +86,8 @@ panfrost_pack_work_groups_compute( /* Quirk: for graphics, workgroups_x_shift_2 must be at least 2, * whereas for OpenCL it is simply equal to workgroups_x_shift. For GL - * compute, it seems it might *always* be 2, but this is suspicious and - * needs further investigation. (I'm probably just using GL wrong). */ + * compute, it is always 2 if no barriers are in use, but is equal to + * workgroups_x_shift is barriers are in use. */ unsigned shift_2 = shifts[3]; -- 2.30.2