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

Brian Paul brianp at vmware.com
Wed Nov 11 11:51:04 PST 2015


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.


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

I haven't done so.


>
> 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.
>

-Brian



More information about the mesa-dev mailing list