Closed Bug 1712486 Opened 2 years ago Closed 5 months ago

RenderDXGITextureHost Failed to open shared texture, hr=0x80070057

Categories

(Core :: Graphics, defect, P1)

Firefox 88
defect

Tracking

()

RESOLVED FIXED
104 Branch
Tracking Status
firefox104 --- fixed

People

(Reporter: mkeroppi, Assigned: sotaro)

References

Details

Attachments

(5 files, 4 obsolete files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0

Steps to reproduce:

Go to https://apps.facebook.com/playmyvegas/

Actual results:

Black screen within the app after Firefox has been running a while - the app runs if Firefox is only recently opened.
GFX Failure log shows: GP+[GFX1-]: RenderDXGITextureHost Failed to open shared texture, hr=0x80070057

Expected results:

App runs.

There are other instances of the black screen on other web pages but haven't tracked those consistently.
GFX1 is AMD Radeon(TM) Graphics

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: WebRender' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Graphics: WebRender
Product: Firefox → Core

A few questions -

  1. have you experienced any crashes?
  2. could you check about:crashes and see if there's anything recent?
  3. Could you post your about:support text?

This sounds like a low memory problem, or a driver issue.

Flags: needinfo?(mkeroppi)

The problem seems to be related to oop WebGL. I am going to look into more.

The problem seemed to happen when ID3D11Texture2D is closed before it is opened by RenderDXGITextureHost. It seems similar to Bug 1654477. To prevent the problem, we needs to keep the ID3D11Texture2D alive until it is opened by RenderDXGITextureHost.

But just adding TextureFlags::WAIT_HOST_USAGE_END flag to TextureClient could not address the problem. SharedSurfaceTextureData just owns SurfaceDescriptorD3D10. It does not own the ID3D11Texture2D.

Assignee: nobody → sotaro.ikeda.g

(In reply to Jim Mathies [:jimm] from comment #4)

A few questions -

  1. have you experienced any crashes?
  2. could you check about:crashes and see if there's anything recent?
  3. Could you post your about:support text?

This sounds like a low memory problem, or a driver issue.

Sorry I can't post the entire about:support.
It's not AMD specific. The same problem with Intel UHD Graphics on two separate machines.

Flags: needinfo?(mkeroppi)
Flags: needinfo?(jgilbert)
Flags: needinfo?(jgilbert)
Depends on: 1715937

Am I the only one experiencing this? This bug was on a number of system with different processor/GFX cards.

Component: Graphics: WebRender → Graphics

This appears to have to do with dual graphics card and hdmi display.

Steps:

  1. firefox.exe on integrated GPU -> laptop display
  2. Switch to HDMI display <- discrete card (firefox.exe still on integrated GPU engine)
  3. black box appears on certain firefox displays
  4. works fine on chrome

Seems like a case of us probably trying to mix two different devices, each attached to a different GPU?

Flags: needinfo?(mstange.moz)
Flags: needinfo?(jgilbert)

I don't know how the Windows parts work, I'd put my trust in Sotaro.

Flags: needinfo?(mstange.moz)

I think this is generally the buggy cross-process surface lifetime issue.

Flags: needinfo?(jgilbert)
Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P1

With the patch, the following STR caused the "Failed to open shared texture, hr=0x80070057".

-[1] Open https://developer.mozilla.org/ja/docs/Web/API/WebGL_API/Tutorial/Animating_objects_with_WebGL. And scroll until showing WebGL animation.
-[2] Open a new window
-[3] Open https://www.google.co.jp/maps/ in the new window.
-[4] Scale/Move in https://www.google.co.jp/maps/

As in Comment 7, the problem seems like the following.

  • SharedSurface_ANGLEShareHandle was destroyed before shared handle of ID3D11Texture2D is opened by RenderDXGITextureHost::EnsureD3D11Texture2D().
  • Destruction of SharedSurface_ANGLEShareHandle also caused close of the ID3D11Texture2D.

Ok, yeah, sounds like our known frame lifetime liveness problem.
We really do need a solution for this, but it's complicated since WebGLParent and wr-parent are different actors, even if they're (always?) in the same process these days.
I think it's ultimately a game of telephone where in order to be correct and sound, we have to go:

WebGLChild::HoldFrameUntilAck();
WebGLChild::SendFrameP1 -> webglparent -> compositor-child::SendFrameP2 -> compositor-parent::RecvFrameP2
                                                                                                |
                                                                                                V
WebGLChild::RecvFrameAckP2 <- webgl-parent::SendFrameAck2 <- compositor-child <- compositor-parent::SendFrameAck1
 |
 V
WebGLChild::AckReleasesFrame()

It seems that the lifetime problem could be simpler if IPC actor is used.

Attachment #9269698 - Attachment is obsolete: true
Attachment #9278490 - Attachment description: WIP: Bug 1712486 - Keep SharedSurface of SurfaceDescriptorD3D10 alive during its use by TextureHost → WIP: Bug 1712486 - Keep SharedSurface of SurfaceDescriptorD3D10 in GPU proces alive during its use by TextureHost
Attachment #9278490 - Attachment description: WIP: Bug 1712486 - Keep SharedSurface of SurfaceDescriptorD3D10 in GPU proces alive during its use by TextureHost → Bug 1712486 - Keep SharedSurface of SurfaceDescriptorD3D10 in GPU proces alive during its use by TextureHost
Attachment #9278490 - Attachment is obsolete: true
Depends on: 1772493
Attachment #9279564 - Attachment description: WIP: Bug 1712486 - Add async front buffer posting for out-of-process WebGL → WIP: Bug 1712486 - Add async front buffer posting to compositor for out-of-process WebGL
Attachment #9279564 - Attachment description: WIP: Bug 1712486 - Add async front buffer posting to compositor for out-of-process WebGL → WIP: Bug 1712486 - Add async front buffer posting for out-of-process WebGL
Attachment #9279564 - Attachment is obsolete: true
See Also: → 1769254
Blocks: 1776146
Blocks: 1776148
Blocks: 1776149
Attachment #9280623 - Attachment description: WIP: Bug 1712486 - Add async front buffer posting for out-of-process WebGL → Bug 1712486 - Add async front buffer posting for out-of-process WebGL

Async IPC was added for async front buffer posting for out-of-process WebGL.
Client does not use TextureClient for storing SurfaceDescriptor.
It works basically same way as to in-process WebGL around nsDisplayCanvas, WebRenderCanvasData, WebRenderCommandBuilder and WebRenderBridgeParent.
SharedSurfaces of SurfaceDescriptorD3D10 are kept alive during their usage. It is for keeping a shread handle valid.
Copied data buffers of SharedShurface_Basics are kept alive during their usage. It is for keeping RenderBufferTextureHost valid.

Attachment #9280623 - Attachment is obsolete: true

Somehow D148888 link became invalid. Then posted as a new patch.
https://phabricator.services.mozilla.com/D150197

Attachment #9280623 - Attachment is obsolete: false
Attachment #9282707 - Attachment is obsolete: true
Attachment #9282707 - Attachment is obsolete: false
Attachment #9280623 - Attachment is obsolete: true
Blocks: 1776885

Kelsey prefers more simplified way. But going to land the patch for testing by disabling it.

(In reply to Sotaro Ikeda [:sotaro] from comment #27)

Kelsey prefer more simplified way. But going to land the patch for testing by disabling it.

It was my misunderstanding.

  1. be fixed so it follows the spec with regard to showing exactly the right buffer, and 2) Very eventually, we should have a better way to do things
    but we don't have time to do #2 right now and it sounds like #1 isn't that hard so we should just fix it up to work with your current approach.

(In reply to Sotaro Ikeda [:sotaro] from comment #28)

(In reply to Sotaro Ikeda [:sotaro] from comment #27)

Kelsey prefer more simplified way. But going to land the patch for testing by disabling it.

It was my misunderstanding.

  1. be fixed so it follows the spec with regard to showing exactly the right buffer, and 2) Very eventually, we should have a better way to do things
    but we don't have time to do #2 right now and it sounds like #1 isn't that hard so we should just fix it up to work with your current approach.

I agree because this bug is really severe.

Pushed by sikeda.birchill@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/af98fb4ff148
Add async front buffer posting for out-of-process WebGL r=jgilbert,lsalzman,gfx-reviewers

Backed out for causing build bustages on LayersSurface

Backout link

Push with failures

Failure log 1 // Failure log 2

Flags: needinfo?(sotaro.ikeda.g)
Flags: needinfo?(sotaro.ikeda.g)
Pushed by sikeda.birchill@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/69064ec2225e
Add async front buffer posting for out-of-process WebGL r=jgilbert,lsalzman,gfx-reviewers
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → 104 Branch

Hello! Perfherder has detected this alert https://treeherder.mozilla.org/perfherder/alerts?id=34690
After investigating it looks like the cause could be 69064ec2225eef5f5900a58698e782a411368162. The graph is pretty noisy and unstable. What do you think? Is it alright to file a bug for this?

Hmm, the change seems not related to the alert. It seems not cause such size change.

See Also: → 1781798

I'm on Firefox 104 now, and the black screen is still showing when I'm on a different graphics card.

Bug 1776148 is going to fix the problem, but depending bug of Bug 1776885 became larger than I expected.

(In reply to Sotaro Ikeda [:sotaro] from comment #38)

Bug 1776148 is going to fix the problem, but depending bug of Bug 1776885 became larger than I expected.

Not sure to understand, is the bug fixed ? Cause I still got the bug on firefox 105.0.1.

If Bug 1791693 is addressed the problem should also be addressed. Bug 1776148 was replaced by Bug 1791693.
Can you check if pref webgl.out-of-process.async-present = true works on nightly? pref could be changed from about:config.

You need to log in before you can comment on or make changes to this bug.