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

[Emil Velikov]

On 11 November 2015 at 19:51, Brian Paul <brianp at vmware.com> wrote:
> On 11/11/2015 11:38 AM, Emil Velikov wrote:
>>
>> 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.
>
>
> Well, the above-mentioned build script doesn't touch drm.ko and works on
> about 14 different versions of Ubuntu, Mint, Fedora, RHEL, etc. so I don't
> think we've ever seen that conflict.  But if someone's doing their own
> kernel/graphics builds/installs, who knows.  If it comes up, we'll just have
> to address it.
>
Ouch... I see what's happening here. You're not using any of the
kernel core drm/ttm/foo - you're just static linking the local ones
into vmwgfx.ko. This will explain why the lack of issues.

Well played guys !

Cheers,
Emil