[OpenGL and Vulkan Interoperability on Linux] Part 11: Debugging the semaphore synchronization πŸ„

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.

Continue reading [OpenGL and Vulkan Interoperability on Linux] Part 11: Debugging the semaphore synchronization πŸ„

Building the i965 mesa driver on FreeBSD

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.

Continue reading Building the i965 mesa driver on FreeBSD

EXT_external_objects and EXT_external_objects_fd for the Intel iris driver have been merged into mesa3D! [updated]

This post is a quick status update on OpenGL and Vulkan Interoperability extensions for Linux mesa3D drivers:

Both EXT_external_objects and EXT_external_objects_fd implementations for the Intel iris driver have been finally merged into mesa3D earlier today and will be available in next release! πŸŽ‰

Continue reading EXT_external_objects and EXT_external_objects_fd for the Intel iris driver have been merged into mesa3D! [updated]

Setting up to debug ANGLE with GDB (on Linux)

ANGLE is an EGL/GLES2 implementation on top of other graphics APIs. It is mainly used in systems that lack a native GLES2/GLES3 driver and in some browsers for example Chromium. As recently, I’ve used it for some browsers related work in Igalia‘s WebKit team (more on that coming soon) and had to set it up for debugging with GDB, I’d like to share the few extra settings and the configuration I’ve used to be able to use GDB and step inside the ANGLE API calls to examine the underlying driver API calls, when possible, while I was experimenting with ANGLE-based test programs.

Continue reading Setting up to debug ANGLE with GDB (on Linux)

A hack to instantly display the Vulkan CTS tests output

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 instantly display the CTS output image when I’m running a CTS test, hoping that they might be handy to more people who work on the drivers.

Continue reading A hack to instantly display the Vulkan CTS tests output

[OpenGL and Vulkan Interoperability on Linux] Part 10: Reusing a Vulkan stencil buffer from OpenGL

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.

Continue reading [OpenGL and Vulkan Interoperability on Linux] Part 10: Reusing a Vulkan stencil buffer from OpenGL

[OpenGL and Vulkan Interoperability on Linux] Part 9: Reusing a Vulkan z buffer from OpenGL

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.

Continue reading [OpenGL and Vulkan Interoperability on Linux] Part 9: Reusing a Vulkan z buffer from OpenGL

[OpenGL and Vulkan Interoperability on Linux] Part 8: Using a Vulkan vertex buffer from OpenGL and then from Vulkan

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.

Continue reading [OpenGL and Vulkan Interoperability on Linux] Part 8: Using a Vulkan vertex buffer from OpenGL and then from Vulkan

[OpenGL and Vulkan Interoperability on Linux] Part 7: Reusing a Vulkan vertex buffer from OpenGL

This is the 7th post on OpenGL and Vulkan Interoperability with EXT_external_objects. It’s about another EXT_external_objects use case implemented for Piglit as part of my work for Igalia‘s graphics team. In this case a vertex buffer is allocated and filled with data from Vulkan and then it’s used from OpenGL to render a pattern on screen.

Continue reading [OpenGL and Vulkan Interoperability on Linux] Part 7: Reusing a Vulkan vertex buffer from OpenGL

[OpenGL and Vulkan Interoperability on Linux] Part 6: About overwriting buffers [UPDATED]

This blog post (originally published on: Oct 18, 2020) has been updated in 2022 because some information was inaccurate.

I had misinterpreted a part of the spec about memory mapping and thought that we can’t really overwrite Vulkan allocated buffers. That had to do with the Intel cards memory organization where the GPU memory is RAM and we usually map it the same way we map user allocated memory. I am pretty sure that buffers should be overwritten now, and so I am planning to extend these series with buffer overwriting examples in the future.

Afaik, Tapani PΓ€lli is working on supporting this feature on Intel and AMD might have some support already (I plan to check) so I believe that it will be soon available in most mesa drivers that support the interoperability extensions.

More blog posts about it coming (hopefully) soon!


Links: