No 3D support available from host

[gelsawy]

Below is my configuration:

1. Workstation 15

2. Host Linux OS: RHEL 7.8

3. Guest OS: Windows 10

4. Host machine GPU: Nvidia quadro k620

5. Enabe 3D acceleration in VM

6. glxinfo | grep "renderer string" on host machine ---> llvmpipe

7. Host machine: OpenGL version string: 2.1 Mesa 18.3.4

And I get the below error while powering up the VM:

No 3D support available from host

And I can't use 3D applications properly inside the VM

Does any one know what is wrong with this configuration?

[Mits2020]

Have you installed the VMware Tools in both host and guest?

[gelsawy]

I installed it on the Windows VM , how to check if it is installed on the Linux host machine or not ?

[scott28tt]

You don't install VMware Tools on the host OS, it's not running in a VM.

[gelsawy]

Yeah that's what I knew , that's why I got confused by the previous question

[gelsawy]

So please do you know why I get no 3D support message, I checked the VMs display driver and it is VMWare SVGA 3D

Shouldn't this enable 3D acceleration?

[scott28tt]

This section of the documentation may help: Configure Display Settings for a Virtual Machine

[banackm]

>6. glxinfo | grep "renderer string" on host machine ---> llvmpipe

>7. Host machine: OpenGL version string: 2.1 Mesa 18.3.4

Those sound like you're not actually running the Nvidia driver and getting acceleration on your X server.  llvmpipe is Mesa's software fallback for configurations that don't have a graphics card.

If the Nvidia driver is installer properly, then glxinfo should show something like:

server glx vendor string: NVIDIA Corporation

OpenGL renderer string: GeForce GTX 1080/PCIe/SSE2

I'd try to re-install the proprietary Nvidia driver, and follow whatever recommendations your Linux distro has for setting that up.

[gelsawy]

I am accessing the machine through a VNC session , could this be the reason for :

glxinfo | grep "renderer string" on host machine ---> llvmpipe

Host machine: OpenGL version string: 2.1 Mesa 18.3.4

[banackm]

Ah... okay yeah.  If you're using Xvnc or something, it normally launches a headless X server that doesn't have direct access to accelerated graphics.

Workstation is supposed to find the accelerated X server on your local console, and then connect to that for graphics while simultaneously connecting to the headless X server (that the UI is running on) for the console display.  That's apparently going wrong here...

If you post a vmware.log I can take a look and try to figure out what's going wrong, and hopefully either give you better advice or see if we can patch this for a future version of Workstation.

Otherwise, as far as immediate work-arounds, you can try either:

(1) Setting the config option: mks.x.displayStringFallback=":0"

(Or replace ":0" with whatever your accelerated X server DISPLAY string is.)

(2) If you launch the VM on the accelerated display, you can turn on "VNC Connections" and then access the VM on your VNC X server via a separate VNC client.

VM Settings => Options => VNC Connections => "Enable VNC Connections"

If you have trouble launching the VM on the other X server, you configure the VM this way in the UI on your VNC X server, and then quit the Workstation UI and manually launch the vmware-vmx process yourself with the correct DISPLAY variable.

DISPLAY=":0" /usr/lib/vmware/bin/vmware-vmx /path/to/vm.vmx

[gelsawy]

Thanks alot for your reply .. I attached the vmware log

[banackm]

We try to start GLRenderer on DISPLAY=":2"

>2020-05-20T06:28:26.714-05:00| mks| I125: MKS-RenderMain: PowerOn allowed MKSBasicOps GLRenderer GLBasic

>2020-05-20T06:28:26.714-05:00| mks| I125: MKS-RenderMain: Collecting RenderOps caps from GLRenderer

>2020-05-20T06:28:26.718-05:00| mks| I125: MKSXInput: XI major version 2, minor version 3

>2020-05-20T06:28:26.720-05:00| mks| W115: GLBackend: Overriding DRI driver blacklistFail to realpath: /usr/lib64/dri/tls/swrast_dri.so, errno=2

>2020-05-20T06:28:26.722-05:00| mks| I125: Denied library: /usr/lib64/dri/tls/swrast_dri.so

>2020-05-20T06:28:26.794-05:00| mks| I125: GLHostX11: Created context with GL 2.1, core: 0, robust: 0, resetStrategy: NO_NOTIFICATION

>2020-05-20T06:28:26.795-05:00| mks| I125: GLHostX11: Found direct rendering display ":2"

>2020-05-20T06:28:26.820-05:00| mks| W115: XINFO XErrorEvent: knownDisplay=1, request 151.34, error 165: GLXBadFBConfig

>2020-05-20T06:28:26.820-05:00| mks| W115: XINFO XErrorEvent: knownDisplay=1, request 151.34, error 165: GLXBadFBConfig

>2020-05-20T06:28:26.820-05:00| mks| W115: XINFO XErrorEvent: knownDisplay=1, request 151.34, error 165: GLXBadFBConfig

>2020-05-20T06:28:26.820-05:00| mks| W115: XINFO XErrorEvent: knownDisplay=1, request 151.34, error 165: GLXBadFBConfig

