VRAM not reported correctly with Azure in about:memory

RESOLVED FIXED in mozilla16

Status

()

Core
Graphics
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Grant, Assigned: bas)

Tracking

14 Branch
mozilla16
x86
Windows 7
Points:
---

Firefox Tracking Flags

(firefox15-)

Details

(Whiteboard: [MemShrink:P1])

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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

5 years ago
Component: Untriaged → Graphics
Product: Firefox → Core
QA Contact: untriaged → thebes
(Assignee)

Comment 1

5 years ago
Azure content does not correctly report VRAM usage. So about:memory does not display Azure content properly.
(Reporter)

Comment 2

5 years ago
(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
Whiteboard: [MemShrink]
Blocks: 563700
Whiteboard: [MemShrink] → [MemShrink:P2]
No longer blocks: 563700
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
tracking-firefox15: --- → ?

Comment 4

5 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).
Whiteboard: [MemShrink:P2] → [MemShrink]
Whiteboard: [MemShrink] → [MemShrink:P1]
(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

5 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.
> 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

5 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.
We try to measure this with bug 689870 but unfortunately we lack the headers required to make it build.
(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.
tracking-firefox15: ? → -
(Assignee)

Comment 11

5 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

5 years ago
Created attachment 632452 [details] [diff] [review]
Add memory reporting for Azure VRAM

This adds some VRAM usage estimates to Azure.
Assignee: nobody → bas.schouten
Status: NEW → ASSIGNED
Attachment #632452 - Flags: review?(jmuizelaar)
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

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/e7b9f828d4c1
(Assignee)

Comment 15

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/c4083302aa3f
https://hg.mozilla.org/mozilla-central/rev/e7b9f828d4c1
https://hg.mozilla.org/mozilla-central/rev/c4083302aa3f
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla16
You need to log in before you can comment on or make changes to this bug.