[DEV]Possible way of enabling mali400 dynamic memory use and allocation - Sony Xperia P, U, Sola, Go

I did find this https://groups.google.com/forum/#!topic/linux-sunxi/dYCL84IQH_Yù
In short: changing an option you can have mali do dynamic ram allocation that means it uses only ram that it REALLY needs, not some hardcoded number like 192. So when it is not needing so much ram, system has more free ram. Everyone likes having more usable ram right?
Pasting relevant parts
Siarhei Siamashka said:
After this fix, Mali400 GPU is configured to use up to 256 MiB of
normal memory when CONFIG_SUNXI_MALI_RESERVED_MEM is not enabled.
When CONFIG_SUNXI_MALI_RESERVED_MEM is enabled, it uses 64 MiB of
reserved memory and up to 192 MiB of normal memory (same as before).
Click to expand...
Click to collapse
and this
Mali has MMU and does not strictly need any physically contiguous
memory reservation. Most users will likely prefer more flexible
memory allocation instead of always wasting 64 MiB (even when Mali
is not used or needs much less).
CONFIG_SUNXI_MALI_RESERVED_MEM option is still available and can
be enabled if needed (for performance or some other reasons).
Click to expand...
Click to collapse
I wanted to ask if something like this is doable for our Xperia devices here that have a mali400 (U, Sola, Go and P). And if yes, how can we do this? Or at least try to see if it works.
Is it an option that has to be set in a config file when compiling kernel? Can it be set as build prop or init.d or whatever?
I'm not a dev and I don't have the environment/skill to compile anything so unless it is something easy I'm probably not going to make it myself.
High hopes for this though... :laugh:

---

@95A31 @percy_g2 @DevSwift1

---

I looked to our kernel codes now, it's possible to apply it but I don't know, it shouldn't be that easy :/

---

if the choice of pre-allocating ram for mali was because of "safety" reasons like avoiding potential hacks to pirate stuff or sidestep limitations imposed by licensing or whatever (like for example some of the Xposed Framework's modules that allow youtube content over HDMI port or whatever), it can just be a matter of disabling settings.
Or maybe they pushed it into production before the drivers were stable enough for dynamic ram allocation to work reliably.
Some people running linux on arm boards with a mali400 gpu already recommend to build kernels disabling that option to "maximize available memory".
http://www.malaya-digital.org/make-...-an-external-usb-hard-disk-over-your-network/
pasting relevant part here (note that this is for compiling linux-on-arm kernel and for a different device, stuff may or may not apply to our phones):
9] To maximize available memory, edit .config and look for the line having "CONFIG_CMDLINE". Then edit the line to become::
CONFIG_CMDLINE="[email protected] console=ttyS0,115200 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=8"
10] Look for CONFIG_SUNXI_MALI_RESERVED_MEM, CONFIG_MALI, and CONFIG_MALI400 in .config . Set them to "n" :
CONFIG_SUNXI_MALI_RESERVED_MEM=n
CONFIG_MALI=n
CONFIG_MALI400=n
Click to expand...
Click to collapse
Besides, I don't see why the heck a non-HD-resolution phone must keep 192 mb of dedicated gpu ram when anything else (desktop/laptop or console) can do perfectly fine with full HD resolutions and hardware accelerated h.264 decoding with a crappy card that has only 64mb of ram (and the hardware accelerator, of course).

---

Make more of a difference if we had a rom that actually used the leaked sources so it doesn't run like ****.
However I'd like this still as I don't game on my phone at all, so it's pointless for the gpu to use so much on mine.

---

Are there some devs working on it at the moment? It would be just great to have some MB's more RAM

---

I comparet our kernel with this one and they are totally different. AFAIK is not possible.

---

95A31 said:
I comparet our kernel with this one and they are totally different. AFAIK is not possible.
Click to expand...
Click to collapse
But it's still in AOSP todo, so we can hope? I think this can radically change our user experience, isn't it?

---

Our board uses only 32MB of RAM for Mali, not 64MB

---

Garcia98 said:
Our board uses only 32MB of RAM for Mali, not 64MB
Click to expand...
Click to collapse
then why we have only 392 mb out of 512? i know that some mbs are dedicated to the gpu, but 120mb to gpu????

---

alexhdkn said:
then why we have only 392 mb out of 512? i know that some mbs are dedicated to the gpu, but 120mb to gpu????
Click to expand...
Click to collapse
In Xperia U 15MB are used for memory debugger, 1MB for shared memory, 16MB for modem, 1MB for ISSW, 64MB (may vary) for hardware, 32MB are reserved for Mali and then 383MB (may vary) are available for the system

---

Regarding dynamic memory allocation, I don't think that using it would be a good idea, as it can lead to allocation failures, memory leaks and other logical errors. I'm sure that there is a reason why Igloo Community don't apply Mali dynamic memory allocation to Snowball
BTW, you can read here the opinion of a professional about dynamic memory allocation in real time systems: http://www.mentor.com/embedded-soft...10b6e1-f9e9-4d87-8c88-6ced717a9f7a?cmpid=8688 :good:

---

Said professional even goes further advising against the practice - but yet it landed on sunxi 3.4 branches, with dev even sounding almost shocked by the senselessness of the previous state of affair.
My educate guess is that if Igloo Community never lift a finger, is just because they were axed before such a secondary issue could become relevant, in the grand scheme of things.