Open Bug 1429587 Opened 7 years ago Updated 20 days ago

Hardware Rendering disabling in Firefox for VMware Video Driver 8.15.1.50

Categories

(Core :: Graphics, defect, P3)

57 Branch
defect

Tracking

()

ASSIGNED

People

(Reporter: steve.burke, Assigned: aosmond, NeedInfo)

Details

(Whiteboard: [gfx-noted])

Attachments

(2 files, 1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36 Steps to reproduce: Launch firefox on a VM with hardware rendering enabled and located on an ESXi host with a graphics card installed. Connect to the host via SSH and run 'gpuvm' to check usage. In firefox navigate to 'about:support' and confirm hardware usage. Actual results: 'GPUVM' does not list the VM using the graphics card. Navigating to 'about:support' shows the browser does recognize the GPU #1 successfully as 'VMware SVGA 3D' however it shows WebGL Renderer disabled 'FEATURE_FAILURE_UNKNOWN_DEVICE_VENDOR' , Direct2D disabled 'Blocked for your graphics card because of unresolved driver issues.' and D3D11_COMPOSITING disabled because of 'BLOCKLIST_FEATURE_FAILURE_UNKNOWN_DEVICE_VENDOR'. I checked https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers as well as searched bugzilla for any mention of the driver version, 'vmware', or svga and found no results showing VMware video drivers should be blacklisted. Expected results: Firefox should allow rendering to be offloaded from CPU to GPU since we have graphics cards available for use.
Attached file aboutsupport.txt
'about:support' output
Component: Untriaged → Graphics
Product: Firefox → Core
Attached file latest about:support
Spun up a new WIN7x86 VM, installed all microsoft updates, downloaded latest firefox, and confirmed hardware still isn't being used for rendering. I SSH into ESXi hypervisor and run 'gpuvm' and confirm no GPU usage. When launching IE and Chrome I see hardware rendering successfully. Latest about:support attached.
Confirming that Force-enabling blocked graphics by spoofing works successfully. This appears to be a result of code in 'gfxinfo.cpp' whitelisting specific vendors and VMware is not on the list (vendor ID included in about:support). This prevents VMs from utilizing hardware rendering resources for content loaded in Firefox. For example we utilize Virtual Shared Graphic Acceleration (vSGA) in our environment where VMs on a hypervisor share hardware GPUs for 3D acceleration via the physical host. Since the VMware driver isn't whitelisted it doesn't get loaded and rendering can't then be passed to our NVidia M6 mezzanine cards. Is there a way to get VMware added to the whitelist?
I guess this should just follow bug 1421314's example.
Assignee: nobody → aosmond
Priority: -- → P3
Whiteboard: [gfx-noted]
Attachment #8943000 - Flags: review?(jmuizelaar)
Thank you Andrew - before the patch is incorporated into a general release would it be possible for me to test a sandbox build? There appears to be an issue involved GPU rendering with VMware video drivers and the latest versions of Chrome. Chromium made the decision to blacklist VMware drivers but they allow an administrative override flag for testing. I initially requested they remove VMware drivers from the blacklist however my end users are reporting sites not loading correctly. (https://bugs.chromium.org/p/chromium/issues/detail?id=800453) I'm unsure if this would be specific to Chrome or if Firefox Quantum will face similar issues. I won't know until this proposed code change is introduced and we test. It may create the need to allow VMware as outlined in the above patch but blacklist driver versions. I'm unsure if the issue is owned by VMware or Chrome and will be opening a case with VMware dev to review the rendering issues.
Attachment #8943000 - Flags: review?(jmuizelaar) → review+
Just providing an update on Comment 6 - we conducted further testing with vmware and chromium dev teams and the rendering issues we discovered were caused by the 'ignore-gpu-blacklist' switch and were not a result of the graphics drivers. We conducted the same testing using a development version of chrome with vmware unblocked and no issues were detected. They plan on removing the vmware blacklist in version 67. VMware said they reached out to Mozilla dev two weeks ago and haven't heard back. If you need anything additional from me to help get vmware drivers added to firefox let me know. It would be great to be able to offload video from CPU to GPU for systems that support it.
In about:support have a problem with this patch -> 0001-Bug-1429587-Allow-VMWare-drivers-for-hardware-accele.patch WebGL 2 Driver Renderer WebGL creation failed: * Error during ANGLE OpenGL init. * Error during ANGLE OpenGL init. * Error during ANGLE OpenGL init. * Error during ANGLE OpenGL init. * Error during ANGLE OpenGL init. * Exhausted GL driver caps.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:aosmond, could you have a look please?

Flags: needinfo?(aosmond)
Attachment #8943000 - Attachment is obsolete: true
Flags: needinfo?(aosmond)
Severity: normal → S3

Any update on this? It is still blocklisting everything other than Intel, AMD, NVIDIA, and Parallels.

If VMware driver is unstable, I can understand if it is disabled by default, but at least there should be an option in about:config that allows us to force enable it. Currently, all force enabling options in about:config will be overridden by the hard-coded blocklist.

Flags: needinfo?(jmuizelaar)

Spoofing GPU vendor according to https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers can actually enables hardware rendering and provide significant performance improvement without seeing any instability. Hardware video decode does not work though (although about:support claims that it works).

It seems this was finally done without much fanfare in Bug 1641982 rendering this bug obsolete. While I have bugedit privs someone more familiar with current day Mozilla triage should likely deal with it.

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

Attachment

General

Creator:
Created:
Updated:
Size: