As there were no conformance tests (CTS) for this extension, and we needed to test it, we have written (and we are still writing) small tests for piglit that allow the exchange and the synchronization of the exchange of resources such as buffers, textures, and depth or stencil buffers.
This was difficult because not only most drivers were untested (and it was tricky to tell if there’s a bug or we don’t use the extension properly) but also, there were no interoperability examples out there to use them as a reference. We had to use debugging hacks like for example writing the tests in OpenGL first, then in Vulkan, and then in both using interoperability to reach a conclusion about how the extension should be used and if the driver is implementing it correctly.
So, after having spent some time trying to understand the interoperability extensions, I thought that it might be useful to start a series of posts on how to use them on Linux for different cases (eg: exchange a texture, a depth buffer, a stencil buffer, a pixel buffer and so on), using the small tests I’ve written for piglit as example. The full code can be found in the piglit repository, although some of the examples might not be there yet as they’re under review at the time of writing.
In a previous post, I wrote about Vkrunner, and how I used it to play with fragment shaders. While I was writing the shaders for it, I had to save them, generate a PPM image and display it to see the changes. This render to image/display repetition gave me the idea to write a minimal tool that automatically displays my changes every time I save the file with the shader code and use it when the complexity of the scene is increasing. And so, I’ve written sdrviewer, the minimal OpenGL viewer for pixel shaders of the video below:
The video mostly shows the behavior of some GL calls and operations with and without the patches that improve the emulation of the ETC/EAC formats on Gen7 GPUs. The same programs run first with the previous ETC/EAC emulation (upper terminal) and then with the new one (lower terminal).
Hair rendering and simulation can be challenging, especially in real-time. There are many sophisticated algorithms for it (based on particle systems, hair mesh simulation, mass-spring systems and more) that can give very good results. But in this post, I will try to explain a simple and somehow hacky approach I followed in my first attempt to simulate hair (the mohawk hair of the video below) using a mass-spring system.
FOSSCOMM (Free and Open Source Software Communities Meeting) is a Greek conference aiming at free-software and open-source enthusiasts, developers, and communities. The event is solely organized and ran by volunteers (usually university students, communities, Linux User Groups) and is taking place in a different city every year. The attendance is free and everyone is welcome to make a presentation or a workshop related to free and open source projects.
There are several methods to create and display a terrain, in real-time. In this post, I will explain the approach I followed on the demo I’m writing for my work at Igalia. Some work is still in progress.
Sometimes, when working with the mesa drivers, modifying or replacing a shader might be extremely useful for debugging. Mesa allows users to replace their shaders at runtime without having to change the original code by providing these environment variables:
As part of my work for Igalia I wanted to do some environment mapping. I was able to find plenty of high quality .hdr images online but I couldn’t find any (OSS) tool to convert them to cubemap images. Then, Nuclear (John Tsiombikas) gave me the solution: he wrote a minimal tool that does the job quickly and produces high quality cube maps.
So, here’s a short “how to” create cubemaps on Linux using his “cubemapper” program in combination with other OSS tools: