Language Selection

English French German Italian Portuguese Spanish

Graphics: Mesa, Wayland/Weston, Radeon

Filed under
  • "Soft" FP64/INT64 Implementations Merged To Mesa, Intel Driver Already Making Use

    For those with older graphics processors, rejoice as with the upcoming Mesa 19.0 driver release it might now be possible to have OpenGL 4.0 thanks to software-based implementations of ARB_gpu_shader_int64 and ARB_gpu_shader_fp64 finally being merged to mainline. The FP64 one is most notable with that being a requirement for OpenGL 4.0 but some older GPUs lacking that capability for bumping past OpenGL 3.3.

    Going back to the summer of 2016 was a Google Summer of Code project by Elie Tournier to implement "soft" FP64 support using GLSL to help out older GPUs that otherwise couldn't expose OpenGL 4.0 due to not supporting ARB_gpu_shader_fp64. Elie Tournier has since gone on to work for Collabora but getting this code merged has taken quite some time.

  • Intel Developer Working On Adding HDR Display Support To Wayland / Weston

    While the Linux desktop's display stack has largely reached parity with Windows and macOS in recent years (most recently, the DRM core properties hitting Linux 5.0 around Adaptive-Sync / VRR), but one of the areas that has remained elusive has been for full HDR display support. We've seen NVIDIA working on nursing the X.Org-based display stack for HDR while now Intel appears to be working on the necessary Wayland changes.

    Back in 2016 is when NVIDIA began looking at the Linux shortcomings for HDR display support and ended up proposing the DeepColor X11 extension (still yet to be merged) and other efforts for an HDR Linux desktop compared to traditional SDR content. Now with Intel's Icelake processors coming out later in the year with "Gen 11" graphics and their Xe discrete graphics potentially coming next year, HDR display support is now on the minds of their open-source driver developers.

  • The Expected Linux Driver State For The Radeon VII

    With yesterday's surprise announcement of the Radeon VII "Radeon 7" as a new $699 7nm second-generation Vega consumer graphics card launching in early February, you may be wondering about the open-source Linux driver support state. While nothing official has come down the wire yet, here is what appears to be the state for this new Vega graphics card on Linux.

    AMD hasn't communicated yet about the Linux driver support for Radeon VII, I don't have any review sample or the like at this time, but given the number of questions since yesterday about Linux support, here's what I know based off my close monitoring of the AMD open-source Linux driver development.

More in Tux Machines

Reducing sysadmin toil with Kubernetes controllers

Kubernetes is a platform for reducing toil cunningly disguised as a platform for running containers. The element that allows for both running containers and reducing toil is the Kubernetes concept of a Controller. [...] The canonical example of this in action is in how we manage Pods in Kubernetes. A Pod is effectively a running copy of an application that a specific worker node is asked to run. If that application crashes, the kubelet running on that node will start it again. However, if that node crashes, the Pod is not recovered, as the control loop (via the kubelet process) responsible for the resource no longer exists. To make applications more resilient, Kubernetes has the ReplicaSet controller. The ReplicaSet controller is bundled inside the Kubernetes controller-manager, which runs on the Kubernetes master node and contains the controllers for these more advanced resources. The ReplicaSet controller is responsible for ensuring that a set number of copies of your application is always running. To do this, the ReplicaSet controller requests that a given number of Pods is created. It then routinely checks that the correct number of Pods is still running and will request more Pods or destroy existing Pods to do so. By requesting a ReplicaSet from Kubernetes, you get a self-healing deployment of your application. You can further add lifecycle management to your workload by requesting a Deployment, which is a controller that manages ReplicaSets and provides rolling upgrades by managing multiple versions of your application's ReplicaSets. Read more

Android Leftovers

Server: IBM, LAMP and Kubernetes

  • A HATS For Many Occasions
    IBM gives customers plenty of options when it comes to its Rational Host Access Transformation software, including several modes of operation, different runtime options, and support for different operating systems in screen modernization engagements. With last week’s launch of HATS version 9.7, the development and deployment options got even wider. Regardless of which downstream options a HATS customer ultimately chooses, it all starts out basically the same on the front side of the sausage machine: Customers come to HATS because they have a 5250 (or 3270 or VT100) application that they want to transform, but they don’t want to go through the hassle, expense, and risk of modifying the IBM i, z/OS, or Unix application’s source code.
  • Six top skills that you should acquire in 2019
    There is a growing demand for the fullstack development skill set, which is the ability to develop tech both on the front-end/client side and back-end/server side. As you can’t learn all, select combinations like MEAN or LAMP stack.
  • Kubernetes and the Enterprise
    The reason we were having this conversation was around SUSE’s Cloud Application Platform (CAP). This is our Kubernetes focused Cloud Foundry distribution. And as part of the Kubernetes focus, we have been supporting and running SUSE CAP on Azure’s AKS for the last year or so. The conversation continued with observations that Kubernetes was clearly the future across IT. Yet to date, Cloud Foundry still has a good following with the large enterprise. And the thinking was that the Cloud Foundry approach really helped the large enteprise work with their applications, even if the applications were purely ‘container’ applications. Cloud Foundry makes the container-side of managing your ‘container’ application transparent. This approach ultimately lowers the tasks, breadth of tooling, and knowledge you have to surround Kubernetes with. It was with this thought, that a light-bulb went on.

today's howtos