February 10, 2017
Unlike some online news might’ve let you believe, Mesa 13.0.x is not going to be in 16.04 LTS. And it has only been days since it received the “dated” 12.0.6 release as a SRU together with 16.10.
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.
January 26, 2017
Previous LTS point-releases came with a renamed Mesa backported from the latest release (as in mesa-lts-wily for instance) . Among other issues this prevented providing newer Mesa backports for point-release users without getting a mess of different versions.
That’s why from 16.04.2 onwards Mesa will be backported unrenamed, and this time it is the last version of the 12.0.x series which was also used in 16.10. It’s available now in xenial-proposed, and of course in yakkety-proposed too (16.10 released with 12.0.3). Get it while hot!
December 3, 2016
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.
July 23, 2016
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.
March 12, 2016
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!
March 11, 2016
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 🙂
October 31, 2012
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.
November 26, 2008
The University I work for has offered a UNIX (secure-) shell service for its students and staff for over 15 years now. The servers have so far been AIX (Power/PPC), OSF1/Digital Unix/Tru64 UNIX (alpha) and Solaris (sparc64).They’ve also been mostly top-of-the-line (=expensive) boxes so they can handle hundreds of simultaneous users without problems. The exotic hardware and OS also makes it more secure, since script-kiddies tend to use more common hardware and OS’s.
Now we are in the process of phasing out the last remaining publicly available Tru64 server (ES40/4x667MHz, 5GB RAM), and possibly with a x86-64 server running Linux (Ubuntu 8.04). The reason why Linux has not been an option before is that some people claim it still can’t handle the load of ~1000 users reading their email (pine/alpine/mutt) while chatting with irssi or whatnot. Also the security problems have been brought up. It’s possibly a lot easier to break into Linux than Solaris, because Linux is more common and easy to get (although there is Opensolaris now..).
What I’d like to know is that are there people already running Linux on similar purpose, and how does it perform? What measures can be taken against the security threats (preferably something that doesn’t involve building a custom kernel)? What else should be taken into account to make it scale better?
The x86 hardware is at least a lot cheaper. Eight-core blade with 64GB of RAM is less than 8kEUR.. but could it handle 700 users like the ES40 does with ease?
November 13, 2008
- Grab the nearest book.
- Open it to page 56.
- Find the fifth sentence.
- Post the text of the sentence in your journal along with these instructions.
- Don’t dig for your favorite book, the cool book, or the intellectual one: pick the CLOSEST.
There were two books within reach, so I picked the one that wasn’t in Finnish: “Kerberos: The Definite Guide” by Jason Garman (O’Reilly)
Make sure that the hostname you place in the krb5.conf file actually resolves to the local machine.
July 3, 2008
For the past few days I’ve been working on merging the latest upstream release of xorg-server (1.5rc5) for Intrepid, which happens to require the recently released libdrm 2.3.1 and mesa 7.1rc. Had to merge xorg as well and rebuild the drivers that I need (kbd, mouse, intel), since the video and input ABI’s have changed. The intel DRI driver has a couple of bugs that prevent compiz from working, but hopefully they are fixed in the not-too-distant-future…
Today I’ve been trying to get mesa to use the new autotoolized build system, and it’s starting to look good. For reasons unknown to me, it still isn’t capable of building static and shared libs at the same time etc., so it actually copies the source and runs configure & make ten (10) times to build the various targets.. The sun is already rising, so hopefully the ongoing build finally looks normal so I can push this to git.debian.org and go to bed 😀