1294988 - Enable Direct3D11 in the GPU process

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Comment 1

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: part 1, factor our d3d11.dll loading

This splits d3d11.dll loading into a separate function, so we can have per-process device creation functions rather than one big one that checks the process type.

Comment 2

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: part 2, split up device initialization

This splits device initialization into a compositor half and a content half, to make it clearer which steps happen in which processes.

Comment 3

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: part 3, baseline d3d11 support

This enables D3D11 compositing in the GPU process. As part of initializing the GPU process, we send the FeatureStatus of major features via IPDL. The GPU process imports these into gfxConfig, then creates a D3D11 compositor device if necessary.

With this patch, I can use D3D11 compositing with the GPU process.

This patch doesn't handle some important cases: it doesn't send the adapter information back to content, or the UI. It doesn't send the texture sharing status back. It's just the minimal effort to get D3D11 working. I'll use this bug to keep expanding support.

Comment 4

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: part 0, rename some functions

Whoops, forgot this goes first. This just renames some poorly named functions, e.g. "AttemptDeviceCreation" -> "CreateDevice".

Comment 5

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: part 4, refactor cross-process data

This refactors how we share DXGI/D3D11 information across process. Original functionality is preserved and no new functionality is added.

The old model was that the parent process decides both feature settings and D3D11 device requirements. When a content process needs a device, it requests all of this information in a "DeviceInitData" struct, and caches it. This information is then used by gfxPlatform/DeviceManagerD3D11.

This model is retained, but cleaned up a bit. DeviceInitData is gone. Instead, the two components (preferences and device data) are split into two separate structs. DevicePrefs was added in part 3 and is reused for preferences. The D3D11/DXGI-specific bits are now in a D3D11DeviceStatus struct.

Without the GPU process, things basically look the same. The content process queries all of this information via "ContentDeviceData". The UI-process gfxPlatform fills this in, via gfxConfig and DeviceManagerD3D11. The content process gfxPlatform uses the information to populate its local gfxConfig and DeviceManagerD3D11.

However, now that it's decoupled from gfxPlatform, it'll be easier to integrate the GPU process. Now it'll just be a matter of routing content queries through GPUProcessManager instead of gfxPlatform.

Comment 6

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: part 5, share GPU process device info

This extends the work in part 4 to include the GPU process. gfxPlatform is still responsible for constructing ContentDeviceData. However, if the GPU process is active, it will block until compositor devices have been created. The GPU process then returns a GPUDeviceData, which includes gfxConfig changes and a D3D11DeviceStatus. This is imported back into gfxPlatform in the UI process, before replying to content.

Comment 7

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: part 6, include feature level

For the sake of completeness, this adds the d3d11 feature level to D3D11DeviceStatus. Without this Telemetry will report 0 as the d3d11 feature level when using the GPU process.

Comment 8

[Matt Woodrow (:mattwoodrow)]

Comment on attachment 8782229 [details] [diff] [review]
part 5, share GPU process device info

Review of attachment 8782229 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/ipc/PGPU.ipdl
@@ +62,5 @@
> +
> +child:
> +  // Sent when the GPU process has initialized devices. This occurs once, after
> +  // Init().
> +  async GPUReady(GPUDeviceData data);

Maybe InitComplete() to make it clearer that this is a direct response to Init()?

It would be nice if ipdl syntax supported return values for async calls so that we could have a stricter definition for this sort of thing (GPU process video decoding has the same pattern).

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/57d779cb06b1
Rename DeviceManagerD3D11 helpers. (bug 1294988 part 0, r=mattwoodrow)
https://hg.mozilla.org/integration/mozilla-inbound/rev/aac8c2c3773f
Factor out d3d11.dll handling. (bug 1294988 part 1, r=mattwoodrow)
https://hg.mozilla.org/integration/mozilla-inbound/rev/58e146b5e164
Split device initialization into separate per-process steps. (bug 1294988 part 2, r=mattwoodrow)
https://hg.mozilla.org/integration/mozilla-inbound/rev/5fab3f36dc9d
Enable Direct3D 11 in the GPU process. (bug 1294988 part 3, r=mattwoodrow)
https://hg.mozilla.org/integration/mozilla-inbound/rev/ecd47b2b03d4
Refactor cross-process acceleration controls. (bug 1294988 part 4, r=mattwoodrow)
https://hg.mozilla.org/integration/mozilla-inbound/rev/6c00e4ee0d0c
Communicate GPU process device information across processes. (bug 1294988 part 5, r=mattwoodrow)
https://hg.mozilla.org/integration/mozilla-inbound/rev/627439e91cb9
Add feature level to D3D11DeviceStatus. (bug 1294988 part 6, r=mattwoodrow)

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/57d779cb06b1
https://hg.mozilla.org/mozilla-central/rev/aac8c2c3773f
https://hg.mozilla.org/mozilla-central/rev/58e146b5e164
https://hg.mozilla.org/mozilla-central/rev/5fab3f36dc9d
https://hg.mozilla.org/mozilla-central/rev/ecd47b2b03d4
https://hg.mozilla.org/mozilla-central/rev/6c00e4ee0d0c
https://hg.mozilla.org/mozilla-central/rev/627439e91cb9