[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