OpenGL version outdated

English Virtualization
21

You have to be clear about whether you are running a Win10 Guest on an openSUSE (or any Linux) HostOS, if so then you can discard practically that entire post I made, it applies only to an openSUSE Guest.

If you’re running a Win10 Guest on an openSUSE HostOS, then the OpenGL 3D version is irrelevant, or at least is not relevant anywhere I can find.
On the HostOS, you should just install the best and most capable GPU driver available (or try alternatives as Malcolm is suggesting), and make sure it’s configured to enable maximum hardware acceleration. But even then it’s still a scenario VMware does not describe, is certainly unsupported and only a “best try” and I don’t remember seeing recounted anywhere by anyone.

TSU

22

/sbin/lspci -nnk | egrep -A3 “VGA|3D|Display” shows:


01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Device [1002:6617] (rev c7)
        Subsystem: XFX Pine Group Inc. Device [1682:7240]
        Kernel driver in use: radeon
        Kernel modules: radeon, amdgpu

Taking Radeon out of the system causes so many dependency changes I don’t have the time for that tonight. I will try it tomorrow.

There are posts about Opengl saying most distributions install version 3.1 by default because there are proprietary concerns with the versions that follow. Given Suse’s inclination to favor open standards that would explain why OpenGL 3.1 is installed on my copy of Leap 15.1 . I assume there may be an environment setting to change the version but I don’t understand why the documentation to do that is so hard to locate.

23

Hi
No need to remove anything, you just switch… looks like that’s a Southern Island card, so all you need to do is install xf86-video-amdgpu to start with.

You then need to fire up YaST boot loader and add the following to the kernel command line options


amdgpu.cik=0 amdgpu.si=1

You could also try before any changes is to tell the radeon driver with the kernel options;


radeon.cik=0 radeon.si=1
24

@malcolmlewis:

I was about to ask you if, the openSUSE Leap 15.1 kernels are compiled with “CONFIG_DRM_AMDGPU_SI=Y” and “CONFIG_DRM_AMDGPU_CIK=Y”.

  • grep ‘CONFIG_DRM_AMDGPU’ /boot/config-4.12.14-lp151.28.* confirms that, they are indeed enabled.

[HR][/HR]Meaning that, I can try my OLAND SI card with the AMD GPU driver – at last – Yippeee!!!

25

I added the Kernel options amdgpu.cik=0 amdgpu.si=1 and rebooted.

/sbin/lspci -nnk | egrep -A3 “VGA|3D|Display” shows no change:


01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Device [1002:6617] (rev c7)
        Subsystem: XFX Pine Group Inc. Device [1682:7240]
        Kernel driver in use: radeon
        Kernel modules: radeon, amdgpu

The Compositor options in Display and Monitor setting didn’t change.

The OpenGL standard allows individual vendors to provide additional functionality through extensions. Sometimes other vendors adopt the original vendors extension and the naming standard within OpenGLGL changes to identify when more than one vendor adopts an extension. Those extensions can be rolled into the OpenGL specification leaving uneven adoption of a new standard among different vendors.

The last completely backwards compatible OpenGL version is 3.0. Some distros default to an earlier version to main compatibility with what was an open standard. Leaving the unknowing Suse user to guess if the version used by default is for open standards compatibility or if the kernel doesn’t support a higher version. Leaving trial and error as the usual SOP.

The Mesa override for OpenGL version is MESA_GL_VERSION_OVERRIDE.

MESA_GL_VERSION_OVERRIDE=3.3 glxinfo | grep version shows:


server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
    Max core profile version: 3.3
    Max compat profile version: 3.3
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL core profile version string: 3.3 (Core Profile) Mesa 18.3.2
OpenGL core profile shading language version string: 4.50
OpenGL version string: 3.3 (Compatibility Profile) Mesa 18.3.2
OpenGL shading language version string: 4.50
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.3.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

