One important part of the implementation of the EXT_external_objects and EXT_external_objects_fd groups of extensions for iris (the Intel gallium OpenGL driver) was the semaphore synchronization (EXT_semaphore extension). We’ve seen how the GL semaphores structs and functions that are introduced by this extension should be used in previous interoperability posts. In this post, I’ll try to describe the methods we’ve used to debug the EXT_semaphore implementation itself as well as the fences backend of the iris driver without getting into many driver internals details.
Today I wanted to see if I can build mesa on FreeBSD. I had to do a few fixes in the code of libdrm and mesa, but the rest of the process was very similar to the steps I follow to build mesa on Linux. Only some paths and a few commands and settings had to be slightly different.
This post is about an experiment I’ve performed to investigate if it’s possible to fill a texture from an ANGLE EGL/GLESv2 context (ANGLE is an EGL/GLESv2 implementation on top of other graphics APIs), and use it from a native (for example mesa3D) EGL/OpenGL context on Linux.
It’s been a few weeks I’ve been experimenting with EGL/GLESv2 as part of my work for WebKit (Browsers) team of Igalia. One thing I wanted to familiarize with was using shared DMA buffers to avoid copying textures in graphics programs.
FOSSCOMM (Free and Open Source Software Communities Meeting) is a Greek conference aiming to promote the use of FOSS in Greece and to bring FOSS enthusiasts together. It is organized entirely by volunteers and universities and takes place in a different city each year. This year it was virtual as Greece is under lockdown, and although we’ve missed all the fun of the gathering, there were many interesting talks to watch.
My talk was very similar to the one I’ve given in XDC 2020 about OpenGL and Vulkan Interoperability. It was an update on the EXT_external_objects and EXT_external_objects_fd OpenGL extensions status on various mesa drivers, and Igalia‘s work on them.
Vulkan conformance tests for graphics drivers save their output images inside an XML file called
TestResults.qpa. As binary outputs aren’t allowed, these output images (that would be saved as PNG otherwise) are encoded to text using Base64 and the result is printed between
<Image></Image> XML tags. This is a problem sometimes, as external tools are required to display them. In this post I’d like to share a few simple hacks I’m using to display the CTS output as an image immediately after running a CTS test, hoping that they might be handy to more people who work on the drivers.
This is 10th post on OpenGL and Vulkan interoperability with EXT_external_objects and EXT_external_objects_fd. We’ll see the last use case I’ve written for Piglit to test the extensions implementation on various mesa drivers as part of my work for Igalia. In this test a stencil buffer is allocated and filled with a pattern by Vulkan and then it is used in OpenGL to render something else. We validate that the pattern has been imported correctly and we repeat the process for other depth-stencil formats.
In this 9th post on OpenGL and Vulkan interoperability on Linux with EXT_external_objects and EXT_external_objects_fd we are going to see another extensions use case where a Vulkan depth buffer is used to render a pattern with OpenGL. Like every other example use case described in these posts, it was implemented for Piglit as part of my work for Igalia‘s graphics team to check the extensions implementation of various mesa drivers.
This is the 8th post on OpenGL and Vulkan Interoperability with EXT_external_objects and EXT_external_objects_fd where I explain some example use cases of the extensions I’ve implemented for Piglit as part of my work for Igalia. In this example, a Vulkan vertex buffer is created and filled with vertices and then it’s used to render the same chess board pattern once with OpenGL and once with Vulkan.