yashsingh1/xdaforums huggingface dataset:
[Nexus 10 Original Android Development] stonebear:
Thanks man. :)

edit

Doesn't look like that works... this is copied from terminal, I had already set no scaling as per Morfics command (echo off > /sys/devices/platform/mali.0/dvfs) that is why it is at 620 at the start. I used your commands to set 533 but it didn't take.

Am I doing something wrong?

u0_a26@manta:/ $ export PATH=/data/local/bin:$PATH

u0_a26@manta:/ $ su

root@manta:/ # cat /sys/devices/platform/mali.0/clock

Current sclk_g3d[G3D_BLK] = 620Mhz

Possible settings : 620, 533, 450, 400, 350, 266, 160, 100Mhz

root@manta:/ #

root@manta:/ # echo 533 > /sys/devices/platform/mali.0/dvfs_under_lock

root@manta:/ # echo 533 > /sys/devices/platform/mali.0/dvfs_upper_lock

root@manta:/ #

root@manta:/ # cat /sys/devices/platform/mali.0/clock

Current sclk_g3d[G3D_BLK] = 620Mhz

Possible settings : 620, 533, 450, 400, 350, 266, 160, 100Mhz

root@manta:/ #
[Nexus 10 Original Android Development] morfic:
It's good enough even for non testers I think.

Just stay away from links that ask you to find breakage, those are the ones you wanna avoid ;)

And TX3 is stable for sure, an earlier build with even less going on, it's on the site already.

Safest bet would be downloading links from the site, those appear after testing in here.
[Nexus 10 Original Android Development] morfic:
Thanks for helping out.
[Nexus 10 Original Android Development] morfic:
Sounds like ktoonsez also was had by the stock behaviour of limiting to 450MHz maybe.

Wonder if that was accidental or intentional on Google's/Samsung's part.
[Nexus 10 Original Android Development] morfic:
Did you disable dvfs? (Don't)
[Nexus 10 Original Android Development] :
Tried the same as stonebear, but dvfs is off after booting your kernel. Using flaming monkey rom.

/ #cat /sys/devices/platform/mali.0/dvfs
G3D DVFS is off
/ # echo on > /sys/devices/platform/mali.0/dvfs
/ # cat /sys/devices/platform/mali.0/dvfs
G3D DVFS is off

Your kernel is fast - even with 533 upper lock. Thanx.
[Nexus 10 Original Android Development] morfic:
that's what i mean the difference in memory after reserved memory was taken out on N4 and N10 differ by only ~219MB

But the amount of free ram on homescreen after booting is more ~700MB

So we could say we roughly are missing 500MB that are not explained by how much is reserved

1687800KB is what we have on N10

1917600KB is what we have on N4

That is the ram as linux/the kernel sees it.

Yet the difference in memory reported as free is far larger than the above difference.
[Nexus 10 Original Android Development] xfinrodx:
So far so good on 10 :) . I'm thrilled to see that someone's thinking about the "big fat pig" in my device too! 2 gigabytes of RAM and I see 700 at boot? Maybe, but it seems fishy.
[Nexus 10 Original Android Development] djd338:
Does anyone know of a widget which shows current CPU temp? I have TKT, but it appears the N10 is not supported yet. Just looking for another simple widget in the interim. Thx
[Nexus 10 Original Android Development] morfic:
Considering our gpu reserves more memory, 1200MB is what we expect.

But reducing the VM heap size made the wall paper smaller (last night).... Guess our memory relates to our resolution.

It is ~4x that of the N4....

Still feel the free memory between my n4 and n10 is backwards, opposite of what I need/want.
[Nexus 10 Original Android Development] xfinrodx:
To test that theory: Could you force the display resolution to 1280x800 (1/4 original) just to see whether it gets close to the expected free memory?