I would like to try running VMWare Player inside a session with MESA_GL_VERSION_OVERRIDE=3.3 but haven’t figured that one out yet.

26

Yes, fine, for the Redmond product but, what about the 3D graphics capabilities of “VMware Workstation Player” running on a Linux platform?

  • The VMWare web information for the Workstation Player states only “3D Graphics with DX10.1 and OpenGL 3.3 Support” …
  • Possibly, they forgot to add “at least OpenGL 3.3” …

[HR][/HR]What happens if you simply download the VMWare “Bundle” for Linux and run it?

  • Does install OK?
  • I’ll be checking what goes on in a parallel session here on this machine …
27

The “VMware Workstation Player” installs and runs OK – didn’t setup a VM but, I suspect that, because Windows 10 runs OK in an Oracle VirtualBox VM and, the 3D is pretty much OK there, the same will apply for a VMware VM …
[HR][/HR]BTW, uninstalling the “VMware Workstation Player” verges on sadism – AFAIKS it doesn’t uninstall cleanly …

28

VMWare Player installs and runs Windows 10 flawlessly on Leap 15.1 with 3D acceleration turned off. The only problem is VMWare requires OpenGL 3.3 to run 3D acceleration.

29

First,
Am not clear what would be the difficulty of running VMplayer in an openGL 3.0 session (although I’m not sure why you would even want to do so, wasn’t the requirement openGL 3D 3.3?)

Also,
ultimately I highly recommend you benchmark each configuration you set up,

  • To verify there is a provable benefit in each or any configuration
  • There is always the possibility that some unannounced and undocumented change may happen which would make everything you’ve done unnecessary or change requirements.

In other words, particularly for poorly documented (and I consider including documentation that hasn’t changed for over 5 years), I consider unreliable. Especially when you can produce real, empirical evidence with little effort, that’s the only sure way forward (instead of relying on version numbers and stale documentation).

BTW - because this Forum thread has become so virtualization specific without any likely way of wavering, I’m going to request it be moved to the Virtualization Forum.

TSU

30

It may well be that, the “VMware Workstation Player” possibly needs OpenGL 3.3 if the 3D Acceleration for Windows 10 clients is to be enabled.
[HR][/HR]Please note that, on this Leap 15.1 machine with OpenGL version 4.5, Windows 10 running in an Oracle VirtualBox VM has 3D Acceleration enabled:


 > VBoxManage showvminfo xxx
Guest OS:                    Windows 10 (64-bit)
 .
 .
PAE:                         enabled
Long Mode:                   enabled
Triple Fault Reset:          disabled
APIC:                        enabled
X2APIC:                      disabled
Nested VT-x/AMD-V:           disabled
 .
 .
3D Acceleration:             enabled
2D Video Acceleration:       enabled
 .
 .
 > 



 # lspci -nnk
 .
 .
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Oland PRO [Radeon R7 240/340] [1002:6613]
        Subsystem: ASUSTeK Computer Inc. Device [1043:04bb]
        Kernel driver in use: amdgpu
        Kernel modules: radeon, amdgpu
 .
 .
 #

[HR][/HR]I have absolutely no idea if, you absolutely have to use VMware for your Virtual Machines but, openSUSE Leap 15.1 running Oracle’s VirtualBox seems to be able to do what you want to achieve …

31

Hi
You might need to look at the third party provider (VMware) for answers as well…

32

Sorry, it seemed that nobody here detected earlier that this is about Virualization.
The thread is now moved there.

33

My own testing in VBox 5.x was that VBox hardware acceleration support was truly “experimental” as described in the VBox documentation and didn’t really perform on the occasions it even worked at all…
But, may be vastly improved with VBox 6.0 and 6.1,
I haven’t gotten around to running any tests… But would be important to see if it really works now.

For anyone who tries to run both VMware nd VBox products on the same machine, you <must> stop a number of VMware services (IIRC virtualization authentication, NAT, USB and something else… the workstation service should already be stopped and never or rarely started automatically) before you can run VBox.

