Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
1493913003:
Ensure that the code in the DXVA DX11 decoder which can potentially access the DX11 device context … (Closed)
|
Created:
5 years ago by ananta Modified:
5 years ago CC:
chromium-reviews, posciak+watch_chromium.org, jam, mcasas+watch_chromium.org, feature-media-reviews_chromium.org, darin-cc_chromium.org, piman+watch_chromium.org Base URL:
https://chromium.googlesource.com/chromium/src.git@master Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionEnsure that the code in the DXVA DX11 decoder which can potentially access the DX11 device context on the decoder thread is locked with the ID3D10Multithread interface.
The ProcessInput call on the color converter does access the DX11 device context on the decoder thread to check states.
This currently executes outside the lock. Moving it inside the lock. With this change the color converter ProcessInput
and ProcessOutput calls are in the lock. Added a class AutoDX11DeviceLock to make the locking more seamless.
The other change is to get rid of the begin streaming calls for the converter and the Flush calls on the context.
These are not necessary now with the single device
If this does not fix the Win8 bot flakiness the last step to try would be to move the copy texture call to the main thread.
Failing that we need to go back to the two device model. All symptoms here point to an NVIDIA driver quirk.
BUG=548383
TBR=dalecurtis
Committed: https://crrev.com/fc9a5766e318f7d331961c87bbeb515df1d5b0f6
Cr-Commit-Position: refs/heads/master@{#363611}
Patch Set 1 #Patch Set 2 : Remove commented out code #
Total comments: 2
Patch Set 3 : Rebased to tip #
Depends on Patchset: Messages
Total messages: 23 (11 generated)
Description was changed from ========== Ensure that the code in the DXVA DX11 decoder which can potentially access the DX11 device context on the decoder thread is locked with the ID3D10Multithread interface. The ProcessInput call on the color converter does access the DX11 device context on the decoder thread to check states. This currently executes outside the lock. Moving it inside the lock. With this change the color converter ProcessInput and ProcessOutput calls are in the lock. Added a class AutoDX11DeviceLock to make the locking more seamless. If this does not fix the Win8 bot flakiness the last step to try would be to move the copy texture call to the main thread. Failing that we need to go back to the two device model. All symptoms here point to an NVIDIA driver quirk. BUG=548383 ========== to ========== Ensure that the code in the DXVA DX11 decoder which can potentially access the DX11 device context on the decoder thread is locked with the ID3D10Multithread interface. The ProcessInput call on the color converter does access the DX11 device context on the decoder thread to check states. This currently executes outside the lock. Moving it inside the lock. With this change the color converter ProcessInput and ProcessOutput calls are in the lock. Added a class AutoDX11DeviceLock to make the locking more seamless. The other change is to get rid of the begin streaming calls for the converter and the Flush calls on the context. These are not necessary now with the single device If this does not fix the Win8 bot flakiness the last step to try would be to move the copy texture call to the main thread. Failing that we need to go back to the two device model. All symptoms here point to an NVIDIA driver quirk. BUG=548383 ==========
ananta@chromium.org changed reviewers: + dalecurtis@chromium.org, jbauman@chromium.org
Defer to jbauman@ on this; I don't know these APIs well enough to provide anything more than a style check. https://codereview.chromium.org/1493913003/diff/20001/content/common/gpu/medi... File content/common/gpu/media/dxva_video_decode_accelerator.cc (right): https://codereview.chromium.org/1493913003/diff/20001/content/common/gpu/medi... content/common/gpu/media/dxva_video_decode_accelerator.cc:2034: AutoDX11DeviceLock device_lock(multi_threaded_.get()); This will hold the lock for all the calls below too. Is that intended or do you want to scope this to ProcessInput() ?
https://codereview.chromium.org/1493913003/diff/20001/content/common/gpu/medi... File content/common/gpu/media/dxva_video_decode_accelerator.cc (right): https://codereview.chromium.org/1493913003/diff/20001/content/common/gpu/medi... content/common/gpu/media/dxva_video_decode_accelerator.cc:2034: AutoDX11DeviceLock device_lock(multi_threaded_.get()); On 2015/12/03 22:09:24, DaleCurtis wrote: > This will hold the lock for all the calls below too. Is that intended or do you > want to scope this to ProcessInput() ? ProcessInput and ProcessOutput.
lgtm
Description was changed from ========== Ensure that the code in the DXVA DX11 decoder which can potentially access the DX11 device context on the decoder thread is locked with the ID3D10Multithread interface. The ProcessInput call on the color converter does access the DX11 device context on the decoder thread to check states. This currently executes outside the lock. Moving it inside the lock. With this change the color converter ProcessInput and ProcessOutput calls are in the lock. Added a class AutoDX11DeviceLock to make the locking more seamless. The other change is to get rid of the begin streaming calls for the converter and the Flush calls on the context. These are not necessary now with the single device If this does not fix the Win8 bot flakiness the last step to try would be to move the copy texture call to the main thread. Failing that we need to go back to the two device model. All symptoms here point to an NVIDIA driver quirk. BUG=548383 ========== to ========== Ensure that the code in the DXVA DX11 decoder which can potentially access the DX11 device context on the decoder thread is locked with the ID3D10Multithread interface. The ProcessInput call on the color converter does access the DX11 device context on the decoder thread to check states. This currently executes outside the lock. Moving it inside the lock. With this change the color converter ProcessInput and ProcessOutput calls are in the lock. Added a class AutoDX11DeviceLock to make the locking more seamless. The other change is to get rid of the begin streaming calls for the converter and the Flush calls on the context. These are not necessary now with the single device If this does not fix the Win8 bot flakiness the last step to try would be to move the copy texture call to the main thread. Failing that we need to go back to the two device model. All symptoms here point to an NVIDIA driver quirk. BUG=548383 TBR=dalecurtis ==========
lgtm
The CQ bit was checked by ananta@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1493913003/20001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1493913003/20001
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: ios_dbg_simulator_ninja on tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...) ios_rel_device_ninja on tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ni...) mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...) mac_chromium_gn_rel on tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_gn_r...) mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
The CQ bit was checked by ananta@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1493913003/20001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1493913003/20001
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...) mac_chromium_gn_rel on tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_gn_r...) mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...) win8_chromium_ng on tryserver.chromium.win (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_ng/...) win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...) win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...) win_chromium_x64_rel_ng on tryserver.chromium.win (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)
The CQ bit was checked by ananta@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from dalecurtis@chromium.org, jbauman@chromium.org Link to the patchset: https://codereview.chromium.org/1493913003/#ps40001 (title: "Rebased to tip")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1493913003/40001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1493913003/40001
Message was sent while issue was closed.
Description was changed from ========== Ensure that the code in the DXVA DX11 decoder which can potentially access the DX11 device context on the decoder thread is locked with the ID3D10Multithread interface. The ProcessInput call on the color converter does access the DX11 device context on the decoder thread to check states. This currently executes outside the lock. Moving it inside the lock. With this change the color converter ProcessInput and ProcessOutput calls are in the lock. Added a class AutoDX11DeviceLock to make the locking more seamless. The other change is to get rid of the begin streaming calls for the converter and the Flush calls on the context. These are not necessary now with the single device If this does not fix the Win8 bot flakiness the last step to try would be to move the copy texture call to the main thread. Failing that we need to go back to the two device model. All symptoms here point to an NVIDIA driver quirk. BUG=548383 TBR=dalecurtis ========== to ========== Ensure that the code in the DXVA DX11 decoder which can potentially access the DX11 device context on the decoder thread is locked with the ID3D10Multithread interface. The ProcessInput call on the color converter does access the DX11 device context on the decoder thread to check states. This currently executes outside the lock. Moving it inside the lock. With this change the color converter ProcessInput and ProcessOutput calls are in the lock. Added a class AutoDX11DeviceLock to make the locking more seamless. The other change is to get rid of the begin streaming calls for the converter and the Flush calls on the context. These are not necessary now with the single device If this does not fix the Win8 bot flakiness the last step to try would be to move the copy texture call to the main thread. Failing that we need to go back to the two device model. All symptoms here point to an NVIDIA driver quirk. BUG=548383 TBR=dalecurtis ==========
Message was sent while issue was closed.
Committed patchset #3 (id:40001)
Message was sent while issue was closed.
Description was changed from ========== Ensure that the code in the DXVA DX11 decoder which can potentially access the DX11 device context on the decoder thread is locked with the ID3D10Multithread interface. The ProcessInput call on the color converter does access the DX11 device context on the decoder thread to check states. This currently executes outside the lock. Moving it inside the lock. With this change the color converter ProcessInput and ProcessOutput calls are in the lock. Added a class AutoDX11DeviceLock to make the locking more seamless. The other change is to get rid of the begin streaming calls for the converter and the Flush calls on the context. These are not necessary now with the single device If this does not fix the Win8 bot flakiness the last step to try would be to move the copy texture call to the main thread. Failing that we need to go back to the two device model. All symptoms here point to an NVIDIA driver quirk. BUG=548383 TBR=dalecurtis ========== to ========== Ensure that the code in the DXVA DX11 decoder which can potentially access the DX11 device context on the decoder thread is locked with the ID3D10Multithread interface. The ProcessInput call on the color converter does access the DX11 device context on the decoder thread to check states. This currently executes outside the lock. Moving it inside the lock. With this change the color converter ProcessInput and ProcessOutput calls are in the lock. Added a class AutoDX11DeviceLock to make the locking more seamless. The other change is to get rid of the begin streaming calls for the converter and the Flush calls on the context. These are not necessary now with the single device If this does not fix the Win8 bot flakiness the last step to try would be to move the copy texture call to the main thread. Failing that we need to go back to the two device model. All symptoms here point to an NVIDIA driver quirk. BUG=548383 TBR=dalecurtis Committed: https://crrev.com/fc9a5766e318f7d331961c87bbeb515df1d5b0f6 Cr-Commit-Position: refs/heads/master@{#363611} ==========
Message was sent while issue was closed.
Patchset 3 (id:??) landed as https://crrev.com/fc9a5766e318f7d331961c87bbeb515df1d5b0f6 Cr-Commit-Position: refs/heads/master@{#363611} |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