You're right about opposites. It seems like phones on Android tend to perform better than tablets, which is just silly. One X vs. Infinity, Atrix vs. Xoom, N4 vs. N10...
[Nexus 10 Original Android Development] morfic:
Never ran android at anything but native resolution, so I'm not sure if the OS just follows a changed framebuffer or if it pukes..

Maybe I find someone who knows.
[Nexus 10 Original Android Development] amdfanTO:
Forcing gpu use in dev options can lead to increased memory usage. See if there's difference not forcing it in developer options.
[Nexus 10 Original Android Development] squshy 7:
Re: [DER KERNEL] Trinity Ten

What I don't get, though, is why wouldn't those assets be fed into the reserved RAM for the GPU? Isn't that part of what it's there for?
[Nexus 10 Original Android Development] xfinrodx:
It 'should' boot, but without a ton of changes to device configuration it will probably look extremely stupid. The goal really wouldn't be to make a permanently lowered resolution option (who would want to make their display look bad?) but just to rule out whether resolution alone is the cause of the great disparity in RAM use.

That also concerns me. If the wallpaper is eating up both reserved RAM and general system RAM... Might be more of a core OS design issue than a simple 'check box' fix. But then again, maybe the frame buffer itself is being buffered by RAM/page file, which could allow the wallpaper to eat up both. Who's up for soldering bigger RAM chips on their N10? :D
[Nexus 10 Original Android Development] squshy 7:
Re: [DER KERNEL] Trinity Ten

The double buffer would be kind of redundant wouldn't it? With the memory bandwidth of this chip set that just seems unnecessary.

Do we know if it is even eating up reserved RAM? Are we able to check the GPUs RAM usage?

At least to me, it seems that things are pointing towards inefficient usage of the reserved RAM...I wouldn't be surprised to find out it's not being utilized properly/fully.
[Nexus 10 Original Android Development] EniGmA1987:
Some devices have dedicated vram, many do not. Im no expert on the Exynos processors, but I remember hearing that none of the Exynos line uses dedicated chips on the motherboard for vram.
[Nexus 10 Original Android Development] squshy 7:
Re: [DER KERNEL] Trinity Ten

Ah ok, was not aware of that. Withdrawn.
[Nexus 10 Original Android Development] xfinrodx:
Right. I'm not an expert on Exynos either, but I understand the basic concepts of video buffering and OS RAM implementation. From the general understanding, I know that usually a video buffer is (correctly) assumed to be too small to hold all video content that will ever be shown. Either RAM or LTS (long-term storage - HDD, SSD etc.) must be used to hold resources that are not currently being utilized, or are expected to be utilized again soon. So from the screen you may have a buffer system that vulgarly looks like:

What's on screen.

What's in vRAM.

What's in RAM.

What's in swap file.

General filesystem for additional resources that are not buffered in any way currently.

This is an extremely high-level look at a simple, but reasonable solution and is generally represented (though probably with some additions or modifications) in operating systems. vRAM doesn't care whether it's physically implemented in RAM or in discrete chips: vRAM is logically discrete and the OS is likely to use a buffering scheme like what I've outlined. This could explain the behavior we're seeing, with near-or-completely duplicated video buffering in RAM.

These buffers can carry duplicate data and manage themselves discretely. This is easy to see when you open a large image file. The first time you do it, it takes several seconds to completely load. When you turn off the screen then turn it back on immediately, there is no load time since it's already in the video buffer - but it's still on disk too, and also in general system RAM. When you press home, open your app tray, write an email, then go back to open the image again, it takes a fraction of a second: The image was in the system RAM buffer and still in disk storage at that point. So at any point, you might expect to have 3 copies of any arbitrary video resource: One in storage, one in RAM, and one in vRAM if it's currently being used. (note: RAM and swap are usually exposed to applications as the same buffering layer, with an invisible, "atomic" buffering manager being responsible for placing/moving data around between swap and RAM)

