Hi, Mesa 17.0.2 backports can now be installed from the updates ppa. Have fun testing, and feel free to file any bugs you find using ‘apport-bug mesa’.
Archive for the ‘ubuntu’ Category
Hi, I’ve prepared X server 1.19.2 along with the driver rebuilds for zesty on the staging ppa here:
It also comes with mesa 17.0.1 while it’s still stuck in zesty-proposed… Anyway, give it a shot and report success/failure stories on the FFe bug. The plan is to migrate this to zesty next week.
That said, 13.0.4 is now available on ppa:ubuntu-x-swat/updates for both 16.04 and 16.10. The PPA carries latest LLVM 3.9.1 package as well which fixes some bugs for Radeon users. There were some games released recently that benefit from these, which is one more reason why these backports were (finally) made available.
Update: Ubuntu 17.04 will ship with Mesa 17, so that’s the version which will be backported to 16.04 next.
I’ve uploaded Mesa 12.0.4 for xenial and yakkety to my testing PPA for you to try out. 16.04 shipped with 11.2.0 so it’s a slightly bigger update there, while yakkety is already on 12.0.3 but the new version should give radeon users a 15% performance boost in certain games with complex shaders.
Please give it a spin and report to the (yakkety) SRU bug if it works or not, and mention the GPU you tested with. At least Intel Skylake seems to still work fine here.
The ppa now has 12.0.5 for both xenial & yakkety. There have been no comments to the SRU bug about success/failure, so feel free to add a comment here instead.
Earlier this week Debian unstable and Ubuntu Yakkety switched to load the ‘modesetting’ X video driver by default on Intel graphics gen4 and newer. This roughly maps to GPU’s made since 2007 (965GM->). The main reason for this was to get rid of chasing after upstream git, because there hasn’t been a stable release in nearly three years and even the latest devel snapshot is over a year and a half old. It also means sharing the glamor 2D acceleration backend with radeon/amdgpu, which is a nice change knowing that the intel SNA backend was constantly slightly broken for some GPU generation(s).
Xserver 1.18.4 was released this week with a number of backported fixes to glamor and modesetting driver from master, so the time was right to make the switch now while both Stretch and Yakkety are still on the development phase. So I wrote a small patch for the xserver to load intel driver only on gen2 & gen3 which can’t do glamor efficiently. Newer Intel GPU’s will fall back to modesetting. This approach is good since it can be easily overridden by dropping a conffile to /etc/X11 that uses something else.
I’ve seen only one bug filed that was caused by this change so far, and it turned out to be a kernel bug fixed in 4.6 (Yak will ship with 4.8). If you see something strange like corrupt widgets or whatnot after upgrading to current Yakkety, verify it doesn’t happen with intel (‘cp /usr/share/doc/xserver-xorg-video-intel/xorg.conf /etc/X11’ followed by login manager restart or reboot) and file a bug against xserver-xorg-core (verify xdiagnose is installed, then run ‘ubuntu-bug xserver-xorg-core)’. We’ll take it from there.
Xserver 1.18.2 was released yesterday, and it’s now available for xenial on the staging PPA. It has a fair number of fixes for glamor, DRI2/DRI3/Present and others. Plan is to move it to the main repository next week. The PPA also has a minor update to xserver-xorg-video-intel, and the latest release candidate for Mesa 11.2.0 which has a feature-freeze exception bug filed. Feel free to add comments about success/failure there, and for xserver/intel file a bug against the source package (xorg-server, x-x-v-intel). Happy testing!
In case someone hasn’t noticed yet, fglrx has been removed from Xenial. There are a couple of reasons for this. First of all, the driver did not support XServer 1.18 which we wanted to get in for 16.04. But more importantly, AMD asked us earlier this year to migrate to the open driver stack since fglrx would not be supported in 16.04. With this move we will have the shared core of AMD’s new driver stack in place and ready for adding the proprietary pieces of their hybrid stack, once they have been released later this year.
What does this mean in practice?
- machines currently running fglrx will be automatically migrated to the open source driver stack (kernel, mesa, X) after an upgrade to 16.04 – fglrx package will be removed and xorg configuration moved aside so that the OSS driver can run
- users relying on pro/workstation class features (latest OpenGL, OpenCL, ..) probably should stay on a supported release until the hybrid stack is available
We’re trying to make the transition as painless as possible. Alberto Milone has already backported basically every amdgpu kernel driver commit from 4.5 to the xenial kernel. So even the latest AMD GPU’s should be working fine with modesetting, power management etc. We’re also tracking changes to the Xserver to make sure any fixes applied to master also get in the 1.18.x branch for next point release, especially changes to the glamor acceleration library which newer radeons use for speeding up 2D graphics on Xorg. And there’s also a feature-freeze exception filed for Mesa 11.2… So I’d say we’re as well prepared as we humanly can!
One thing that needs some more thought is what happens when users on 14.04.[2,3,4] get migrated to 14.04.5 with supported HWE stack from 16.04. We’ll discuss this with AMD and hopefully come up with something so that in August when 14.04.5 is released things work as good as or even better than before 🙂
Long time no blog.. sheesh, didn’t realize it has been nearly four years since the previous post.
Anyway, I’ve pushed updated SSSD packages to ppa:sssd/updates. This includes 1.8.5 LTM (“Long Term Maintenance”) bugfix release for precise, which I inted to SRU sometime soon. I’ve also pushed 1.9.2 for quantal, which is basically the version that got in raring on Monday. Feel free to test and report bugs on launchpad, as usual.
Whee, this is my first blog post ever.. Created the account a couple of weeks ago after UDS, but didn’t have the guts to sit down and write anything before this wet, cold Sunday.
Hardy alpha1 is coming next week, and the Ubuntu X-SWAT team has been busy updating all the packages and syncing with Debian where possible. Before alpha1 releases we’ll have the new xcb-1.1 which has a sloppy-lock mode “fixing” assertion crashes with buggy apps like java. Also a newer radeonhd has just hit debian-unstable, so we’ll sync that as well.
After the first alpha we will be focusing on the HardyHardwareDetection spec. Perhaps the first step will be to enable input-hotplug after there is code to generate a hal fdi-file for the keyboard layout in use. There are definately some rough corners with input-hotplug, but my tests have so far been positive. Looking forward to the time when in 99.9% of the use cases xorg.conf is not needed at all 🙂