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.
It’s been some months I am only writing code for work (I am going to post soon about the cool things we are doing there) and have stopped the hobby projects. But this weekend (that was Easter for Greeks) there was a Ludum Dare jam with theme “Keep it alive”. Easter in quarantine was the perfect time for a break. 🙂
This year (2019) GUADEC took place in my city, Thessaloniki. Although I’ve never had any direct contributions to GNOME I wouldn’t miss the opportunity to attend the conference: the traveling time to the venue was about 15 minutes!
My GUADEC-Rust-workshop-inspired helloworld in Rust
This post is mostly instructions on how to install the Temple OS on Debian using VirtualBox. Temple OS is an operating system written from scratch by Terry A. Davis in order to make programming and the creation of games more fun. Its shell is a Holy-C compiler where users can write commands in Holy-C and see the generated assembly. Temple OS lacks networking and security. Every program runs in ring-0 mode, which means that it has full access to the hardware. This is on purpose, “because it’s fun”. As Terry said, he didn’t want to write another UNIX and his goal was to create a modern Commodore64-like OS where the users can start writing code immediately after boot. If you are not familiar with the Temple OS and Terry A. Davis’s story, you can check the links at the end of this post.
This is another post of the series where I explain the ideas I try in order to improve the upsampling of the half-resolution SSAO render target of the VKDFsponza demo that was written by Iago Toral. In a previous post (3.2), I had classified the sample neighborhoods in surface neighborhoods and neighborhoods that contain depth discontinuities using the normals. Having this information about the neighborhoods, in the last post, I demonstrated how to further improve the nearest depth algorithm (that was explained in parts 1 and 2 of these series) and reduce the artifacts in the neighborhoods where we detect depth discontinuities. The result was good but we’ve seen that there are still some imperfections in a few edge cases. So, in this post, I am going to talk about some ideas I had to further improve the SSAO and my final decisions.
This is another post of the series where I explain some ideas I tried in order to improve the upscaling of the half-resolution SSAO render target of the VKDFsponza demo that was written by Iago Toral. In the previous post, I had classified the sample neighborhoods in surface neighborhoods and neighborhoods that contain depth discontinuities using the normals. Having this information about the neighborhoods, in this post, I will try to further improve the nearest depth algorithm (see also parts 1 and 2) and reduce the artifacts in the neighborhoods where we detect depth discontinuities.
This post is again about improving the upsampling of the half-resolution SSAO render target used in the VKDFsponza demo that was written by Iago Toral. I am going to explain how I used information from the normals to understand if the samples of each 2×2 neighborhood we check during the upsampling belong to the same surface or not, and how this was useful in the upsampling improvement.
In my previous posts of these series I analyzed the basic idea behind the depth-aware upsampling techniques. In the first post , I implemented the nearest depth sampling algorithm  from NVIDIA and in the second one , I compared some methods that are improving the quality of the z-buffer downsampled data that I use with the nearest depth. The conclusion was that the nearest depth sampling alone is not good enough to reduce the artifacts of Iago Toral’sSSAO implementation in VKDF  to an acceptable level. So, in this post, I am going to talk about my early experiments to further improve the upsampling and the logic behind each one. I named it part 3.1 because while having started the series I’ve found that some combinations of these methods with other ones can give quite better visual results, and as my experiments with the upsampling techniques cannot fit one blog post, I am going to split the upscaling improvements (part 3) in sub-parts.
In the previous post of these series, I tried to explain the nearest depth algorithm  that I used to improve Iago Toral‘s SSAO upscaling in the sponza demo of VKDF. Although the nearest depth was improving the ambient occlusion in higher resolutions the results were not very good, so I decided to try more quality improvements. In this post, I am going to talk about my first experiments on improving the Z-buffer downsampling.