Language Selection

English French German Italian Portuguese Spanish

Ubuntu 18.04 LTS Users Can Now Install Mesa 18.1.1 to Improve Their Linux Gaming

Filed under
Ubuntu

Implementing OpenGL 3.1 with ARB_compatibility on RadeonSI, r600, NV50, NVC0, Softpipe, LLVMpipe, and SVGA graphics drivers, the Mesa 18.1 graphics stack series debuted on May 18, 2018, with support for new OpenGL extensions, including GL_EXT_semaphore, GL_EXT_semaphore_fd, GL_ARB_bindless_texture, and GL_ARB_transform_feedback_overflow_query.

Additionally, it adds support for the GL_EXT_shader_framebuffer_fetch and GL_EXT_shader_framebuffer_fetch_non_coherent extension for the Intel i965 OpenGL graphics driver, support for the GL_KHR_blend_equation_advanced extension for the RadeonSI graphics driver, and enables disk shader cache support for the Intel i965 OpenGL graphics driver by default.

Read more

More on This

  • Mesa 18.0.5 Being Prepped For Ubuntu 18.04 While 18.1.1 Going Into X-Updates

    When Ubuntu 18.04 LTS shipped in April, it shipped with a near-final release candidate of Mesa 18.0. Coming down the pipe now to "Bionic Beaver" desktop users is Mesa 18.0.5.

    Canonical's Timo Aaltonen who wrangles the X/Mesa packages has been working on getting the Mesa 18.0.5 point release out into the 18.04 Bionic archive and also an updated GLVND package to ease the transition for users that may be upgrading from Ubuntu 16.04. Those updates are in the process of landing.

  • Status of Ubuntu Mesa backports

    It’s been quite a while since the last post about Mesa backports, so here’s a quick update on where we are now.

    Ubuntu 18.04 was released with Mesa 18.0.0 which was built against libglvnd. This complicates things a bit when it comes to backporting Mesa to 16.04, because the packaging has changed a bit due to libglvnd and would break LTS->LTS upgrades without certain package updates.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

The Last Independent Mobile OS

The year was 2010 and the future of mobile computing was looking bright. The iPhone was barely three years old, Google’s Android had yet to swallow the smartphone market whole, and half a dozen alternative mobile operating systems—many of which were devoutly open source—were preparing for launch. Eight years on, you probably haven’t even heard of most of these alternative mobile operating systems, much less use them. Today, Android and iOS dominate the global smartphone market and account for 99.9 percent of mobile operating systems. Even Microsoft and Blackberry, longtime players in the mobile space with massive revenue streams, have all but left the space. Then there’s Jolla, the small Finnish tech company behind Sailfish OS, which it bills as the “last independent alternative mobile operating system.” Jolla has had to walk itself back from the edge of destruction several times over the course of its seven year existence, and each time it has emerged battered, but more determined than ever to carve out a spot in the world for a truly independent, open source mobile operating system. After years of failed product launches, lackluster user growth, and supply chain fiascoes, it’s only been in the last few months that things finally seem to be turning to Jolla’s favor. Over the past two years the company has rode the wave of anti-Google sentiment outside the US and inked deals with large foreign companies that want to turn Sailfish into a household name. Despite the recent success, Jolla is far from being a major player in the mobile market. And yet it also still exists, which is more than can be said of every other would-be alternative mobile OS company. Read more

How I Quit Apple, Microsoft, Google, Facebook, and Amazon

It was just before closing time at a Verizon store in Bushwick, New York last May when I burst through the door, sweaty and exasperated. I had just sprinted—okay I walked, but briskly—from another Verizon outlet a few blocks away in the hopes I’d make it before they closed shop for the night. I was looking for a SIM card that would fit a refurbished 2012 Samsung Galaxy S3 that I had recently purchased on eBay, but the previous three Verizon stores I visited didn’t have any chips that would fit such an old model. When I explained my predicament to the salesperson, he laughed in my face. “You want to switch from you current phone to an... S3?” he asked incredulously. I explained my situation. I was about to embark on a month without intentionally using any services or products produced by the so-called “Big Five” tech companies: Amazon, Apple, Facebook, Google, and Microsoft. At that point I had found adequate, open source replacements for most of the services offered by these companies, but ditching the Android OS, which is developed by Google, was proving difficult. Most of the tech I use on a day-to-day basis is pretty utilitarian. At the time I was using a cheap ASUS laptop at work and a homebrew PC at my apartment. My phone was a Verizon-specific version of the Samsung Galaxy J3, a 2016 model that cost a little over $100 new. They weren't fancy, but they’ve reliably met most of my needs for years. For the past week and a half I had spent most of my evenings trying to port an independent mobile OS called Sailfish onto my phone without any luck. As it turned out, Verizon had locked the bootloader on my phone model, which is so obscure that no one in the vibrant Android hacking community had dedicated much time to figuring out a workaround. If I wanted to use Sailfish, I was going to have to get a different phone. Read more

RISC-V Will Stop Hackers Dead From Getting Into Your Computer

The greatest hardware hacks of all time were simply the result of finding software keys in memory. The AACS encryption debacle — the 09 F9 key that allowed us to decrypt HD DVDs — was the result of encryption keys just sitting in main memory, where it could be read by any other program. DeCSS, the hack that gave us all access to DVDs was again the result of encryption keys sitting out in the open. Because encryption doesn’t work if your keys are just sitting out in the open, system designers have come up with ingenious solutions to prevent evil hackers form accessing these keys. One of the best solutions is the hardware enclave, a tiny bit of silicon that protects keys and other bits of information. Apple has an entire line of chips, Intel has hardware extensions, and all of these are black box solutions. They do work, but we have no idea if there are any vulnerabilities. If you can’t study it, it’s just an article of faith that these hardware enclaves will keep working. Now, there might be another option. RISC-V researchers are busy creating an Open Source hardware enclave. This is an Open Source project to build secure hardware enclaves to store cryptographic keys and other secret information, and they’re doing it in a way that can be accessed and studied. Trust but verify, yes, and that’s why this is the most innovative hardware development in the last decade. Read more

ONAP Myths Debunked

The Linux Foundation’s Open Network Automation Platform (ONAP) is well into its third 6-month release (Casablanca came out in Dec ’18), and while the project has evolved since it’s first release, there is still some confusion about what it is and how it’s architected. This blogs takes a closer look at ONAP, under-the-hood, to clarify how it works. To start, it is important to consider what functionality ONAP includes. I call ONAP a MANO++, where ONAP includes the NFVO and VNFM layers as described by ETSI, but goes beyond by including service assurance/automation and a unified design tool. ONAP does not include the NFVI/VIM or the NFV cloud layer. In other words, ONAP doesn’t really care whether the NFV cloud is OpenStack, Kubernetes or Microsoft Azure. Nor does ONAP include VNFs. VNFs come from third-party companies or open source projects but have VNF guidelines and onboarding SDKs that ease the deployment. In other words, ONAP is a modular platform for complete Network Automation. Read more