We were quoted 2GB, and traditionally one expects a separate, "invisible" frame buffer. You pay for video buffering in system RAM only once with discrete vRAM. However, when we expect to see 2GB and we see 512MB taken once for a frame buffer, then ~50-~1024+ taken again via normal video buffering, it could appear that we are down many hundreds of MB's below what we should be... but it's possible that it's just because we're paying for vRAM essentially twice instead of once and therefore the mechanism is that much more visible (or hurts that much more).

The more I think about it, the more it makes sense why we are seeing so little free RAM.
[Nexus 10 Original Android Development] Lim Wee Huat:
Re: [DER KERNEL] Trinity Ten

A small token of appreciation - 2PN240375H701731N... :) Thanks for build 0, Rascarlo. It's running great with Trinity ten.
[Nexus 10 Original Android Development] byock1:
Same. 6CP90945191689332 :) Let's pull together and get Ras a N10 dev device. :cool:
[Nexus 10 Original Android Development] TheGrayHatter:
How are you guys getting a hold of Ras?
[Nexus 10 Original Android Development] morfic:
Re: [DER KERNEL] Trinity Ten

It's all in his xda profile.
[Nexus 10 Original Android Development] morfic:
http://xdaforums.com/showthread.php?t=2106226
[Nexus 10 Original Android Development] Jayrod1980:
Re: [DER KERNEL] Trinity Ten

It seems like the thing present loads everything just because it can. Before you hit throttling it is the fastest device I've ever used. On WiFi the browser is snappier than my oc dual GPU computer with i5 sandy bridge and 16 gigs of ram in it.

I'm a little upset that the device is so beta. There are a lot of stuff that adds up and hurts the user experience. The throttling, the power consumption, the ram usage, etc. Then there's the screen but can't do much about that. Still love it but perhaps it should have been a bit more conventional.

Morfic, I tried to ask rascarlo where I could donate months ago and he brushed aside the request. No reason either of you should have to buy these when so many get to benefit from your work. I'll put some in the pot.

Sent from my 5th and final Nexus 4
[Nexus 10 Original Android Development] morfic:
I made the post because i know he brushes them off and will not ask for anything.

i see your points, and the throttling hasn't impacted me much and franco's changes should make that better, the ram usage well, it's certainly violating my "numbers brain" and what it thinks things should be, but then you talk about power consumption, and that one blows me away, what did i miss since i bought the device that would make power consumption a bad thing in your book?

I Would like to get some examples of what makes you feel that way.

earlier i streamed music to my jambox and used it little here or there, since i plan on taking the two to work tomorrow i wanted to know how much battery the Ten lost, since i know i used up over 75% of the battery of the jambox (running it full blast the whole time with the liveaudio processing), so i was curious how much the bluetooth streaming to jambox and the play music streaming over wifi had cost me, and the Ten was at 74%, the total time i didn't care for but i was curious how much screen on i accumulated and it was 3:46 hours.

I found myself pleasently surpised even if the screen on had been lower as i used the jambox for ~7 hours, 7 hours bluetooth and wifi were busy fetching files and streaming them to speaker, so i could do this for ~25-28 hours? count me happy (I'm not extrapolating the 3:46 since a lot of it was dim until i interacted with the screen again)

so i'm really curious about your usage and why battery comes up as a negative point

and thanks again for saying thanks to Carlo :)
[Nexus 10 Original Android Development] morfic:
morfic@othris:/data/devstuff/TENDEV/zip$ adb shell cat /sys/devices/platform/mali.0/dvfs

G3D DVFS is on

utilisation:48

morfic@othris:/data/devstuff/TENDEV/zip$

no, that's your rom or an app doing, dvfs is on in this kernel by default
[Nexus 10 Original Android Development] :
Seems to bee something strange: I've run a sleep 10 loop on dvfs, and sometimes it's on; sometimes off... will look in the roms source.

Btw: could it be, that fsync_control.c is missing in your git?
[Nexus 10 Original Android Development] morfic:
so i ran a watch -n1 and dvfs stays on while screen is on

