Support us on Patreon
PayPal
With Mesa coming along rather nicely in the latest releases, Feral Interactive are requesting that Canonical push out Mesa updates to their official graphics driver PPA to help Feral officially support Mesa in their Linux ports.
Part of the problem is that Mesa on Ubuntu is often outdated, meaning if Feral (and other game developers) want to give support for it, there needs to be an easy and tested way to get the latest open source GPU drivers.
Adding tested packages to the official PPA would be an ideal solution for now:
You can see the full mailing list entry here.
Hopefully this will get sorted, so users on AMD and Intel can get the best gaming experience possible on Ubuntu.
Not everyone is comfortable compiling things, and I agree that users shouldn't be required to go and compile graphics drivers to get stable versions of Mesa. While there are other PPA's around, they usually provide packages from git which can come with all sorts of breakage. This could benefit a lot of people.
Additional note: The less PPA's people have to add, the more secure they may be. It was an issue raised in our IRC that people flock to all sorts of random PPA's (guilty!), so having a trusted one for this would be awesome. Article taken from GamingOnLinux.com.
Edwin, FeralWe have been working with the Mesa community to help improve the Mesa drivers so more games can run on AMD and Intel hardware, and in the last year this has started to hit the tipping point and support has become more and more viable when using the very latest drivers.
Part of the problem is that Mesa on Ubuntu is often outdated, meaning if Feral (and other game developers) want to give support for it, there needs to be an easy and tested way to get the latest open source GPU drivers.
Edwin, FeralThe biggest issue we have is there is no way for a user to officially download and install the latest stable versions of Mesa. For example because the official Mesa 13.0.1 release isn’t available to install on Ubuntu, you need to compile it yourself.
Adding tested packages to the official PPA would be an ideal solution for now:
Edwin, FeralI’d like to suggest that official Mesa releases are also added to the graphics-drivers PPA using the release information on the mesa.org website: http://www.mesa3d.org/relnotes.html
You can see the full mailing list entry here.
Hopefully this will get sorted, so users on AMD and Intel can get the best gaming experience possible on Ubuntu.
Not everyone is comfortable compiling things, and I agree that users shouldn't be required to go and compile graphics drivers to get stable versions of Mesa. While there are other PPA's around, they usually provide packages from git which can come with all sorts of breakage. This could benefit a lot of people.
Additional note: The less PPA's people have to add, the more secure they may be. It was an issue raised in our IRC that people flock to all sorts of random PPA's (guilty!), so having a trusted one for this would be awesome. Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Quoting: EhvisIt appears Feral also upgraded their radar. All the glitches are gone! Kind of boring really.There is something wrong with the radar, because Total War: Warhammer disappeared. I expect the radar to be updated once again on 22th. I hope there will be huge surprise and a lot of new "UFOs" :).
0 Likes
Nice great step forward. Not an AMD user, but hey- that would be just great. Just for the reason that Mesa has been moving [very] fast (maybe due to all the game developers) recently.
Last edited by STiAT on 21 November 2016 at 3:21 am UTC
Last edited by STiAT on 21 November 2016 at 3:21 am UTC
0 Likes
Quoting: manero666What to expect from the Ubuntu repos?
They still have Wine1.4 and 1.6 as the official options...
Maybe they are to busy rewriting and forking all of Linux to bother keeping the rest of the system up to date. First Unity, then MIR. Maybe now they are forking the Linux Kernel and rewriting/redesigning it from scratch too.
0 Likes
Quoting: JohnersI do agree with this but the PPAs should also have the option to be enabled from the Additional Drivers program to make it even easier for the end user to enable these updates on their system.
Canonical should also provide the same option for AMDGPU-PRO and the nVidia drivers. I know there is already a PPA for nVidia but my biggest complaint about that is how it splits off each driver branch into its own set of packages which makes updates annoying at times because you have to switch from one branch to another.
There is absolutely no reason for Ubuntu to do anything with PPAs other than their kernel mainline builds for testing purposes. Yes, the Mesa project should be tracked and updated putting the most stabilized Mesa branch with the most features into play. By default Ubuntu 16.04 uses kernel 4.4 series and supports OpenGL 4.1 core profile on everything but Intel, Intel has OpenGL 4.2 core profile capability. With the current, LLVM 3.9 or beta LLVM 4.0 libraries, Mesa 13.1 is compiled against that and if you have the release candidate series of Linux kernel 4.9 you can enjoy much of the OpenGL 4.5 core profile specification on Nvidia, AMD and Intel.
Why I don't support the idea of PPAs, those are not policed by Canonical and as the name hints at; Personal Package Archive. This presents a quality issue as other people with tend to fork off of code that isn't being directly maintained nor gone over by Canonical, only certain people that either work for the company or are affiliated with them in some way.
If you want the most up to date drivers for Mesa 3-D OpenGL, OpenGL ES, Vulkan and a host of others, look here.
https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa
Note: He only currently supports versions 16.04 and 16.10.
To answer your questions in regards to AMDGPU-PRO, yes, PRO means, proprietary, because there is an open source version of it just known as AMDGPU and in Ubuntu it shows up as AMDGPU1 in the repositories.
Yes, the AMDGPU-PRO does replace the AMD CRIMSON (Which replaced AMD Catalyst). As far as the other older video cards that aren't supported at this time, AMD wants to make sure the newer cards work correctly before working on the older GP-GPU based cards. They want to make sure the core of the library is working right before they go bat sh*t crazy.
Note:
Like the AMDGPU-PRO the open source variant also has restrictions, the 4.9 kernel series has a pretty significant bug that is being worked on as I type this message in. It has to do with kernel tiling and how the older cards interact with it. The way the new cards interface with it is quite a bit different than the older cards do. They're trying to strike a happy medium in the kernel to provide support for both types at the kernel level, so AMD and other manufacturers don't have to work on a "custom" solution to the problem.
You can read a little about it on the Khronos web site, granted it's talking about OpenVX but many of the advanced features of the older cards are related to that default disabled option in the 4.9 kernel.
https://www.khronos.org/registry/vx/extensions/vx_khr_tiling/1.0/html/
Hopefully soon they will figure this out, I'm looking forward to seeing a speed boost and capability on my older cards I use for low ball testing (minimum target) of my applications I write.
You could download and install the kernel development files for the 4.9 kernel when it gets out of the release candidate and becomes a stable release. Then it would be safe to test the kernel tiling option. After you enable it you'd follow the same rules about compiling the Linux kernel.
The one difference is that when you install it, you need to update grub2 by yourself. You'll need to execute;
sudo update-grub2 after you install, unlike the Ubuntu .deb installer files that do all that fancy foot work for you, you have to do it now.
(And no, I don't feel like creating a PPA with this feature enabled when 4.9 hit prime time). I'll leave that to some other unfortunate bugger (glutton for punishment).
0 Likes
Quoting: m2mg2Quoting: manero666What to expect from the Ubuntu repos?
They still have Wine1.4 and 1.6 as the official options...
Maybe they are to busy rewriting and forking all of Linux to bother keeping the rest of the system up to date. First Unity, then MIR. Maybe now they are forking the Linux Kernel and rewriting/redesigning it from scratch too.
Wine version have nothing to do with the forking of the Linux kernel, first off. Wine on Ubuntu is just repackaged from the source code tree from the master, nothing has changed.
The Linux vanilla kernel is added to by Canonical, Ltd., they add in more drivers and support libraries that are found in the various Ubuntu 16.04 desktop releases.
There is the kernel team, the desktop teams (each desktop has different team members). The repositories all have different team members. Security advisory committee deals with the security updates for the applications and libraries found in the repository (not the kernel, that's handled by the kernel team). For every repository type; main, security, partner, security, etc., they all have different teams assigned to it. One of the reasons why they don't just jump up versions is because it affects the entire system which may or may not make it unusable.
Ubuntu Linux is not a true modular distribution. Meaning there are "hard" dependencies that can't be taken out and replaced, otherwise the desktop itself or something that is compiled against the hard dependency list will fail.
To me, that in and of itself is a cause for security concerns. It should be modular so that it will be easy to change out should there be a threat because something isn't coded correctly could be remedied easily.
However, much of this problem comes from Debian Linux itself, Ubuntu just adds to it.
Now, I'll get back to Wine, as it stands, Wine hasn't changed that much in terms of compatibility of the Windows applications and .DLL it emulates. There is far too much of the "TODO:" warning messages. What needs to be done is to work on the most common libraries that all of the modern applications use. Get those working, then work on the next set that is used on occasion. Keep going until the rare or special use files are written and work well.
The thing that causes the vast majority of problems in Wine isn't the DirectX conversion, it's the .NET series of library files aren't complete. That is what screws things up the most, you need the full library to install and update your system correctly in Microsoft Windows for games and many applications. So true for Wine, it needs those to be completed first, then the DirectX 9.0c files.
Even the fork using Mono (instead of trying to emulate .NET) still has problems. Mono isn't exactly optimized, it's a hodgepodge of code. Needs to be profiled and cleaned up to be more of use.
0 Likes
Why doesn't Canonical provide updates for Mesa in first place?
0 Likes
See more from me