[PATCH 2/2] drm/panfrost: adjusted job affinity for dual core group GPUs

[Steven Price]

On 10/01/2022 17:42, Alyssa Rosenzweig wrote:
>> Whether it's worth the effort depends on whether anyone really cares
>> about getting the full performance out of this particular GPU.
>>
>> At this stage I think the main UABI change would be to add the opposite
>> flag to kbase, (e.g. "PANFROST_JD_DOESNT_NEED_COHERENCY_ON_GPU"[1]) to
>> opt-in to allowing the job to run across all cores.
>>
>> The second change would be to allow compute jobs to be run on the second
>> core group, so another flag: PANFROST_RUN_ON_SECOND_CORE_GROUP.
>>
>> But clearly there's little point adding such flags until someone steps
>> up to do the Mesa work.
> 
> I worry about the maintainence burden (both Mesa and kernel) of adding
> UABI only used by a piece of hardware none of us own, and only useful
> "sometimes" for that hardware. Doubly so for the second core group
> support; currently Mesa doesn't advertise any compute support on
> anything older than Mali T760 ... to the best of my knowledge, nobody
> has missed that support either...

I agree there's no point adding the UABI support unless someone is
willing to step and be a maintainer for that hardware. And I suspect no
one cares enough about that hardware to do that.

> To be clear I am in favour of merging the patches needed for GLES2 to
> work on all Malis, possibly at a performance cost on these dual-core
> systems. That's a far cry from the level of support the DDK gave these
> chips back in the day ... of course, the DDK doesn't support them at all
> anymore, so Panfrost wins there by default! ;)
> 

Agreed - I'm happy to merge a kernel series similar to this. I think the
remaining problems are:

1. Addressing Robin's concerns about the first patch. That looks like
it's probably just wrong.

2. I think this patch is too complex for the basic support. There's some
parts like checking GROUPS_L2_COHERENT which also don't feature in kbase
so I don't believe are correct.

3. I don't think this blocks the change. But if we're not using the
second core group we could actually power it down. Indeed simply not
turning on the L2/shader cores should in theory work (jobs are not
scheduled to cores which are turned off even if they are included in the
affinity).

Thanks,

Steve