it does turn off when screen is off, and yes GPU clock then reports 620mhz while screen is off

that is some odd choice by them

EDIT: the 620MHz seems o have been a glitch as it now consistently switches to 266MHz on screen off.
[Nexus 10 Original Android Development] morfic:
http://goo.gl/4eMa8S TX10 improved CFLAGS, -50mV on CPU, raised Throttle temperature by 10C for cpu and 5C for memory

http://goo.gl/ep3H7a TX10b, like TX10 with a tiny configuration change
[Nexus 10 Original Android Development] Koopa777:
I can just flash the new kernel over the old one(TX3), correct? Just wipe cache?
[Nexus 10 Original Android Development] szale9001:
Ok so, I decided to give 10b a try. So far so good (not sure what the config change was but I figure all will be revealed in time ;) ).

Found something interesting though regarding the 620Mhz screen off glitch though, [MENTION=1122306]morfic[/MENTION]. For starters, my tablet also does this. When I lock my tablet, the utilisation is set to off and the clock speed ramps up to 620Mhz. However, the weird part was how I locked my tablet dictated whether or not this happened. In other words, if I locked my tablet from the launcher or an app, it would ramp up to 620 no questions asked. However, if I locked the device from the lock screen (in other words, pressing the power button to turn on the device, then pressing it again to turn it off without unlocking it), the clock speed would vary from 350-450 with utilisation off. I tested this numerous times to make sure I wasn't going crazy and I can replicate it almost every time.

As for methods, I used watch -n 1 on clock and dvfs through adb on my desktop. My lock screen is a PIN, though not sure why that should matter.

EDIT: Ok, so this is crazy. On a hunch I decided to disable the screen off animation (thank you CM 10.2), and now I can get the GPU to rest at 100Mhz, but still only if I lock it from the lock screen. Even with the animation off, locking an unlocked device still shoots the GPU up to 620Mhz. Weird sh*t.
[Nexus 10 Original Android Development] morfic:
Just flash over it.

Never wipe cache when flashing kernels, they are not related.
[Nexus 10 Original Android Development] morfic:
My 620MHz glitch was i think me observing it wrong, i always turn off my N10 via power button, and i always get 266MHz, expect for the very first misreport.

Kind of wondering what's going on on yours.

I'm on PA right now, was wondering if my E10 DAC would work on it, but it doesn't, still, kept PA for now.
[Nexus 10 Original Android Development] szale9001:
Not sure, but pressing the power button anywhere besides the lockscreen sends the GPU flying to 620 and it stays there until I turn it back on. When I have a moment I will try PA and see if it does the same as CM. In the mean time, is there any log I can get that would show wth is going on behind the scenes lol?
[Nexus 10 Original Android Development] morfic:
Small side note, the nexus 10 is partially my favorite nexus, yet this thread is the slowest moving threads of them all.

TX38 only registering 848 downloads overall.

Numbers fascinate me :)
[Nexus 10 Original Android Development] stonebear:
Tis a slow forum in general the Manta forum.

