Great! Glad to hear it. I'll check in the updated documentation today.
-Brian
On 11/13/2015 03:03 AM, Valera Rozuvan wrote:
Hi Brian,
The updated instructions worked for me. Thank you = )
Regards,
Valera Rozuvan |
https://urldefense.proofpoint.com/v2/url?u=http-3A__valera.rozuvan.net_&d=BQIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=T0t4QG7chq2ZwJo6wilkFznRSFy-8uDKartPGbomVj8&m=23mynH2CtHPfImZY-vSqq61hI3-5ZjhRGipoz9K8OJc&s=gg_NyTw0i8suRhBXUgjcqfHlEiHVvyOHUoboATZm7LU&e=
Skype: valera.rozuvan
E-mail: valera.rozu...@gmail.com
Phone: +38 (050) 837-29-73
On Wed, Nov 11, 2015 at 11:18 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
On 11 November 2015 at 19:51, Brian Paul <bri...@vmware.com> wrote:
On 11/11/2015 11:38 AM, Emil Velikov wrote:
On 11 November 2015 at 18:25, Thomas Hellstrom <thellst...@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 <bri...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