TSU

34

I have never been able to articulate any significant difference between VMWare’s Player and VirtualBox and consider them reasonably interchangeable. For as infrequently as I use Windows the amount of work necessary to build a new virtual machine to replace a smoothly running one isn’t worth the effort. VMPlayer’s dependency on OpenGL 3.3 doesn’t seem unreasonable to me and I expect Leap 15.2 will adopt the newer standard when it arrives.

35

The question is how to obtain OpenGL 3.3 in Leap 15.1 when the default is OpenGL 3.1? This seemed such an easy question when I started and the extended discussion is unexpected.

After this extended discussion, how do I run a session for VMWare Player with the environmental setting of MESA_GL_VERSION_OVERRIDE=3.3? Normally I would do this from a command line by listing the environmental setting before the command for Player but VMWare Player doesn’t run from the command line.

36

You wouldn’t specify an OpenGL version setting when launching the VMware app because they really don’t have much to do with each other.

You would need to specify that OpenGL version as a system environment setting, so would be specified either as a boot time option or as a system environmental setting typically set in /etc/profile.local or a script in /etc/profile.d/
I’m not familiar with the described setting which seems to either set an embedded legacy profile or passes the required text string that identifies the 3D core profile, so I can’t say exactly what the recommended method should be, would require some research or finding the right documentation (perhaps someone can save others the trouble if they already know the source of this information?).

If possible, the described setting should be the preferred way to implement otherwise replacing the Mesa packages with those from openSUSE 13…2 as I described could be another try before custom compiling.

TSU

37

Moving on this thread towards a successful solution,

Here is what should be a summary of essentials from earlier posts in this thread and my current findings and recommendations (at the moment to resolve). I’m fairly confident the following should theoretically work, but will require Users to confirm.

Problem:
How to implement OpenGL 3D in a VMware Guest,
Apparently the Guest requires OpenGL 3D core profile 3.3, must be exact and nothing higher or lower.

Automatic Fallback:
If OpenGL 3D 3.3 cannot be configured, then the general recommendation is to <disable> hardware acceleration in the Guest which should likely then automatically enable OpenGL 3d 2.1(?) support. Leaving hardware acceleration enabled when not configured properly is the worst configuration with least performance.

Useful things to know:
Since OpenGL 3.1, “profiles” are supported so that it’s possible to configure a non default. Profiles are considered not the same as actually compiling that particular version, and there is no guarantee that a particular profile setting will satisfy application requirements, in which case the recommendation is to install and possibly build the specified version of Mesa that supports that version of OpenGL 3D.
There are two types of profiles, the “core profile” which can be considered the base set of instructions supported and “compatibility profile” which by default is supposed to support the given core profile instructions plus anything later than that.

General Setup configurations(required)
**HostOS **- No matter the OS or distro, configure the best performing DirectX (MSWindows) or Mesa (Linux) available. Older versions on the HostOS can work, but will result in less performance and fewer features available to the Guest (Any, no matter OS or distro). Proprietary drivers are generally recommended over FOSS drivers (primarily nVidia and Radeon). Using the driver’s configuration utility, ensure hardware acceleration is enabled and at maximum setting. Although not explicitly described anywhere I can find, the inference in everything I’ve read is that the specific glfx may not be important, but the best hardware acceleration (primarily drivers and driver configuration) is essential.

VMware Guests - Not necessarily applicable to other virtualization technologies although I imagine there is probably plenty opportunity for cross-over since I suspect that CPU hardware extensions support the GPU in some cases (particularly Intel GPUs).
MSWindows Guests should be configured with the latest DirectX available, and hardware acceleration enabled. I cannot find any VMware documentation that specifically describes a MSWindows Guest on a Linux HostOS, but if my inference/guess about the HostOS is correct, then there should not be any further configuration necessary when running on a Linux HostOS.
Linux Guests including openSUSE need to be configured with OpenGL 3D core profile 3.3 <only> and hardware acceleration enabled in the VM Settings.
I cannot find specific instructions for how to configure the Guest but I have found several articles which suggest the following methods will work.