>2020-05-20T06:28:26.820-05:00| mks| W115: XINFO XErrorEvent: knownDisplay=1, request 151.34, error 165: GLXBadFBConfig

>2020-05-20T06:28:26.820-05:00| mks| W115: XINFO XErrorEvent: knownDisplay=1, request 151.34, error 165: GLXBadFBConfig

>2020-05-20T06:28:26.820-05:00| mks| W115: XINFO XErrorEvent: knownDisplay=1, request 151.34, error 165: GLXBadFBConfig

>2020-05-20T06:28:26.820-05:00| mks| W115: XINFO XErrorEvent: knownDisplay=1, request 151.34, error 165: GLXBadFBConfig

>2020-05-20T06:28:26.820-05:00| mks| W115: XINFO XErrorEvent: knownDisplay=1, request 151.34, error 165: GLXBadFBConfig

>2020-05-20T06:28:26.820-05:00| mks| W115: XINFO XErrorEvent: knownDisplay=1, request 151.34, error 165: GLXBadFBConfig

>2020-05-20T06:28:26.821-05:00| mks| W115: GLWindow: GLHost init failed

>2020-05-20T06:28:26.821-05:00| mks| I125: GL Renderer: Stopping

>2020-05-20T06:28:26.822-05:00| mks| I125: MKS-RenderMain: Failed to start the renderer GLRenderer

...and then it goes wrong.

It looks like you have this config option set:

2020-05-20T06:28:24.307-05:00| vmx| I125: DICT --- USER PREFERENCES /user1/VMs/.vmware/preferences

2020-05-20T06:28:24.308-05:00| vmx| I125: DICT mks.gl.allowBlacklistedDrivers = "TRUE"

That's probably causing us to try to start up on the Mesa driver on the X server without acceleration, rather than continuing to search for a working driver.

I'd try removing that option and see if it will keep searching for the other X server?

[gelsawy]

I attached the vmware.log after removing mks.gl.allowBlacklistedDrivers option , it's another VM but has the same issue of the other VM.

NOte: I am accessing the host machine through VNC session

[banackm]

Hmm.. that one still fails to keep searching for an X server after it finds the blacklisted driver, which is a bug.  We'll look into that internally.

Otherwise, I'd still expect the two work-arounds I gave in the earlier post to work if you pick the correct DISPLAY for the accelerated X server.

[gelsawy]

Thanks .. actually I had no luck in workaround.

I tried workaroud1 by setting option displayStringFallback to :0 , but got the same message (No 3D support)

and couldn't have VM invoked on display :0 .. I have no access to the physical machine and display :0

[gelsawy]

I also found that Windows 10 VM have openGL version 1.1 , do you know how could I upgrade the openGL version on it ?

[banackm]

It may not be ":0", it might be on another port?  (ie ":1" ?)

Otherwise if it didn't work, I have to suspect that you're not actually running Nvidia's driver properly?

I'd try looking at the glxinfo for each of the displays.

For instance, something like:

for i in ":0" ":1" ":2" ":3" ":4" ":5" ":6" ; do

   echo $i

   DISPLAY="$i" glxinfo

done

and see which ones are active, and find the one that says:

server glx vendor string: NVIDIA Corporation

I also found that Windows 10 VM have openGL version 1.1 , do you know how could I upgrade the openGL version on it ?

That looks like Microsoft's built-in software OpenGL implementation.  When you get the VM running with 3D acceleration properly it should automatically increase.

[gelsawy]

I also suspect this ,  I couldn't find any display with Nvidia as renderer string.

I installed the nvidia driver but I am not sure why vnc display can't pick it up

[banackm · Accepted solution]

In X11, access to the GPU is mediated by the X server, which connects to it on start-up.  So you typically have to be running an X server that's configured to use the physical GPU in order for anything on the system to be able to access it through X11.

Normally that means installing the driver, and sometimes configuring /etc/X11/xorg.conf to use the driver.  If the machine is headless (ie no physical monitors plugged into the GPU), some nvidia drivers need this line added to the "Screen" section of the /etc/X11/xorg.conf file:

Option "AllowEmptyInitialConfiguration" "true"

WIthout that line, they'll refuse to start the X server without a display plugged into it.

Beyond that, I'm not familiar enough with RHEL to give you specific advice here on how to setup the nvidia drivers on your system, but if you've installed it properly, and then restarted X11 (or rebooted the system), and it's still not working, the only thing I can think of is that you're not running  a local X server, and you have to restart the appropriate system service.

(You can sometimes do it manually through something like "startx" or "startxfce4" , but there's definitely a supported way to do it on RHEL automatically.)

Normally the /var/log/Xorg.0.log has pretty helpful messages about which drivers X11 started and why.

At that point either you have a local X session, and you are VNC-ing into that (and 3D graphics VMware Workstation should start working), or VNC is launching it's own headless X server and you may have to configure something to get it to find the right X server if that still not working.  (I can't tell anymore if Workstation is at fault here.)

[gelsawy]

Thanks a lot , you were very helpful ..  I will check the setup of X11. may be this will solve the isse