Closed
Bug 738189
Opened 12 years ago
Closed 12 years ago
VRAM not reported correctly with Azure in about:memory
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
mozilla16
Tracking | Status | |
---|---|---|
firefox15 | - | --- |
People
(Reporter: tenisthenewnine, Assigned: bas.schouten)
Details
(Whiteboard: [MemShrink:P1])
Attachments
(1 file)
12.32 KB,
patch
|
jrmuizel
:
review+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120321 Firefox/14.0a1 Build ID: 20120321031151 Steps to reproduce: With just one tab opened (on Google's home page) I have been getting this amount of VRAM used, which I thought was normal as its been like this since I can remember. It would slowly grow with the more tabs I used: 12.03 MB ── gfx-d2d-surfacevram Actual results: When I enabled gfx.content.azure.enabled to true and the browser reset to googles , my VRAM usage reported on about:memory was this: 4.00 MB ── gfx-d2d-surfacevram It changes by small amounts, but stays very close to the 4MB mark. Expected results: I would have thought it would still be around the 12-13MB mark. My thoughts are, is about:memory not displaying Azure content properly or is Azure different in some way to make it use less VRAM? Can anyone reproduce?
Updated•12 years ago
|
Component: Untriaged → Graphics
Product: Firefox → Core
QA Contact: untriaged → thebes
Assignee | ||
Comment 1•12 years ago
|
||
Azure content does not correctly report VRAM usage. So about:memory does not display Azure content properly.
(In reply to Bas Schouten (:bas) from comment #1) > Azure content does not correctly report VRAM usage. So about:memory does not > display Azure content properly. Thanks for the reply, this clears it up for me. To get it reported, do I talk to the about:memory guys or is it already in the pipeline?
Summary: VRAM leak with Direct2D turned on, but not with Azure content → VRAM not reported correctly with Azure in about:memory
Updated•12 years ago
|
Whiteboard: [MemShrink]
Updated•12 years ago
|
Blocks: DarkMatter
Whiteboard: [MemShrink] → [MemShrink:P2]
Updated•12 years ago
|
No longer blocks: DarkMatter
Comment 3•12 years ago
|
||
This is particularly bad because Azure content seems to be leaking memory badly (at least with Intel graphics) since it was turned on, and there's no indication as to what's leaking when looking at about:memory.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•12 years ago
|
tracking-firefox15:
--- → ?
Comment 4•12 years ago
|
||
(In reply to Ryan VanderMeulen from comment #3) > This is particularly bad because Azure content seems to be leaking memory > badly (at least with Intel graphics) since it was turned on, and there's no > indication as to what's leaking when looking at about:memory. I am also seeing a big increase in memory use (probably a leak) with azure content turned on. This is with an AMD HD4650 GPU (latest drivers) on Win 7 64bit (32bit moz central nightlies).
Updated•12 years ago
|
Whiteboard: [MemShrink:P2] → [MemShrink]
Updated•12 years ago
|
Whiteboard: [MemShrink] → [MemShrink:P1]
Comment 5•12 years ago
|
||
(In reply to Ryan VanderMeulen from comment #3) > This is particularly bad because Azure content seems to be leaking memory > badly (at least with Intel graphics) since it was turned on, and there's no > indication as to what's leaking when looking at about:memory. That's a separate issue. Ryan, is there a bug filed on that? If not, could you file one? Who is a good candidate for writing a memory reporter for Azure content?
Assignee | ||
Comment 6•12 years ago
|
||
> (In reply to Ryan VanderMeulen from comment #3)
> > This is particularly bad because Azure content seems to be leaking memory
> > badly (at least with Intel graphics) since it was turned on, and there's no
> > indication as to what's leaking when looking at about:memory.
>
> I am also seeing a big increase in memory use (probably a leak) with azure
> content turned on. This is with an AMD HD4650 GPU (latest drivers) on Win 7
> 64bit (32bit moz central nightlies).
Yes, I believe there is a leak. There are bugs which are symptomatic of the leak.
Just for the record, considering the way we do memory counting for video memory it's unlikely the about:memory would show us much useful.
Comment 7•12 years ago
|
||
> Just for the record, considering the way we do memory counting for video
> memory it's unlikely the about:memory would show us much useful.
Well, can we change it? The memory reporter isn't much good if huge leaks don't show up in about:memory.
Assignee | ||
Comment 8•12 years ago
|
||
(In reply to Nicholas Nethercote [:njn] from comment #7) > > Just for the record, considering the way we do memory counting for video > > memory it's unlikely the about:memory would show us much useful. > > Well, can we change it? The memory reporter isn't much good if huge leaks > don't show up in about:memory. Realistically, very hard, there are no good APIs to measure VRAM usage (there has been improvement recently I believe, but I'm not sure), from usermode. And this address space is used by DirectX internally to swap to, it's just magic address space that's part of the working set (not the PWS). We estimate this by counting how much surfaces we allocate, but that doesn't work if some object internal to a surface leaks for example, since DirectX will just keep memory around we don't count. Having said that it would obviously be nice (and not hard), to extend the counting we did with Cairo to Azure.
Comment 9•12 years ago
|
||
We try to measure this with bug 689870 but unfortunately we lack the headers required to make it build.
Comment 10•12 years ago
|
||
(In reply to Bas Schouten (:bas) from comment #6) > Just for the record, considering the way we do memory counting for video > memory it's unlikely the about:memory would show us much useful. It sounds like it's more important to track the bug where we're investigating the memory leak. Please nominate that bug.
Assignee | ||
Comment 11•12 years ago
|
||
(In reply to Alex Keybl [:akeybl] from comment #10) > (In reply to Bas Schouten (:bas) from comment #6) > > Just for the record, considering the way we do memory counting for video > > memory it's unlikely the about:memory would show us much useful. > > It sounds like it's more important to track the bug where we're > investigating the memory leak. Please nominate that bug. That issue has been addressed. I believe, although that crash still exists it's now dropped to an occurrence level where it just indicates a general OOM.
Assignee | ||
Comment 12•12 years ago
|
||
This adds some VRAM usage estimates to Azure.
Assignee: nobody → bas.schouten
Status: NEW → ASSIGNED
Attachment #632452 -
Flags: review?(jmuizelaar)
Comment 13•12 years ago
|
||
Comment on attachment 632452 [details] [diff] [review] Add memory reporting for Azure VRAM Review of attachment 632452 [details] [diff] [review]: ----------------------------------------------------------------- ::: gfx/2d/SourceSurfaceD2D.cpp @@ +17,5 @@ > > SourceSurfaceD2D::~SourceSurfaceD2D() > { > + if (mBitmap) { > + DrawTargetD2D::mVRAMUsageSS -= mSize.width * mSize.height * BytesPerPixel(mFormat); Probably worth having a helper like in DrawTargetD2D
Attachment #632452 -
Flags: review?(jmuizelaar) → review+
Assignee | ||
Comment 14•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/e7b9f828d4c1
Assignee | ||
Comment 15•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/c4083302aa3f
Comment 16•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/e7b9f828d4c1 https://hg.mozilla.org/mozilla-central/rev/c4083302aa3f
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla16
You need to log in
before you can comment on or make changes to this bug.
Description
•