I am still not sure what is happening with these terminal commands, when I do the cat command, I( am seeing either 620mhz or 533mhz, whether I disable scaling or not, and whether I set it to 533 or not.

I assume rebooting resets it? That is what I have been doing with that assumption anyway.

I really just want it locked at 620.
[Nexus 10 Original Android Development] callummr:
I know you prefer blind testing, but how should I know which of these to use?
[Nexus 10 Original Android Development] morfic:
You compare them, likely, no-one notices a difference
[Nexus 10 Original Android Development] morfic:
Disable dvfs, do nothing else, locks it to max for me.
[Nexus 10 Original Android Development] stonebear:
OK, I have been trying that and also locking it to 533 and I am not sure where I am up to now, lol. But I think I still got a 533 reading after disabling dvfs....but not 100% sure.

I will reboot and disable dvfs one more time to make sure.

edit

This is what I mean, I disabled dvfs but on the 4th cat command I get 533
[Nexus 10 Original Android Development] morfic:
When I disable dvfs and the cat the clock file in same directory,I read 620, and the fps in basemark taiji agree that it is 620.

(I don't care what the sysfs tells me if you can't measure it.I use basemark taiji since it's quick enough to not bother)

(What I mean by not caring about sysfs is that you can display anything you want as few devs on the n4 got caught doing)

(Some oced but showed stock clock, others oced to a lower frequency than they displayed in sysfs for users to see)

(That's where "how come I can't run frequency X on this kernel? It works on [thatotherkernel]!" Stuff comes from.)

(That's why I'll always benchmark, to verify what I hoped to achieve is actually happening)
[Nexus 10 Original Android Development] morfic:
Anything in dmesg?
[Nexus 10 Original Android Development] stonebear:
Dunno, want me to get one?

(BTW I keep doing the cat command still keep getting 533 and 620, never lower than 533).

edit

I used Syslog and just got all the logs in a zip https://dl.dropboxusercontent.com/u/42242524/2013-08-18_23.18.zip

---------- Post added at 11:27 PM ---------- Previous post was at 11:17 PM ----------

u0_a26@manta:/ $ export PATH=/data/local/bin:$PATH

u0_a26@manta:/ $ su

root@manta:/ # echo off > /sys/devices/platform/mali.0/dvfs

root@manta:/ # cat /sys/devices/platform/mali.0/clock

Current sclk_g3d[G3D_BLK] = 533Mhz

Possible settings : 620, 533, 450, 400, 350, 266, 160, 100Mhz

root@manta:/ # cat /sys/devices/platform/mali.0/clock

Current sclk_g3d[G3D_BLK] = 533Mhz

Possible settings : 620, 533, 450, 400, 350, 266, 160, 100Mhz

root@manta:/ # cat /sys/devices/platform/mali.0/clock

Current sclk_g3d[G3D_BLK] = 533Mhz

Possible settings : 620, 533, 450, 400, 350, 266, 160, 100Mhz

root@manta:/ # cat /sys/devices/platform/mali.0/clock

Current sclk_g3d[G3D_BLK] = 620Mhz

Possible settings : 620, 533, 450, 400, 350, 266, 160, 100Mhz

root@manta:/ #
[Nexus 10 Original Android Development] morfic:
Thanks, I'll have to check from desktop later.

Right now I'm taking care of this:
[Nexus 10 Original Android Development] stonebear:
Hehe, enjoy. :)
[Nexus 10 Original Android Development] morfic:
If you echo a frequency to clock, does it take? (Not sure it also has a store function or just a show function for clock)(if it takes, make it read-only)
[Nexus 10 Original Android Development] morfic:
Limit your cpu to say 800MHz max, does the gpu still cycle?
[Nexus 10 Original Android Development] kylealanr:
I haven't had time today to play with the GPU scaling on TX-10, but I just wanted to say that it run amazing right out of the gate. I've had nothing but problems with this tablet since buying it and have tried multiple ROMs and kernels, and have flashed the factory images back more than a few times. This kennel on the stock 4.3 ROM vindicates my purchase of this device.

Just wanted to share, thanks for the great work. I'll do whatever I can to help testing in the future.
[Nexus 10 Original Android Development] morfic:
It scales to my liking, so you shouldn't have to worry about it unless you have a special interest.

Thanks for the feedback, glad to hear this kernel helps you relax and enjoy the tablet :)
[Nexus 10 Original Android Development] stonebear:
You mean using the commands Brees posted earlier? If so then, I have tried only with 533 and it still cycles between 533 and 620.

Yep.

---------- Post added at 12:17 AM ---------- Previous post was at 12:12 AM ----------

Just tried setting it to 450

u0_a26@manta:/ $ export PATH=/data/local/bin:$PATH

u0_a26@manta:/ $ su

root@manta:/ # echo 450 > /sys/devices/platform/mali.0/dvfs_under_lock

root@manta:/ # echo 450 > /sys/devices/platform/mali.0/dvfs_upper_lock

root@manta:/ # cat /sys/devices/platform/mali.0/clock

Current sclk_g3d[G3D_BLK] = 533Mhz

Possible settings : 620, 533, 450, 400, 350, 266, 160, 100Mhz

root@manta:/ #

I rebooted first but it still doesn't take.
[Nexus 10 Original Android Development] morfic:
What the fajitas turned into.

Not sure I can drag myself to the computer anytime soon after plate #2.
[Nexus 10 Original Android Development] stonebear:
Note to self - make Mexican food soon. :) That looks good.

