On 11 November 2015 at 19:51, Brian Paul <[email protected]> wrote: > On 11/11/2015 11:38 AM, Emil Velikov wrote: >> >> On 11 November 2015 at 18:25, Thomas Hellstrom <[email protected]> >> 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 <[email protected]> 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 _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
