Linux graphics, why sharing code with Windows isn't always a win.

A recent article on phoronix has some commentary about sharing code between Windows and Linux, and how this seems to be a metric that Intel likes. I'd like to explore this idea a bit and explain why I believe it's bad for Linux based distros and our open source development models in the graphics area. tl;dr there is a big difference between open source released and open source developed projects in terms of sustainability and community. The Linux graphics stack from a distro vendor point of view is made up of two main projects, the Linux kernel and Mesa userspace. These two projects are developed in the open with completely open source vendor agnostic practices. There is no vendor controlling either project and both projects have a goal of try to maximise shared code and shared processes/coding standards across drivers from all vendors. This cross-vendor synergy is very important to the functioning ecosystem that is the Linux graphics stack. The stack also relies in some place

llvmpipe is OpenGL 4.5 conformant.

(I just sent the below email to mesa3d developer list). Just to let everyone know, a month ago I submitted the 20.2 llvmpipe driver for OpenGL 4.5 conformance under the SPI/ umbrella, and it is now official[1]. Thanks to everyone who helped me drive this forward, and to all the contributors both to llvmpipe and the general Mesa stack that enabled this. Big shout out to Roland Scheidegger for helping review the mountain of patches I produced in this effort. My next plans involved submitting lavapipe for Vulkan 1.0, it's at 99% or so CTS, but there are line drawing, sampler accuracy and some snorm blending failure I have to work out. I also ran the OpenCL 3.0 conformance suite against clover/llvmpipe yesterday and have some vague hopes of driving that to some sort of completion. (for GL 4.6 only texture anisotropy is really missing, I've got patches for SPIR-V support, in case someone was feeling adventurous). Dave. [1] m

lavapipe: a *software* swrast vulkan layer FAQ

(project was renamed from vallium to lavapipe) I had some requirements for writing a vulkan software rasterizer within the Mesa project. I took some time to look at the options and realised that just writing a vulkan layer on top of gallium's llvmpipe would be a good answer for this problem. However in doing so I knew people would ask why this wouldn't work for a hardware driver. tl;dr DO NOT USE LAVAPIPE OVER A GALLIUM HW DRIVER, What is lavapipe? The lavapipe layer is a gallium frontend. It takes the Vulkan API and roughly translates it into the gallium API. How does it do that? Vulkan is a lowlevel API, it allows the user to allocate memory, create resources, record command buffers amongst other things. When a hw vulkan driver is recording a command buffer, it is putting hw specific commands into it that will be run directly on the GPU. These command buffers are submitted to queues when the app wants to execute them. Gallium is a context level API, i.e. like OpenGL/D3D10. Th

DirectX on Linux - what it is/isn't

This morning I saw two things that were Microsoft and Linux graphics related. a) DirectX on Linux for compute workloads b) Linux GUI apps on Windows At first I thought these were related, but it appears at least presently these are quite orthogonal projects. First up clarify for the people who jump to insane conclusions: The DX on Linux is a WSL2 only thing. Microsoft are not any way bringing DX12 to Linux outside of the Windows environment. They are also in no way open sourcing any of the DX12 driver code. They are recompiling the DX12 userspace drivers (from GPU vendors) into Linux shared libraries, and running them on a kernel driver shim that transfers the kernel interface up to the closed source Windows kernel driver. This is in no way useful for having DX12 on Linux baremetal or anywhere other than in a WSL2 environment. It is not useful for Linux gaming. Microsoft have sub

Senior Job in Red Hat graphics team

We have a job in our team, it's a pretty senior role, definitely want people with lots of experience. Great place to work,ignore any possible future mergers :-)

Open source compute stack talk from Linux Plumbers Conference 2018

I spoke at Linux Plumbers Conference 2018 in Vancouver a few weeks ago, about CUDA and the state of open source compute stacks. The video is now available.

virgl - exposes GLES3.1/3.2 and GL4.3

I'd had a bit of a break from adding feature to virgl while I was working on radv, but recently Google and Collabora have started to invest in virgl as a solution. A number of developers from both companies have joined the project. This meant trying to get virgl to pass their dEQP suite and adding support for newer GL/GLES feature levels. They also have a goal for the renderer to run on a host GLES implementation whereas it currently only ran on a host GL. Over the past few months I've worked with the group to add support for all the necessary features needed for guest GLES3.1 support (for them) and GL4.3 (for me). The feature list was roughly: tessellation shaders fp64 support ARB_gpu_shader5 support Shader buffer objects Shader image objects Compute shaders Copy Image Texture views With this list implemented we achieved GL4.3 and GLES3.1. However Marek@AMD did some work on exposing ASTC for gallium drivers, and with some extra work on EXT_shader_framebuffer