Both versions added lots of new capabilities that have been lacking from the client application and database, so even though there are lots of reports for OpenGL ES 3.1 and 3.2 those only contain capabilities up to OpenGL ES 3.0.
GLES 3.1 brought compute shaders, GLES 3.1 geometry and tessellation shaders. Compute is an important feature and not having that information in the database was really hindering it’s usefulness. Continue reading →
I finally found some time to overhaul the OpenGL ES hardware database. I admittedly neglected my OpenGL databases in recent years (mainly due to Vulkan ® and a severe lack of spare time), and especially the OpenGL ES one was in dire need of an overhaul and a cleanup. So I spent a few days fixing lots of problems (both technical and data-related) as well as getting it (mostly) on par with the Vulkan hardware database and the changes are now live.
In general the database should now run much faster and contain better data. If you notice anything (errors, bugs, missing data) drop me a line.
So here is a small run-down of the stuff that has been changed and fixed.
Note that all my open source examples, demos and applications will work fine with Vulkan 1.1 SDK and drivers. I’m already planing to add 1.1 specific functions to the Vulkan Hardware Capability Viewer and my examples.
I have added a new example to my open source C++ Vulkan examples that demonstrates the basic use of conservative rasterization using the VK_EXT_conservative_rasterization extension. This has been missing from Vulkan some time now (while other APIs already offer this feature) but has recently been added and is already support by at least NVIDIA.
Conservative rasterization changes the way fragments are generated, and enabling over estimation generates fragments for every pixel touched instead of only pixels that are fully covered.
One of the most common Vulkan related that I’m seeing a lot is about rendering stuff that somehow ends up being not visible on the screen, even though technically everything looks okay (no validation layer errors, correct buffer uploads, etc.).
Luckily there are debugging tools tools like RenderDoc that can help locating and fixing such problems. But not everyone knows about such tools or how to use them for debugging these kind of problems.
So I decided to upload a narrated video that shows how to debug non-visible models (in Vulkan) using RenderDoc:
If you’re interested in additional narrated, Vulkan related videos just drop me a line.
I have released the first working version of a separate (from the examples) Vulkan physical based rendering example that uses the glTF 2.0 model file format.
glTF is a royalty free format specification by the Khronos Group and is a new format for 3D models gaining lots of traction. With version 2.0 it also added several PBR extensions and definitions.
I decided to make this a stand-alone project instead of “just” another example in my Vulkan C++ example repository to make it easier getting into the code. While lots of people seem to learn from my examples they contain a lot of abstraction, and for this example I wanted the code to be very readable and verbose on purpose so those interested in doing PBR with Vulkan and glTF 2.0 get a closer look at the actual code without that much abstraction as was the case for my examples.
So while it still contains a few base classes from my examples, these have been stripped down (e.g. no more initializers) and the main class is pretty verbose and doesn’t do much Vulkan abstraction. I hope this makes it easier to actually get into the relevant Vulkan parts.
One big problem of traditional shadow mapping, esp. with large outdoor scenes is the resolution you get as one single shadow map has to cover the whole camera spectrum.
Upon popular request I finally got around combining android device data from my Vulkan and OpenGL ES hardware databases into a convenient table. This should be handy if you plan on supporting both apis on Vulkan or if you just need to check for general device support.
It combines all android device reports from the Vulkan database with all reports from the OpenGL ES database and also uses google’s official device list for translating device IDs (stored with Vulkan and OpenGL ES reports) into actual retail names.
Each entry displays the highest supported Vulkan and OpenGL ES version if there is a report present for that device in at least one of the database and also lists what apis are supported by a given device. Clicking on the version opens up the report for this device in the respective database.
So if you just want to see all devices that support (have a report present for) Vulkan and OpenGL ES you can filter by the list of supported apis or just pass this selection as a parameter to the url: https://android.gpuinfo.org?apis=vk,gles
I have just added two minimal, mostly self-contained cross-platform headless Vulkan examples to my open source C++ Vulkan repository. Unlike the other examples in my repository these two don’t require a surface (created from a window) and as such can be run on systems with no window compositor.
The intention behind the two examples is to show how Vulkan can be used for running graphics and compute tasks without the need for an actual user interface to be present i.e. in the form of a window, often called “headless mode”. Those could e.g. be run on headless cloud-hosted server instances (like AWS once they add support) with Vulkan support.
With my Vulkan C++ example github repository approaching 200 MB in size I decided it was about time to shrink it down to a reasonable size again. Shrinking a git(hub) repository isn’t just about deleting locally present files but requires cleaning up the history as files that have been removed are still present in the repository’s history and therefore still contribute to it’s size.
A big chunk of the repo’s size is caused by binary assets like textures and 3d models. When I started out with my Vulkan example there were only a few assets so I just added them to the repository. In hindsight this was the wrong decision, so one of my primary goals was to remove all those assets from the repository and it’s history. I already stopped adding assets while I did some examples using HDR textures and moved them into a separate asset pack that needs to be downloaded to actually run these examples. After removing the assets I’ll no longer add any of them to the repo but rather put them into the separate asset pack.
So in this article I’ll try to describe how to shrink down a long running repository without having to recreate it. For my Vulkan examples this resulted in a much smaller repository that’s a lot faster to clone. Continue reading →
