Posts

llvmpipe/lavapipe: anisotropic texture filtering

In order to expose OpenGL 4.6 the last missing feature in llvmpipe is anisotropic texture filtering. Adding support for this also allows lavapipe expose the Vulkan samplerAnisotropy feature. I started writing anisotropic support > 6 months ago. At the time we were trying to deprecate the classic swrast driver, and someone pointed out it had support for anisotropic filtering. This support had also been ported to the softpipe driver, but never to llvmpipe. I had also considered porting swiftshaders anisotropic support, but since I was told the softpipe code was functional and had users I based my llvmpipe port on that. Porting the code to llvmpipe means rewriting it to generate LLVM IR using the llvmpipe vector processing code. This is a lot messier than just writing linear processing code, and when I thought I had it working it passes GL CTS, but failed the VK CTS. The results also to my eye looked worse than I'd have thought was acceptable, and softpipe seemed to be as bad. Once

DOOM (Vulkan) + lavapipe

Image
For the fun of it I decided to run some real apps on lavapipe. Talos Principle is still rando crashing on startup, occasionally whatever magic value ends up being right in uninit memory and it suddenly runs fine. I started Rise of the Tomb Raider, and it renders really slowly up to the menu. Then I gave DOOM 2016 with the Vulkan renderer a go, and with a few lavapipe hacks to enable some feature bits, I managed to get it to load a game image. It's taking 5-6s per frame to render. However most of the slowness in the frame is the BPTC texture loading which is a path that I've done no tuning for so it definitely running very slowly. I think RoTR is also hitting that slow path so I guess I've some incentive to look at cleaning it up.  

lavapipe reporting Vulkan 1.1 (not compliant)

The lavapipe vulkan software rasterizer in Mesa is now reporting Vulkan 1.1 support. It passes all CTS tests for those new features in 1.1 but it stills fails all the same 1.0 tests so isn't that close to conformant. (lines/point rendering are the main areas of issue). There are also a bunch of the 1.2 features implemented so that might not be too far away though 16-bit shader ops and depth resolve are looking a bit tricky. If there are any specific features anyone wants to see or any crazy places/ideas for using lavapipe out there, please either file a gitlab issue or hit me up on twitter @DaveAirlie

crocus: gallium for the gen4-7 generation

The crocus project was recently mentioned in a phoronix article . The article covered most of the background for the project. Crocus is a gallium driver to cover the gen4-gen7 families of Intel GPUs. The basic GPU list is 965, GM45, Ironlake, Sandybridge, Ivybridge and Haswell, with some variants thrown in. This hardware currently uses the Intel classic 965 driver. This is hardware is all gallium capable and since we'd like to put the classic drivers out to pasture, and remove support for the old infrastructure, it would be nice to have these generations supported by a modern gallium driver. The project was initiated by Ilia Mirkin last year, and I've expended some time in small bursts to moving it forward. There have been some other small contributions from the community. The basis of the project is a fork of the iris driver with the old relocation based batchbuffer and state management added back in. I started my focus mostly on the older gen4/5 hardware since it was simpler

sketchy vulkan benchmarks: lavapipe vs swiftshader

 Mike, the zink dev, mentioned that swiftshader seemed slow at some stuff and I realised I've never expended much effort in checking swiftshader vs llvmpipe in benchmarks. The thing is CPU rendering is pretty much going to top out on memory bandwidth pretty quickly but I decided to do some rough napkin benchmarks using the vulkan samples from Sascha Willems. I'd also thought that due to having a few devs and the fact that it was used instead of mesa by google for lots of things that llvmpipe would be slower since it hasn't really gotten dedicated development resources. I picked a random smattering of Vulkan samples and ran them on my Ryzen  workstation without doing anything else, in their default window size. The first number is lavapipe fps the second swiftshader. gears: 336 309 instancing: 3 3 ssao: 19 9 deferredmultisampling:  11 4 computeparticles: 9 8 computeshader: 73 57 computeshader sharpen: 54 34 I guess the swift is just good marketing name, now I'm not sure

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/X.org 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] https://www.khronos.org/confor m