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

[Thomas Hellstrom]

On 11/11/2015 08:51 PM, Brian Paul 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.
>
Actually they are unlikely to happen since this scenario was taken into
account when the standalone vmwgfx module was designed, and unless we
have a bug it should be safe (I've seen two duplicate TTM symbols
exported in 3.19, but that's cosmetic only until another TTM aware
driver is loaded, which is currently not likely).

When built, only internal drm / ttm  headers are used, no internal drm
or ttm symbols are exported (except as stated above) and all drm and ttm
references are internally resolved except two, namely those that allow
binding to core drm's sysfs, so that the driver's sysfs interface shows
up where it should; among other things for Mir compatibility.

It's true that if these two single DRM functions change their interface,
we need to handle that, but that's a small interface to watch over; The
driver is simply designed to interoperate with core drm and TTM.

/Thomas