1123465 - Explain and account for the WriteCombined mappings we see on Windows with Intel

Status: NEW

(Core :: Graphics, defect, P3)

Description

[Jeff Muizelaar [:jrmuizel]]

I get a shared Read/Write/WriteCombined mapping of approximately the texture size when I can create a 2D texture with D3D11_BIND_RENDER_TARGET | D3D11_BIN_SHADER_RESOURCE, D3D11_USAGE_DEFAULT and D3D11_RESOURCE_MISC_SHARED_MUTEX. If I take away the D3D11_RESOURCE_MISC_SHARED_MUTEX the mapping does not occur. I find this behaviour surprising.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

The actual allocation comes from _NtGdiDdDDICreateAllocation which is no surprise. This corresponds to pfnAllocateCb http://msdn.microsoft.com/en-us/library/windows/hardware/ff568893%28v=vs.85%29.aspx

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Using D3D11_RESOURCE_MISC_SHARED instead of D3D11_RESOURCE_MISC_SHARED_KEYEDMUTEX doesn't seem to make thing mapping go away. Also, changing the usage flags seems to make no difference. What I'd like is a way to track texture lifetime to see if we see textures being kept alive. I'm not sure how to do this yet.

Comment 3

[Jeff Muizelaar [:jrmuizel]]

So it looks like we should be able to use SetPrivateDataInterface on the textures to make this work

Comment 4

[Bas Schouten (:bas.schouten)]

Jeff seems to be working on this.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

It looks like "d3d9-shared-textures" and "d3d11-shared-textures" account for most of the write_combined_size in many of the crash reports, but it looks like there's still something missing. We currently don't account for webgl shared textures so that could be it...

Comment 6

[Jeff Muizelaar [:jrmuizel]]

Looking at the about:memory reports that David sent to me it doesn't look like WebGL is being used. This suggests that there's some other bit that's causing this usage. One guess that I had is the memory used by the swapchain.

Comment 7

[(Away)]

FWIW I'm completely fine with the current write-combine situation. Bug 1127925 and bug 1128170 took out the vast majority of issues.

Comment 8

[Ting-Yu Chou [:ting] (away)]

Bug 1266517 comment 12, in 2016-06, 47% of the OOM crashes have >=64M tiny (<1M) free blocks and >=64M write combine memory. Also the memory pattern I saw (bug 1259512 comment 29) was just like what :dmajor described in bug 1101179.

So I am wondering, is it possible to avoid write combine completely to mitigate the fragmentation?

Comment 9

[Jeff Muizelaar [:jrmuizel]]

Do we have memory reports that show where the write-combine mappings are coming from?

Comment 10

[Ting-Yu Chou [:ting] (away)]

AFAIK, no, we only count how big it is [1]. Also I don't think we can know where are they from by just scanning the memory.

[1] https://dxr.mozilla.org/mozilla-central/rev/f378a56b25ce2a2997b263c1857629f3f18d7400/xpcom/base/nsMemoryReporterManager.cpp#954

Comment 11

[Jeff Muizelaar [:jrmuizel]]

(In reply to Ting-Yu Chou [:ting] from comment #10)
> AFAIK, no, we only count how big it is [1]. Also I don't think we can know
> where are they from by just scanning the memory.
> 
> [1]
> https://dxr.mozilla.org/mozilla-central/rev/
> f378a56b25ce2a2997b263c1857629f3f18d7400/xpcom/base/nsMemoryReporterManager.
> cpp#954

We track the size of objects that we believe are associated with the mappings (like the shared textures). This information should be in the memory reports.

Comment 12

[Ting-Yu Chou [:ting] (away)]

I can't find memory report of a crash report on Socorro. :mccr8, do we upload memory report when it's OOM?

Comment 13

[Andrew McCreight [:mccr8]]

(In reply to Ting-Yu Chou [:ting] from comment #12)
> I can't find memory report of a crash report on Socorro. :mccr8, do we
> upload memory report when it's OOM?

First, you need to find a report where ContainsMemoryReport is set to 1. I'm not sure if this is working for content processes or not right now.

Next, you need to take the crash id and look it up in the UnredactedCrash viewer, like this:
  https://crash-stats.mozilla.com/api/UnredactedCrash/?crash_id=b93e36ef-3afc-48da-a857-eb5ec2160330

Make sure you are logged in, and have minidump access. This report should have a memory_report field. Click on "Save", and save it to a file like "report.json".

Finally, go to about:memory, then click on "Load..." and select report.json. That should show you the memory report.

(I'll add these steps to https://wiki.mozilla.org/Platform/Uptime/NightlyCrashAnalysis )

Comment 14

[Ting-Yu Chou [:ting] (away)]

:mccr8, thank you.

Jeff, I captured 3 memory reports from the crash of bug 1266517. The write combine size is from the field "write_combine_size" of Socorro's "Raw Dump", and the other numbers are from the minidump by using dmajor's tool in bug 1001760. 

bp-8c22cc6e-b98f-4097-ad20-e0a5e2160627
  https://goo.gl/dC1TXp
  Free=102M Tiny=102M Misaligned=0M Usable=0M Other=0M WriteCombine=347M
bp-53e57db1-6281-4e45-a0f4-1506e2160622
  https://goo.gl/j5sxAM
  Free=131M Tiny=66M Misaligned=5M Usable=1M Other=59M WriteCombine=198M
bp-a8262ebe-248d-496c-bb7a-d2d412160620
  https://goo.gl/199Xgz
  Free=253M Tiny=82M Misaligned=19M Usable=66M Other=85M WriteCombine=88M

Comment 15

[Ting-Yu Chou [:ting] (away)]

NI for comment 14.

Comment 16

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 24 weeks.