[Mesa-dev] Can't get OpenGL 3.x inside VMware Workstation 12 (Ubuntu guest)

[Emil Velikov]

On 11 November 2015 at 18:25, Thomas Hellstrom <thellstrom at vmware.com> wrote:
> On 11/11/2015 07:07 PM, Brian Paul wrote:
>> On 11/11/2015 10:44 AM, Emil Velikov wrote:
>>> On 11 November 2015 at 16:48, Brian Paul <brianp at vmware.com> wrote:
>>>> On 11/11/2015 08:44 AM, Emil Velikov wrote:
>>>
>>>>>
>>>>> I have seen similar type of documents in the past, most of which going
>>>>> out of date very quickly due to distribution changes and/or others.
>>>>> Wondering how you'll feel about "check your distro and add svga to the
>>>>> gallium-drivers array" style of instructions ?
>>>>
>>>>
>>>> I'm afraid I don't quite understand what you're saying there.  Can you
>>>> elaborate?
>>>>
>>>>
>>> Rather than walking through the requirements, configure and make/make
>>> install steps, just forward people to the distro specific wiki on "how
>>> to build mesa/kernel" and explicitly mention the differences:
>>> mesa:
>>> - XA must be enabled: --enable-xa
>>> - svga must be listed in the gallium drivers:
>>> --with-gallium-drivers=svga...
>>>
>>> kernel:
>>>   - Set DRM_VMWGFX
>>>
>>> others...
>>
>> I guess I've never seen those wikis.  I'd have to search for them, but
>> I really don't have the time now.
>>
>> We actually have an in-house shell script that installs all the
>> pre-req packages, pulls the git trees, builds and installs for a
>> variety of guest OSes.  But it has some VMware-specific stuff that I'd
>> have to trim out before making public.
>>
>>
>>>
>>> Related: does the upstream [1] vmwgfx module work well when combined
>>> with upstream core drm across different versions ? Considering how
>>> well Thomas is handling upstreaming shouldn't the module from the
>>> kernel be recommended ?
>>
>> Either should be fine at this point but the build instructions cover
>> the case of one having an older distro that may not have the
>> GL3-enabled kernel module already.
>>
>
> The upstream[1] vmwgfx module should work well with any linux kernel
> dating back to 2.6.32 unless the distro has changed the kernel API from
> the base version. It ships with builtin stripped drm and ttm to handle
> compatibility issues, and is intended for people (mostly including
> ourselves and our QA team) that want to try out new features without
> installing a completely new kernel.
>
Ok seems that my point is too subtle, so I'll try from another angle.

The wiki instructions say "nuke he vmwgfx.ko module" and implicitly
"keep drm.ko". If we ignore the unlikely cases where either one and/or
both is built-in, we can have a case where the new vmwgfx is build
against core drm from the upstream, yet the downstream drm module
is/gets loaded. As core drm often goes through various changes, you
can see how bad things are likely to happen.

TL;DR: If using vmwgfx.ko from upstream one should also pick drm.ko ?

Cheers,
Emil

Note: I've not experienced this, although I had the pleasure of
dealing with similar issues. Props to your colleague who updated the
start up scripts to honour the existing vmmon & co modules.