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
