1312595 - Figure out why D3D11 DXVA is slower than D3D9 DXVA for some users

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, defect, P1)

Description

[Marco Castelluccio [:marco]]

+++ This bug was initially created as a clone of Bug #1299520 +++

See the discussion in bug 1299520 for more context.

Comment 1

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

What evidence do you have that D3D11 is slower?

Comment 2

[Marco Castelluccio [:marco]]

vonchen in bug 1299520 mentioned that disabling D3D11 made video playing smoother.

Comment 3

[vonchen]

Hi
Just want to report the situations.
Firefox50.0 and AMD Crimson 16.11.4, Win10 64bit 1607+RX460,  this issue still exists.

IMO, for now, as far as I see, this issue is more like a video loading issue, than a slow issue.

I tested this situation on Youtube.

It sometimes loads videos , in this situation video runs very smooth.

It sometimes loads videos but stuck and freezes Firefox for 1~2 seconds while loading, then video plays very smooth.

It sometime do not load videos , only give user a loading circle and black video. Only to reload the page can have a chance to fix.
(In fact it backs to these three random situations unless you are luck enough.)

Back to D3D9 dxva fixed this issue by disabling this setting: 
media.windows-media-foundation.allow-d3d11-dxva

I tested the same situation again on other browses like Chrome and Edge, and Chrome and Edge have no issue on d3d11 dxva as I tested before.

I found a similar issue bug report on Chrome bug forum at early day, they already fixed the issue , it maybe can be a reference.

https://bugs.chromium.org/p/chromium/issues/detail?id=330271

Comment 4

[vonchen]

Hi
Some news for this issue.
There is a thread talking about d3d11va issue in AMD driver at AMD community :
https://community.amd.com/thread/208125
It was saying that if using a command line arguments to disable Chrome driver issue work around, then it will has issue with d3d11va.

I can reproduce the issue on Chrome with the command line arguments:
chrome.exe --disable-gpu-driver-bug-workarounds --ignore-gpu-blacklist --use-angle=d3d11

Chrome what I used is release version.

So maybe, this issue is still an AMD side driver issue in d3d11 dxva. But Chrome do a Workaround so it seems play fine with d3d11 with AMD driver.

I am not saying Firefox has to do the d3d11 workaround too, but maybe someone here want to know this.

For now to disable this setting is still the best way(no need to wait for fix) to avoid d3d11 dxva not loading/hang issue on Firefox :
media.windows-media-foundation.allow-d3d11-dxva

Comment 5

[Milan Sreckovic [:milan] (needinfo for best results)]

This is good info, thanks!

Comment 6

[Matt Woodrow (:mattwoodrow)]