I am done for the night too, 20 past midnight here.

Basically whatever I set the thing to, no scaling or setting 450 even, I still either get a reading of 533 or 620, it might take 4 "cats" or more to show but it always does.
[Nexus 10 Original Android Development] morfic:
The main focus for me right now is that it does scale to 620 under load and stays there while the load is high and that the fps agree that the gpu is at 620.

Considering it never scaled over 450 before, nothing surprises me.

Keeping in mind that when the nexus 10 came out they discovered there is some tdp limiting the gpu business going on, I'm not really surprised to see the cycling.

Would be nice if I could find the root of this though,I would like having the control the sysfs implies

20 past midnight? You're a Brit then?
[Nexus 10 Original Android Development] brees75:
I tried it with just the DVFS disabled and that was where I was getting the poor performance. Then I added the upper/lower frequency lock and I was flying! Getting top scores in 3DMark and 20 FPS in the Citadel Ultra High bench. I have yet to try out the latest Trinity, first thing on my list when I get home tonight!
[Nexus 10 Original Android Development] stonebear:
Yea, as long as it hits 620 and stays there under load it is good for me. :)

I have CPU set to 1.2 Ghz now and it feels as fast as the 4.2.2 kernel at that speed - whether it is at 533 scaling up to 620 or not.

I am a Brit yea. :)
[Nexus 10 Original Android Development] rubene66:
Tx10 3dmark
[Nexus 10 Original Android Development] brees75:
Complete awesomeness...

TX10b with makelegs CM 10.2
[Nexus 10 Original Android Development] morfic:
I admit, i haven't ran this one in so long i have no idea what stock delivers in that benchmark.
[Nexus 10 Original Android Development] szale9001:
Ok, well I flashed the latest PA (3.96, I think) and I got a slightly different behavior than on CM. On PA, the DVFS would report disabled after the utilisation reached 0 even with the screen on (which is weird because I believe you said this didn't occur for you). This of course would cause the GPU to ramp up to 620 until I touched the screen again. In CM the dvfs stayed on until I turned the screen off and then was disabled, ramping the GPU up. Not sure why my tablet has to be so difficult lol :p .

At any rate, I made a init shell script that dirty fixes my problem in the mean time. Basically it checks every second to see if the dvfs file reports that it is off and when it does, fires an "echo on" command. That way, in CM or PA, after I turn the screen off, the dvfs file gets reverted back to on, the utilisation reports 0, and the GPU rests nicely at 100 until I turn it back on again. Still curious why I get this behavior in the first place though. I tried 10 and 10b and they both did the same thing in regards to dvfs and locking the GPU at 620.
[Nexus 10 Original Android Development] :
I've the very same behavior with flaming monkey. I think - I'm not sure, just guessing because of battery usage and coolness of the device - I think when utilization went to 0 and dvfs goes of, clock is REPORTING 620, but it's just a strange way to signal, the gpu is on 100... Just a guess...
[Nexus 10 Original Android Development] szale9001:
I wondered if it might be a reporting error too. I would certainly rather a reporting error than having the GPU running full throttle when my tablet is sleeping lol.