New issue
Advanced search Search tips

Issue 856862 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug
Proj-XR
Proj-XR-VR



Sign in to add a comment

Texture hazard on WebVR pages with mirroring

Project Member Reported by billorr@chromium.org, Jun 27 2018

Issue description

Repro:
1. Turn on D3D11 debug layers.
2. go to a webvr page that uses mirroring, for example https://webvr.info/samples/04-simple-mirroring.html
3. Enter VR on windows (requires some flags) - I noticed with Oculus hardware enabled, but it shouldn't be Oculus-specific.

Expected: render in headset and on page correctly.

Actual: D3D warnings will cause debugger to break in:
D3D11 WARNING: ID3D11DeviceContext::OMSetRenderTargets: Resource being set to OM RenderTarget slot 0 is still bound on input! [ STATE_SETTING WARNING #9: DEVICE_OMSETRENDERTARGETS_HAZARD]

Without debug layers, or on WebXR this appears to work correctly.  That said, we should investigate whether what we are doing wrong.

This breaks in inside ANGLE when setting the RTV.  ANGLE has code to detect/fix conflicts, so I'm curious how we are still breaking.

 
StateManager11::syncFramebuffer is the top of the stack before OS code.
Labels: VR-Desktop
Components: Internals>XR
Components: Blink>WebXR
Components: Blink>WebXR>VR
Components: -Blink>WebXR
Components: -Internals>XR Internals>XR>VR
Cc: geoffl...@chromium.org billorr@chromium.org jmad...@chromium.org
Components: Internals>GPU>ANGLE
Owner: ----
Status: Available (was: Assigned)
clarification - by enable debug layers, I mean open up DirectX control panel, and go to break settings to enable break on warning/error/corruption.  I also add Chrome to the list of executables the setting applies to, and click the "force on" button for Debug Layer.

If I go into ANGLE code, and modify Blit11::copyTexture by appending the following two lines at the end:

d3d11::SharedSRV *null_srv = nullptr;
    stateManager->setSimplePixelTextureAndSampler(*null_srv, mPointSampler);

DirectX warnings don't occur in my scenario.

This appears to be an ANGLE "bug", but I don't know if we have a goal of being debug-layer clean.  There is some code in ANGLE to try to detect and avoid hazards, but I haven't stepped through to see why it doesn't catch this.

ANGLE owners, what are your thoughts on this - should ANGLE prevent texture hazards?  Should we be "debug-layer clean"?
Owner: jmad...@chromium.org
Status: Assigned (was: Available)
Yes, we should be clean in the debug layers. It's probably some edge case we haven't covered that is used in WebVR. I'll see if I can track down why our code isn't detecting this.
Labels: BlinkWebXR
Removing Blink>WebVR component and assigning to Blink>WebXR 
Components: Blink>WebXR
Labels: -BlinkWebXR
Removing Blink>WebVR component and assigning to Blink>WebXR 
Components: -Blink>WebVR
Components: Internals>XR
Removing Internals>VR component and assigning to Internals>XR
Components: -Internals>VR

Sign in to add a comment