(In reply to vonchen from comment #4)
> Hi
> Some news for this issue.
> There is a thread talking about d3d11va issue in AMD driver at AMD community
> :
> https://community.amd.com/thread/208125
> It was saying that if using a command line arguments to disable Chrome
> driver issue work around, then it will has issue with d3d11va.

This thread seems to primarily be about a rendering issue, not a performance one. Do you see the rendering problems when running chrome with the flags, or just the slowness?

> 
> I can reproduce the issue on Chrome with the command line arguments:
> chrome.exe --disable-gpu-driver-bug-workarounds --ignore-gpu-blacklist
> --use-angle=d3d11

What happens if you don't pass '--ignore-gpu-blacklist'?

Can you please attach the contents of chrome's chome://gpu page when you're running chrome in the working configuration (without the command line flags).

Comment 7

[vonchen]

(In reply to Matt Woodrow (:mattwoodrow) from comment #6)
> This thread seems to primarily be about a rendering issue, not a performance
> one. Do you see the rendering problems when running chrome with the flags,
> or just the slowness?
Ok,I see rendering problems, but not slowness.So the thread is about rendering issue.

> What happens if you don't pass '--ignore-gpu-blacklist'?
Still the same rendering issue.
 
> Can you please attach the contents of chrome's chome://gpu page when you're
> running chrome in the working configuration (without the command line flags).
The driver is 16.12.1(ReLive)
http://i.imgur.com/8sjasMw.jpg

Chrome:
http://i.imgur.com/HAHmZ5h.jpg

Graphics Feature Status
Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Native GpuMemoryBuffers: Software only. Hardware acceleration disabled
Rasterization: Software only, hardware acceleration unavailable
Video Decode: Hardware accelerated
Video Encode: Hardware accelerated
VPx Video Decode: Hardware accelerated
WebGL: Hardware accelerated

Problems Detected
New AMD drivers have rendering glitches with GPU Rasterization: 653538
Disabled Features: gpu_rasterization
AMD cards have rendering issues with GPU rasterization on Windows: 660897
Disabled Features: gpu_rasterization
Native GpuMemoryBuffers have been disabled, either via about:flags or command line.
Disabled Features: native_gpu_memory_buffers

Comment 8

[Paul Blinzer]

(In reply to Matt Woodrow (:mattwoodrow) from comment #6)
> (In reply to vonchen from comment #4)
> > Hi
> > Some news for this issue.
> > There is a thread talking about d3d11va issue in AMD driver at AMD community
> > :
> > https://community.amd.com/thread/208125
> > It was saying that if using a command line arguments to disable Chrome
> > driver issue work around, then it will has issue with d3d11va.
> 
> This thread seems to primarily be about a rendering issue, not a performance
> one. Do you see the rendering problems when running chrome with the flags,
> or just the slowness?
> 
> > 
> > I can reproduce the issue on Chrome with the command line arguments:
> > chrome.exe --disable-gpu-driver-bug-workarounds --ignore-gpu-blacklist
> > --use-angle=d3d11
> 
> What happens if you don't pass '--ignore-gpu-blacklist'?
> 
> Can you please attach the contents of chrome's chome://gpu page when you're
> running chrome in the working configuration (without the command line flags).

The issue mentioned in the link above should now be fixed with the Crimson 17.3.1 driver release (caused by some incorrect handling of NV12 surfaces in some corner cases).

Comment 9

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

(In reply to Paul Blinzer from comment #8)
> The issue mentioned in the link above should now be fixed with the Crimson
> 17.3.1 driver release (caused by some incorrect handling of NV12 surfaces in
> some corner cases).

Note that bug 1340398 will hopefully land soon so it may (or may not) change which edge cases we hit.

Comment 10

[vonchen]

Hi Paul
Thanks for the info.

I re-tested the issue with Relive 17.3.1 and Chrome 56.0.2924.87 (64-bit).
And it seems fixed. At least I did not notice anything wrong.

I am using RX470 now(I replaced the old RX460 for more GPU power) but it should be no different on testing this issue.

My configuration:
Windows 10 64bit
Relive 17.3.1
Powercolor Red Devil RX470 4G
http://i.imgur.com/7cf0kxq.png

---
Hi everyone
As for the issue of this thread mentioned(random probability Firefox window freezes while loading/switching youtube video with D3D11 H/W enabled on my AMD RX460/RX470s), it seems fixed too with Firefox52.0 and 17.3.1.

I tested Firefox 51.0.1 and new released Firefox 52.0(with d3d11 + h264ify enabled).

Firefox 51.0.1: only happen once when I have heavy loading tabs(many tabs), but not happen if I use clean profile.

Firefox 52.0: seems no issue even with my daily using profile(many tabs opened).

I do not test this in detail, but I do the same testing that mentioned on  bug 1299520 , and I can not re-produce the issue in a short time(as before, with a clean Firefox profile) with Firefox 52.0 and Relive 17.3.1.

So basically the issue seems fixed on Firefox52.0 or 17.3.1 in my opinion ,but I wonder I should test it more days to confirm.
Iif anything got wrong I will report it back.

Comment 11

[Paul Blinzer]

(In reply to vonchen from comment #10)
> Hi Paul
> Thanks for the info.
> 
> I re-tested the issue with Relive 17.3.1 and Chrome 56.0.2924.87 (64-bit).
> And it seems fixed. At least I did not notice anything wrong.
> 
> I am using RX470 now(I replaced the old RX460 for more GPU power) but it
> should be no different on testing this issue.
> 
> My configuration:
> Windows 10 64bit
> Relive 17.3.1
> Powercolor Red Devil RX470 4G
> http://i.imgur.com/7cf0kxq.png
> 
> ---
> Hi everyone
> As for the issue of this thread mentioned(random probability Firefox window
> freezes while loading/switching youtube video with D3D11 H/W enabled on my
> AMD RX460/RX470s), it seems fixed too with Firefox52.0 and 17.3.1.
> 
> I tested Firefox 51.0.1 and new released Firefox 52.0(with d3d11 + h264ify
> enabled).
> 
> Firefox 51.0.1: only happen once when I have heavy loading tabs(many tabs),
> but not happen if I use clean profile.
> 
> Firefox 52.0: seems no issue even with my daily using profile(many tabs
> opened).
> 
> I do not test this in detail, but I do the same testing that mentioned on 
> bug 1299520 , and I can not re-produce the issue in a short time(as before,
> with a clean Firefox profile) with Firefox 52.0 and Relive 17.3.1.
> 
> So basically the issue seems fixed on Firefox52.0 or 17.3.1 in my opinion
> ,but I wonder I should test it more days to confirm.
> Iif anything got wrong I will report it back.

Excellent, thank you for confirmation. Looks that the driver workaround can be removed and Firefox now can use the DX11 paths for composition and video playback. Jeff can the blacklist entry be removed then for this driver?

Comment 12

[Marco Castelluccio [:marco]]

I think we've never blocked the new driver, only the one which was causing the crash (bug 1299520).

Gerald, can you confirm?

Comment 13

[Paul Blinzer]

Any update here?

Comment 14

[vonchen]

Hi

After testing 2 months with this topic, I am afraid I have to say this issue is still there. 

But things is not so no hope, and I believe that there is another factor I did not considered while testing this issue. It seems that support multi-thread or not is one of a factor of this issue too. For Edge and Chrome, they are already multi-thread supported for a while , and starting from recent version, Firefox has more good support for multi-thread, although still has many limits on it.

When come to multi-thread , I obviously have a very smooth using experience with Firefox.

To sum up:
1.Single-thread mode :  I still experience a small freezing issue if Firefox runs on single-thread mode on D3D11 DXVA.
This often happens while doing forward or backward operation from current playing video web page to previous video web page. It will finally plays fine if I don't want to carp about it. Except this, I did not see any noticeable delay or freezing/crash things.

One thing I have to say , is that I have a TDR issue again while using pre-Creators Update driver on Window 10 1703 Creators Update, but soon AMD released a Creators Update supported driver and it works fine again. So basically this TDR issue is already fixed(on Creators Update).

2.Multi-thread mode : I have no any freezing issues on D3D11 DXVA. Basically I have the same using experience as Chrome or Edge.
(I have to say you still see the page seems freezing, but other tabs and whole Firefox works without lag or freezing.)

I thinks it is unfair if I compare Firefox with Chrome or Edge without considering Multi-thread mode factor. I have to say to support multi-thread is a right-way for Firefox. Although I have to give up some addons and modify Firefox's about:config to get it be enabled for now.

Conclusion
So for now I think new Multi-thread feature should be a good work-around of this issue. Or at least it makes the issue not impact to user experience directly. But the issue,that while switching form one video page to another video page caused freezing, is still exists at somewhere by unknown reason.

===
There are two limits for Firefox to enable multi-thread feature:
A.accessibility function(So I disable it in Firefox)
0.Type "about:config" in URL bar.
1.set "accessibility.force_disabled" to "0"
2.delete "accessibility.lastLoadDate" if it exists. To delete it , in Firefox , right-click on it and use "reset" option.
If you are using a clean profile, you have to at least install one addon ex: h246ify once, or Firefox still not enable multi-thread feature.
You can remove h246ify after that but since at this topic we are testing DXVA instead of VP9 so anyway have to install h264ify.

B.Addons that not supporting multi-thread feature
For unknown reason , Add-on Compatibility Reporter does not identify addons correctly  even it says the addon support multi-thread. For example Tab Mix Plus or MEGA addon. If I enable these kind addons , Firefox still disables multi-thread feature. 

So for addons If anyone want to try multi-thread feature, I suggest that try addons one by one.

There is a way to forcing Firefox to use multi-thread feature by modify this :
"browser.tabs.remote.force-enable"
Set it to "True" can force Firefox to use multi-thread feature, but I do not suggest this , because of the Addons Compatibility. Some addon can not function correctly under this mode even Add-on Compatibility Reporter says it supports.

Comment 15

[Paul Blinzer]

(In reply to vonchen from comment #14)
> Hi
> 
> After testing 2 months with this topic, I am afraid I have to say this issue
> is still there. 

Is it really the same issue/root cause?
From your updated description it sounds that there may be similar general symptoms ("hesitation") but the options that influence the behavior seem to indicate a different toot cause than before, specifically the graphics vs general browser behavior. Definitely so, as you mentioned yourself previously that the original problem is "gone" and it seems to be now limited to specific situations.

Single-thread mode will typically be more prone to "hesitation" as certain work items are serialized and if any one of them takes slightly longer than average, things may get delayed for the graphics jobs behind them. From your description you see some hesitation only when you have many tabs with your custom profile open (most likely addons running too), correct?
You do not mention if the change between D3D11 and D3D render makes any difference here, as it did in the past, you only mention multi-threaded making a difference...

So from that it seems the original problem is fixed now (that root cause was well understood), but you may experience vaguely similar symptoms. Your descriptions are not quite clear, but since multi-thread mode is now the default for Firefox, I am not sure if there is anything actionable here for either Firefox or the graphics driver.

If you can create a system profile trace when this issue happens (or define a detailed system setup description with all add-ons you are using) then it may be possible to analyze where the CPU and GPU time goes here. I have tried to recreate your scenario and was unable to do so for the last few days. 

So, could you please provide the detail data when exactly you see the issue relatively reliably (URL, addons, etc.) or provide a perf trace that shows it (If you know how to generate one) ?

Comment 16

[vonchen]

Hi Paul
First thanks for reading my report and testing.
I think you are right. I see the same symptom , but not necessarily means it is the same issue or root cause.

Today I done some testing on this topic again, I found the symptoms can not be reproduced every time I try it.
So , sometime it occurs but next time it didn't happen. It become a random symptom so I reported it is fixed at first but found it again at next testing.

I make a new video(size 29MB) to demo the issue which I see:
https://drive.google.com/file/d/0Bx6pDxKyikytbjh3MVhhM2pmdlk/view

Notice the red loading bar on the top of the page, when it suddenly stops, I have chance to got the issue. But not every time.
http://i.imgur.com/dWb3diz.jpg

Also notice the mouse cursor, when it moves on tab it try to click on it but Firefox did not switch the tab immediately(no response at the moment).
At 00:41 I click on "about:config" tab but it delay to switch to it, at the moment the Firefox is no responding.

After recorded the video, I keeps testing the issue, I still can reproduce it for a while. 

"But suddenly it gone", for now I can not reproduce the symptom on the video, everything seems fine again.

So for now I may still say this issue is fixed since I have good experience with latest version Firefox with multi-threaded feature enabled. And I agree there is nothing to do on graphic driver or Firefox for now if I do not have a more clear proof and steps to reproduce this issue. 

I am confusing too, so maybe the root cause is another.

As for the D3D9 or D3D11 differences, since I can not producing the issue for now, I can not tell if they have differences.

As for the system profile, I am not familiar with tracing tool to do a system profile so I am not able to provide it. But I can give the description of the system if you still need it:

Firefox profile:
A clean profile with only h264ify add-on installed can produce the issue on my case.

But if you want to know, for now I only use the following add-on on my Firefox profile:
1.H264ify
2.uBlock Origin
3.Zoom Page
4.YouTube Video and Audio Downloader
5.Session Manager
For the multi-threaded support, I give up many add-on. And not use over 10 tabs to avoid lag.

Firefox profile location:
I use it on SSD now. While I tested it in past is on hard driver.

Video:
https://www.youtube.com/watch?v=6Dakd7EIgBE&index=1&list=RD6Dakd7EIgBE
For more clear, the videos that default runs with VP9, but use h264ify add-on to force it to run with H.264 format.

Hardware:
INTEL E3-1230v2
Gigabyte B75M-D3H BIOS F15(no overclocking)
Kingston DDR3 1333 8Gx2+2Gx2
Creative Audigy Rx
PowerColor RedDevil RX470 4GB
Seasonic G-650W

Hard driver:
Micron Crucial MX300 275GB SSDx1 with SATA6G for OS and APP.
Hard driverx4 with SATA3G for file storage.
I use IRST 13.1.0.1058 driver from Intel for B75 AHCI driver on Windows 10.
Only driver installed, no IRST software installed. This is a win8.1 driver basically, but I have no choose.

OS:
Windows 10 Pro x64 1703 Creators Update(15063.296)
Graphic driver: Relive 17.5.1

Comment 17

[Paul Blinzer]

Von, 

thanks. we'll try to recreate the issue based on the updated info; I wonder if h264ify or one of the add-ons has some weird impact here. The system used here didn't have any addons. but otherwise was not that different in terms of performance level. 

In any case, it may be worthwhile for you to see if the same issue can be repro'd with a clean Firefox build (e.g. no add-ons). 
I specifically wonder about the "zoom page" add-on. 

You may also consider opening a specific bug here for the configuration, and closing this one. From your description the symptoms are somewhat similar but the repro frequency and type has changed (which may indicate a different root cause).

Comment 18

[Paul Blinzer]

Von,

any update from your side?
Did you file the new ticket already? What keeps this ticket open from your side?

Comment 19

[vonchen]

Hi Paul,
Sorry for so long time.

Since the bug is randomly, I am not sure if we should close it immediately at that time. But after 2 months , seems I did not have this issue anymore for a long time with multi-thread feature, I think it should be the time to close it now.

But I do not know how to close the thicket , the ticket is created(clone) from another ticket by Marco but not me in fact.

I will try to find the way to close it, but if someone know and can do it I will appreciate.

Thanks everyone for replying and helping this ticket.

Comment 20

[Paul Blinzer]

Von, thank you for the information. Since that issue has not reoccurred for the last couple months, I think it can be closed now. 
Jeff or Marco, could you please resolve the ticket as fixed?

Comment 21

[Marco Castelluccio [:marco]]

Thanks everyone!