The following describes how to configure any VMware settings which might work in the vmx file first, then how to set the Guest system environmental setting inside the Guest.
Again, all rely on having a recent version of Mesa installed (current seems to be 4.6), later than Mesa 3.1

VMware specific settings (not likely relevant outside of configuring a VMware Guest)
https://www.mesa3d.org/envvars.html

**VMware SVGA driver environment variables

**SVGA_FORCE_SWTNL

[INDENT=2]force use of software vertex transformation[/INDENT]
SVGA_NO_SWTNLdon’t allow software vertex transformation fallbacks (will often result in incorrect rendering).

SVGA_DEBUG

[INDENT=2]for dumping shaders, constant buffers, etc. See the code for details.[/INDENT]
SVGA_EXTRA_LOGGING

[INDENT=2]if set, enables extra logging to the vmware.log file, such as the OpenGL program’s name and command line arguments.[/INDENT]
SVGA_NO_LOGGING

[INDENT=2]if set, disables logging to the vmware.log file. This is useful when using Valgrind because it otherwise crashes when initializing the host log feature.[/INDENT]
See the driver code for other, lesser-used variables.

Following were added with VMware Workstation (and Player) 15.0

  • Multisample antialiasing (2x, 4x)
  • GL_ARB/AMD_draw_buffers_blend
  • GL_ARB_sample_shading
  • GL_ARB_texture_cube_map_array
  • GL_ARB_texture_gather
  • GL_ARB_texture_query_lod
  • GL_EXT/OES_draw_buffers_indexed

How to Configure
How to Configure VMware Specific settings
The above settings can be considered VMware specific settings.

I expect that it adding each and any of the above listed commands to a Guext vmx (The main Guest configuration file) should work.
I also suspect that the commands <may> work within the Guest as either a system environment variable or a User profile variable <may> work.

How to Configure general Mesa settings
The astute observer might already have noticed that none of the VMware specific settings listed above will configure a specific OpenGL 3D profile, this seems to be possible only as a general environment setting. I have found two types of postings that describe how to pass non-default environment settings, one by an application setting if provided (eg in a Steam game) and the other in a development environment by modifying the console environment (eg modifying bashrc) by usual means. Although I cannot find an explicit recommended method of configuration for ordinary Use (not a specific game or using a console to code), those can easily be used to infer that these environment variables can be set in the system profile using ordinary methods.

If you want to try the following command which sets the system OpenGL 3D core profile setting without rebooting, you’ll have to reload the system profile manually, then after a reboot my glxinfo reports all Mesa settings are now based on 3.3. I did not run any benchmarks, recommend people do so or otherwise verify any performance benefit.


cat >> /etc/profile.local << EOF
#Custom Mesa OpenGL core profile setting to support 3D acceleration
export MESA_GL_VERSION_OVERRIDE-3.3
export MESA_GLES_VERSION_OVERRIDE=3.3
export MESA_GLSL_VERSION_OVERRIDE=3.3
EOF

Full documentation listing all the various Mesa configuration options can be found in the following, is a complete listing for not just generic system but also specific hardware both physical and virtual.

https://www.mesa3d.org/envvars.html

Additional Misc references I used to create this solution
Describes modifying bashrc setting to support new environment setting
https://communities.vmware.com/thread/579259
Misc Mesa info if you want to do more research, one of many that also describes how to compile your own Mesa
http://mesa.sourceforge.net/prereqs.html
How to set environment variable in a Steam game
https://www.reddit.com/r/linux_gaming/comments/7w77kv/how_to_override_mesa_environment_variable/

38

I just noticed that the command that inserts the necessary export commands to profile.local was munged by the text editor (happens often, I wish the bug would be addressed).

