Re: GPU memory profiling
729 views
Skip to first unread message
Dongseong Hwang
May 13, 2015, 9:11:32 AM5/13/15
to graphi...@chromium.org, ael...@google.com, sie...@google.com, chromiu...@chromium.org, prim...@google.com
+chromiu...@chromium.org
On Friday, May 1, 2015 at 6:50:56 AM UTC+3, Chris Blume wrote:
At current state my best suggestions would be:
1) dumpsys meminfo, as you pointed out. [1]
2) Looking at mmaps, specifically memory mapped to /dev/kgsl on most Qualcomm chips, or /dev/nv* for nvidia chips, /dev/mali on Arm Mali + *dma*. You can use go/memory-inspector [2] to inspect process mmaps in a civilized way (or, from chrome tree tree, just ./src/tools/memory_inspector/start_web_ui)
How can I look at mmaps in intel device? e.g. Nexus Player. Do you have a plan to allow external contributors to access " go/memory-inspector " ?
In addition, Is there equivalent way to '2)' for chrome os?
- DS
+graphi...@chromium.org
Context: Trying to learn about GL memory usage on Svelte.
Some measurements: https://code.google.com/p/chromium/issues/detail?id=482727
Is there a good way to know what GL allocations are being made?On Thu, Apr 30, 2015 at 6:40 PM, Chris Blume <cbl...@google.com> wrote:Alex noticed that the sum of the *dma* mapping matches EGL mtrack.
This may be SurfaceTexture gralloc buffers?
+Daniel who might know when/where those are expected to be allocated.On Thu, Apr 30, 2015 at 6:22 PM, Chris Blume <cbl...@google.com> wrote:I'm bringing this thread back to life because it looks like perhaps we are using significantly more OpenGL memory than I thought.
Here are some measurements: https://code.google.com/p/chromium/issues/detail?id=482727
Primiano, could you help me understand this?
There are lots of 128 private dirty Kb /dev/kgsl-3d0 . Are these tiles? Do we allocate tiles in 128 Kb chunks?
128 Kb * 1024 Kb per b = 131072 b.
131072 b / 2 b per pixel = 65536 pixels
The square root of 65536 = 256, as I'm sure you know.
So that would mean tiles which are 256 x 256 at 16 bits per pixel.
I seem to recall svelte is 16 bits per pixel but I am uncertain of that.
Anyway, it makes sense to me if these 128 Kb chunks of /dev/kgsl-3d0 are the tiles.
The *dma* allocations are all much larger, but not so large that I am convinced they are the front/back buffers.
The Nexus 4 screen is 768×1280 = 983040 pixels.
983040 * 16 b per pixel = 15728640 b per screen buffer.
15728640 b / 1024 b per Kb = 15360 Kb.
15360 Kb / 1024 Kb per Mb = 15 Mb.
None of the *dma* are 15 Mb.
In fact, the *dma* may not even total up to 18 Mb. So there wouldn't be enough room for a front and back buffer.
Maybe Svelte doesn't run at native resolution?
Also, is there any update on being able to track GL memory allocations? I think we would like to figure out how much memory is being used by tiles and images.
Thanks!
-ChrisOn Mon, Apr 20, 2015 at 4:23 PM, Chris Blume <cbl...@google.com> wrote:After some trouble with Flashstation (and Alex helping me by using his comp to flash...turns out BeyondCorp was my prob and I needed to grab a new, experimental build of flashstation), I ran a quick sanity check of where we stand.
Executive summary: ChromeShell seems to hover around 8 MB GPU memory (according to the memory inspector) and 10,000 kB according to dumpsys meminfo. It seems to restrain itself.
On a Nexus 4 with Svette:
- Before launching ChromeShell:
- 17328 kB: GL -- 14h:44m:20s -- updating apps
- 10784 kB: GL -- 14h:48m:40s -- no-permission-change-updates complete
- 10784 kB: GL -- 14h:57m:20s -- done updating other apps
- 8912 kB: GL -- 15h:05m:00s -- installing release ToT ChromeShell
- 19196 kB: GL -- 15h:09m:20s
- Launched ChromeShell:
- 22028 kB: GL -- 15h:14m:45s
- 10172 kB: GL -- 15h:15m:20s
- 10172 kB: GL -- 15h:17m:45s
- 9596 kB: GL -- 15h:18m:20s -- go to imgur.com
- scrolled up and down imgur, searched for cats on images.google.com...stayed at exactly 9596 kB the whole time
- 14652 kB: GL -- 15h:25m:20s -- minimized ChromeShell
- 9316 kB: GL -- 15h:27m:15s -- resumed ChromeShell
- 9596 kB: GL -- 15h:31m:15s -- scrolling around images.google.com cats
- Opened the memory inspector
- scrolling up and down images.google.com cats
- GPU: 7.7 M
- GPU: 8.1 M
- GPU: 7.8 M
- scrolling up and down imgur.com
- GPU: 9.1 M
- GPU: 7.9 M
- GPU: 7.9 M
- GPU: 7.8 M
- Minimized ChromeShell -- 14652 kB: GL
On Thu, Apr 16, 2015 at 11:52 AM, Chris Blume <cbl...@google.com> wrote:I figured out the Svette-on-Nexus-5 but then reread the email saying Nexus 4 was a stable device and not all devices are good for memory testing. So I started to put Svette on the N4 and it looks like perhaps the server hosting the Android builds may be down for the moment?
Anyway, I looked at go/memory-inspector and was unable to download the extension. But src/tools/memory_inspector/start_web_ui seems to work just fine so I think this is okay. So I'll use this and "adb shell dumpsys meminfo", "GL" category to do a few before-during-after measurements once the Android build server is back.On Mon, Apr 13, 2015 at 4:43 PM, Alexandre Elias <ael...@google.com> wrote:Yes, feel free to borrow devices from my desk whenever you need them.
On Apr 13, 2015 7:41 PM, "Chris Blume" <cbl...@google.com> wrote:Sounds good. I'll try again while checking that box.
If it doesn't work out, Alex, can I borrow and flash a Nexus 4 from your desk?On Mon, Apr 13, 2015 at 4:21 PM, Primiano Tucci <prim...@google.com> wrote:I don't think Svelte was ever actually supported on Nexus 5. I know that there is an image on the flashstation, but I don't think anybody put any effort to make it boot (I personally never heard about anybody using N5 svelte).The reference devices (see go/aupt-svelte) AFAIK far are N4 (occam-svelte) and the new Android one (sprout).The former is IMHO a bit more solid and tested. The latter more in the "bringup" phase.With "more in the bringup phase" I mean that b/18963089 (Graphics memory is not being accounted for on sprout) is still marked as assigned as is getting commits in these days.Extra tip: if you flash a device and go backwards (w.r.t Android build number in the current image) remember to tick the "wipe" checkbox in the flashstation. Most of the app/services do only support upgrade or their data folder and are known to just crash if you go back in time... including the system one which can therefore end up causing cause reboot loops :)On Mon, Apr 13, 2015 at 11:53 PM, Chris Blume <cbl...@google.com> wrote:I am trying to load a Svelte build onto my Nexus 5 and so far every build puts the device in a reboot loop.
I'll let you know if I get anywhere but if you have suggestions let me know.
Thanks!On Thu, Apr 9, 2015 at 3:45 PM, Alexandre Elias <ael...@google.com> wrote:Sounds good, thanks!On Thu, Apr 9, 2015 at 12:48 AM, Primiano Tucci <prim...@google.com> wrote:Hello AlexYeah, the short version is that we are slowly getting there with chrome tracing but, at the moment, we are not there yet with GPU memory (Actually, one day I'll probably fly out there and have a chat with you guys. But in the meanwhile we have a backlog of things that we need to sort out first)At current state my best suggestions would be:1) dumpsys meminfo, as you pointed out. [1]2) Looking at mmaps, specifically memory mapped to /dev/kgsl on most Qualcomm chips, or /dev/nv* for nvidia chips, /dev/mali on Arm Mali + *dma*. You can use go/memory-inspector [2] to inspect process mmaps in a civilized way (or, from chrome tree tree, just ./src/tools/memory_inspector/start_web_ui)[1] Which specific device we are talking about? I am asking because (see this thread on project-svelte) the quality of memory accounting in meminfo strictly depends on the phone / board. My understanding is that currently occam-svelte (n4) is fine, sprout (Android one) is not there yet.We don't have a specific device in mind, I don't expect memory usage to vary significantly by device (as long as the different devices have the same amount of RAM). If occam-svelte builds flashed on a Nexus 4 work the best, then we'll use that. (Chris -- that's a special build you can install with Flashstation that makes Nexus 4s pretend they only have 512MB of RAM.)[2] Background context: memory inspector was my first attempt (0.02) to have some memory profiling tool, before we brought up the go/memory-infra team which has now the goal of getting the memory profiling experience into chrome://tracing. As usual in google memory-inspector is the working, not finished and already deprecated solution and memory in chrome://tracing is the bleeding edge solution which we didn't get yet :)Let me know if you need any further help with the tools.--On Thu, Apr 9, 2015 at 12:31 AM, Alexandre Elias <ael...@google.com> wrote:Hi Primiano, Grace requested a sanity check that our lowEndDevice GPU memory budgets are still doing what we expect and I asked Chris to start looking into it. In the past we just ran "adb shell dumpsys meminfo" looking at the "GL" category and added ad hoc logging to the code. Is that still the best approach to take for GPU memory today, or has your new memory profiling hotness gotten support for GPU memory yet?--
AlexPrimiano Tucci
Software Engineer
Google UK Limited
Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ--Primiano Tucci
Software Engineer
Google UK Limited
Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ
Primiano
May 13, 2015, 1:17:28 PM5/13/15
to chromiu...@chromium.org
Just realized that my previous reply didn't make it to this list:
>How can I look at mmaps in intel device? e.g. Nexus Player.
It should already work for intel devices. Doesn't it?
Let me explain here:
go/memory-inspector was a convenient one-click-to-install chrome app which is built out of $chromium_src/tools/memory_inspector.
it's internal only just because I have not gone yet to the internal legal process to release prebuilts.
If you have a chrome tree, however, there is no need of the prebuilt. You can just run tools/memory_inspector/start_web_ui from a chrome tree, and that will give you the same identical product (actually with more features).
(You can even re-package the chrome app yourself using the script which is checked in).
In summary: there is nothing secret there, it is already public and all its code lives in the chrome tree. I just didn't manage yet to handle the legal pipeline for releasing the chrome app to the public.
> In addition, Is there equivalent way to '2)' for chrome os?
MI is in maintenance mode as we are migrating everything to chrome://tracing.
One of the reasons of switching to chrome://tracing is that chrome://tracing is supported on all the chrome platforms (not just android) and has already lot of timeline-based information (so it will allow to correlate memory measurements with timeline events).
We just brought up a team and we are working on the memory side of chrome://tracing.
Some stuff is already there (try enabling the tracing category "memroy-infra" in a bleeding edge Chrome canary) but the various subsystems are being instrumented as we talk.
GPU memory is one of our priorities but is unfortunately also very tricky to account correctly (due to cross-process sharing).
We are currently working to improve the dumping infrastructure and allow correct dumping of this kind of memory.
Will update you soon as it happens, it is being actively worked on at the time of writing.
Primiano
Reply all
Reply to author
Forward
This conversation is locked
You cannot reply and perform actions on locked conversations.
0 new messages