Bug in VMWare Fusion graphics driver?

[hexadecagon]

I'm running Ubuntu 16.04.3 with "OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.3.3" using VMWare Fusion Professional Version 10.1.1 (7520154), and the following OpenGL command seems to have weird side-effects:

glPolygonMode(GL_FRONT_AND_BACK, GL_LINE)

See this bug report for details: Entity selection box not anchored to entity · Issue #53 · ilpincy/argos3 · GitHub

Disabling "Accelerate 3D Graphics" in the VM options fixes the issue, so it seems to be a bug in the VMWare Fusion graphics driver.

Is this a known problem?

[bluefirestorm]

Assuming that your Mac host machine is Metal capable; Fusion 10.x would be using Metal as its render device when 3D acceleration is enabled.

Try this as a possible workaround, enable the 3D acceleration but disable the Metal renderer and it should fall back to OpenGL (just like Fusion 8.x).

Disable the Metal renderer by adding the line

mks.enableMTLRenderer = "FALSE"

to the vmx configuration file of the Ubuntu VM.

[hexadecagon]

Thanks for the quick reply bluefirestorm​.

I tried adding the line mks.enableMTLRenderer = "FALSE" to my vmx configuration file, but the problem still persists. The only change is that lines are now rendered slightly differently.

Is rolling back to an older version of VMWare Fusion likely to make a difference?

[bluefirestorm]

Rolling back to an earlier version of Fusion is unlikely to make any difference.

Maybe just to make sure that OpenGL rendering is used, you could add

mks.enableGLRenderer = "TRUE"

What might make a difference is if you have MacBook Pro that has both Intel integrated graphics and discrete graphics such as Nvidia/AMD as the underlying implementation Metal/OpenGL might have subtle differences aside from the graphic drivers are different. There was a version of macOS Sierra where Fusion 8.x suffered black screens when using Intel Broadwell integrated graphics and the fix was in macOS Sierra (so presumably it was an Intel graphics driver problem).

The default is discrete graphics is not used when the MacBook Pro is on battery power but is used when plugged onto the mains.

You can check/verify from the vmware.log as to which graphic device is used. I don't have a MacBook Pro with discrete graphics and I am still on Fusion 8.x. The sample log below are entries for a Windows 10 VM. It shows that it started "GLRenderer". I assume there should be something similar if it were Metal.

| svga| I125: GLHostMacOS: Renderer[0] = Intel Iris Pro OpenGL Engine

| svga| I125: OpenGL Version: "4.1 INTEL-10.25.19" (4.1.0)

| svga| I125: OpenGL Vendor: "Intel Inc."

| svga| I125: OpenGL Renderer: "Intel Iris Pro OpenGL Engine"

| svga| I125: MKS-RenderMain: Starting GLRenderer

[hexadecagon]

Thanks again for the advice ​.

I tried setting mks.enableGLRenderer = "TRUE", but unfortunately it did not solve the problem.

I tested it with both the integrated and discrete graphics, as verified by the logs:

| svga| I125: GLRenderer: OpenGL Version: "4.1 INTEL-10.30.12" (4.1.0)

| svga| I125: GLRenderer: OpenGL Renderer: "Intel HD Graphics 4000 OpenGL Engine"

| svga| I125: GLRenderer: OpenGL Version: "4.1 NVIDIA-10.28.10 355.11.10.10.20.111" (4.1.0)

| svga| I125: GL Renderer: Starting on "NVIDIA GeForce GT 650M OpenGL Engine"

[bluefirestorm]

Is there any way within the Argos code that OpenGL initialisation code that the Core Profile can be specified? VMware VMs only support the OpenGL 3.3 Core Profile.

Digressing a bit but still sort of related, just for curiousity sake; so totally optional if you don't have time to do this. As I am still on Fusion 8.5.x, I can't have the Metal option (it is something new to Fusion 10.x). I wonder whether whether Metal or OpenGL will give the better graphic capabilities. In the vmware.log file, there should be a listing (0 to 243) of the graphics capabilities.

Something like this

vmx| I125:   cap[ 73]: 0x00000001 (SUPERSAMPLE)