The proper command should be the following

cat >> /etc/profile.local << EOF
# Custom Mesa OpenGL core profile setting to support 3D acceleration
export MESA_GL_VERSION_OVERRIDE-3.3
export MESA_GLES_VERSION_OVERRIDE=3.3
export MESA_GLSL_VERSION_OVERRIDE=3.3
EOF

Note the required carriage return (or space) after the first EOF.
Would be nice if an Administrator can simply edit post
https://forums.opensuse.org/showthread.php/538612-OpenGL-version-outdated?p=2924173#post2924173

TSU

39

In my installation there were two changes necessary to run 3D acceleration in Windows 10 in VMWare Player on Leap 15.1.

VMWare unexpectedly blocks some kernel video drivers. Those drivers have to be given permission to run. Granting permission is done by adding the line mks.gl.allowBlacklistedDrivers to the bottom of VMWare’s preference file at ~/.vmware/preferences.

Leap 15.1 comes with OpenGL 3.1 installed by default. VMWare requires an OpenGL core profile of at least 3.3 and VMWare doesn’t recognize the Compatibility profile. If glxinfo | grep version shows a default OpenGL core profile of 3.1 but higher available features there is a way to force Mesa to report a core profile of 3.3. This is done with the Environment setting of MESA_GL_VERSION_OVERRIDE=3.3. You can set this with export MESA_GL_VERSION_OVERRIDE=3.3 at the command line.

Thanks to everyone who took the time to respond to my question.[LEFT][/LEFT]

40

Hi,
Unless you found documentation I didn’t,
I couldn’t find anything that described OpenGL 3.3 core needed to be installed/configured in a Linux HostOS running a MSWindows Guest…
It would be useful for you to verify if OpenGL 3.3 core is required as you describe or if as I suspect you only need to install best performing video drivers available, configure for maximum hardware acceleration and <maybe> simply installing the latest Mesa release without any other special configuration.

I would recommend and ask you to run either or both of the following 3D Benchmarks in your MSWindows Guest (both are free)

GFXBench DX Benchmark from the Microsoft Store
3DMark (requires Steam) 3DMark benchmark for Windows, Android and iOS

The following benchmarks might be useful, they seem to focus more on OpenGL 3D support in the running MSWindows, not just DirectX
OpenGL Extension Viewer Download OpenGL Extension Viewer
GLview http://realtech-vr.com/admin/glview

Run each or any benchmark at least 3 (maybe 5?) times, throw out the first and last and average the others
Run first on a default openSUSE LEAP 15.1
then
Run with all 3 OpenGL 3D settings(described in my post) set to to the “opengl 3D core profile=3.3”… preferably set on boot as I described although <maybe> setting in a console might work (I didn’t test and don’t know if it would even work properly). You didn’t describe exactly how you set the OpenGL core profile if not on boot, so I don’t know if it did more than simply change the glfx readout or truly set the environment variable and the scope of your action (The method I described sets system-wide and is effective).

Or, if you’re running some application that is refusing to run because 3D hardware acceleration is not detected, then it would be useful to know what that application is, and perhaps a snippet of the log that throws the notification.

Regarding your blacklisted video drivers setting…
I wonder about that, and could be related to your specifying a special openGL configuration in your HostOS.
The Internet search I did only returned results related to Mesa when doing a GPU pass-through, and ESXi which is known to be extraordinarily picky about hardware in general. I couldn’t find anything that should show up in other VMware apps like the Player you say you are running.
In any case, this may again be relevant to whether configuring OpenGL core profile 3.3 is necessary in the HostOS at all… If not necessary then the problem you ran into loses relevancy (becomes an unnecessary setting).
BTW - IMO the lack of hits again possibly provides further weak support that others haven’t had to apply a special OpenGL configuration in the HostOS.

Thx if you can do this… Could be highly informative for others who follow if no one has tested this and published before…
TSU