Hi there,
We are now transplanting our graphics subsystem onto the sunxi-A20 SoC, whose GPU is Mali-400 MP2. But we find that rendering a frame costs about 33ms, which is too slow. And after we did some study on the driver, we found the cause of low performance is that there is only one pp core used during per frame. As we don't have a copy of code of user space libraries, we can only locate the problem in the kernel side. We find out that when start a pp job by the user space, via calling MALI_IOC_PP_START_JOB(ioctl) with args in _mali_uk_pp_start_job_s, there is an attribute named "num_cores"(in _mali_uk_pp_start_job_s) set as 1, which results in that the job cannot be split into more sub jobs. Are there any methods to enable both of the pp cores?
The version of the libraries and drivers we use is "r3p0", and ABI is "armhf", EGL_TYPE is "framebuffer"
Any reply will be appreciated! Thanks all of you guys.
Ailen
Anyone knows?
Hi and welcome to the community! Many of our ARM Mali Graphics team is out of the office for the holidays and returning on Monday, January 6th - their reply might be a bit delayed.
Thank you for your patience and Happy New Year!
Brad
thank you, Brad.Happy New Year!
Hi Ailen,
I am afraid that you need to contact the library/BSP supplier to confirm the build options used for your libraries (and possibly get new libraries). In r3p0 how the user space libraries split the the jobs up is controlled by a build time option, it appears that the drivers you are using are configured to process the PP job as single job (default setting). To enable the use of 2 PPs you will need a driver that is configured, at build time, to split the PP job into at list two sub jobs so they can be allocated to both PP cores.
Hope this helps and Happy New Year,
Mark
Hi Mark,
Thank you very much!
We downloaded the libraries from the Internet, and we did have no idea of the exact build options of our libraries. But we tried to update our pair of libraries and driver into the version of "r3p2 01rel1" and fortunately it worked. The rendering jobs are split into 2 parts now. But we think that the version of the libraries we used now is still low. Could you please tell me where can I get a copy of libraries in higher version?
Thanks again, Happy New Year
Drivers for specific SoCs are intended to be supplied by the SoC vendor, AllWinner in this case, so it's worth approaching them on their roadmap for driver updates. It's possible that they have discontinued software support for that SoC. On occasion ARM do directly supply binary drivers built for select devices at Drivers - Mali Developer Center Mali Developer Center but at present this is only for Midgard family GPUs.
Hth,
Chris
Hi it-ailen
The sunxi-A20 SoC is made by AllWinner. AllWinner are therefore the ones who build the userspace component for this, and it is them you need to ask for later versions.
The latest released driver from ARM to our silicon partners (such as AllWinner) is r5p0, however the distribution of the binaries is controlled by AllWinner for this particular SoC.
Kind Regards,
Michael McGeagh
thanks!
Having seen this thread I decided to check a Mali-450 board we are looking at, which is running r4p0.
In this case, no matter what kind of graphics I try to render, mali_pp_job_create is *always* called with uargs.num_cores = 0.
Then we reach:
So job->sub_jobs_num is 1. Does that mean it is only using one core?
I think it is unlikely that the vendor has made modifications to the libMali behaviour here, or set any non-standard build options.
Is there something different about Mali-450 here, different from Mali 400?
I also found this code:
MALI_STATIC_INLINE mali_bool mali_pp_job_is_virtual(struct mali_pp_job *job) { #if defined(CONFIG_MALI450) return 0 == job->uargs.num_cores; #else return MALI_FALSE; #endif }
MALI_STATIC_INLINE mali_bool mali_pp_job_is_virtual(struct mali_pp_job *job)
{
#if defined(CONFIG_MALI450)
return 0 == job->uargs.num_cores;
#else
return MALI_FALSE;
#endif
}
This suggests that something is different for Mali-450, and that all jobs that are submitted from userspace are virtual jobs. I'm not exactly sure what that means. Does it match expectations? Will multiple cores be used?
Hi dsd,
There is a new job manager for Mali-450, hence why it uses a different path in the driver than the Mali-400 GPU's. As such, we expect it to have its num_cores to be set to 1 for normal operations.
The new job manager will then take this and split it amongst the cores on a dynamic load balancing method, taking into account the overheads, and run on the appropriate number of cores accordingly.
Can I ask, are you seeing a problem... i.e. do you know it is running below the maximum number of cores at all times?
Some platforms have a sysfs entry (if debugfs is enabled) that tells you which cores are enabled and which are not. This entry can vary on different platforms so I cant suggest where to look without knowing the device you have.
If there isn't a problem and you are inferring this from the code, then I would like to say it is safe to see 1, and not to worry, that it is in fact using all the cores if/when it makes sense.
However if you are seeing evidence that not all the cores are being used, it could be that the system has powered off the cores for dynamic power reasons (for example the overhead of splitting a very small job means it doesnt make sense to run that on multiple cores).
That would be controlled by the SoC vendor during integration and they will be able to give you more information as to their power policy, and indeed if they have specifically permanently powered off some cores.
I hope this helped.
Hi mcgeagh
Thanks for the detailed response! I hadn't seen any particular problem, just having seen this thread and seeing that a vendor might have got some build options wrong, I decided to run the same test on my platform.
The sysfs entries suggest that all cores are active, so I think everything is fine. I'll double check with the Mali profiling tools at some point.