At the Workstation Pro 12.5.x on Windows 10 host, I find that if the VM uses OpenGL on an Nvidia instead of DX11 (the default for VMs in Windows hosts) as the graphics render device, the capabilities presented to the VM seem to be better. An example is the SUPERSAMPLE, it shows 1 instead of 0. At the guest VM, even an application such as Chrome browser, chrome://gpu will show better graphics capabilities when OpenGL is used.

[hexadecagon]

Is there any way within the Argos code that OpenGL initialisation code that the Core Profile can be specified? VMware VMs only support the OpenGL 3.3 Core Profile.

Unfortunately not - the visualisation plugin is built upon deprecated functionality and uses a fixed pipeline approach for rendering, which was removed from OpenGL in version 3.1. I didn't realise that VMware VMs only supported the OpenGL 3.3 Core Profile - this might explain why things aren't working as expected.

To answer your question bluefirestorm, there is no difference in the logs between using integrated / discrete graphics, but there are some differences depending on whether Metal is enabled / disabled:

mks.enableMTLRenderer = "FALSE":

| vmx| I125:   cap[ 17]: 255.000000 (MAX_POINT_SIZE)

| vmx| I125:   cap[ 40]: 0x0000601f (SURFACEFMT_LUMINANCE8_ALPHA8)

| vmx| I125:   cap[ 70]: 0x00000003 (MULTISAMPLE_NONMASKABLESAMPLES)

| vmx| I125:   cap[ 71]: 0x0000008b (MULTISAMPLE_MASKABLESAMPLES)

| vmx| I125:   cap[ 72]: 0x00000001 (ALPHATOCOVERAGE)

| vmx| I125:   cap[ 73]: 0x00000001 (SUPERSAMPLE)

| vmx| I125:   cap[ 76]: 0x01044000 (SURFACEFMT_AYUV)

| vmx| I125:   cap[ 87]: 0x00000001 (LINE_AA)

| vmx| I125:   cap[ 88]: 0x00000001 (LINE_STIPPLE)

| vmx| I125:   cap[ 89]:  10.000000 (MAX_LINE_WIDTH)

| vmx| I125:   cap[ 90]:  10.000000 (MAX_AA_LINE_WIDTH)

| vmx| I125:   cap[ 98]: 0x0000000e (DX_MAX_CONSTANT_BUFFERS)

| vmx| I125:   cap[ 99]: 0x00000001 (DX_PROVOKING_VERTEX)

| vmx| I125:   cap[113]: 0x000000f7 (DXFMT_LUMINANCE8_ALPHA8)

| vmx| I125:   cap[144]: 0x00000001 (DXFMT_AYUV)

mks.enableMTLRenderer = "TRUE":

| vmx| I125:   cap[ 17]: 511.000000 (MAX_POINT_SIZE)

| vmx| I125:   cap[ 40]: 0x00006007 (SURFACEFMT_LUMINANCE8_ALPHA8)

| vmx| I125:   cap[ 70]: 0x00000000 (MULTISAMPLE_NONMASKABLESAMPLES)

| vmx| I125:   cap[ 71]: 0x00000000 (MULTISAMPLE_MASKABLESAMPLES)

| vmx| I125:   cap[ 72]: 0x00000000 (ALPHATOCOVERAGE)

| vmx| I125:   cap[ 73]: 0x00000000 (SUPERSAMPLE)

| vmx| I125:   cap[ 76]: 0x00000000 (SURFACEFMT_AYUV)

| vmx| I125:   cap[ 87]: 0x00000000 (LINE_AA)

| vmx| I125:   cap[ 88]: 0x00000000 (LINE_STIPPLE)

| vmx| I125:   cap[ 89]:   1.000000 (MAX_LINE_WIDTH)

| vmx| I125:   cap[ 90]:   0.000000 (MAX_AA_LINE_WIDTH)

| vmx| I125:   cap[ 98]: 0x0000000d (DX_MAX_CONSTANT_BUFFERS)

| vmx| I125:   cap[ 99]: 0x00000000 (DX_PROVOKING_VERTEX)

| vmx| I125:   cap[113]: 0x000000e3 (DXFMT_LUMINANCE8_ALPHA8)

| vmx| I125:   cap[144]: 0x00000000 (DXFMT_AYUV)