The first GPU AnKi run, almost a decade ago, was in fact an ATI Radeon 9800 Pro. The first version of the deferred shading renderer run in that GPU and not only that. AnKi was running on Linux and the fglrx driver. I don’t remember experiencing many game breaking bugs back then, but then again, AnKi was quite simplistic at the time. One thing I remember was some depth buffer corruption that I had to workaround using a copy. Many years later I understood that this was a driver bug.
The love with ATI didn’t last long and AnKi end up being developed exclusively using nVidias. For many years AMD’s OpenGL driver didn’t have the quality or the features I wanted. Fast forward to today, things are looking far better. Firstly, Mesa has a quite decent OpenGL implementation, secondly, there is a very competitive Mesa Vulkan driver (RADV) and on top of that there is an second opensource Vulkan driver directly from AMD (AMDVLK). The cherry on top is a very good profiler for Vulkan and AMDVLK called Radeon GPU profiler. AMD regularly releases lots of documentation and optimization tips as part of their GPUOpen initiative. This is a great period to own AMD hardware for graphics development that’s why I had to get my hands on an AMD GPU.
In this post I’ll focus on some AMD specific optimizations and I’ll be comparing the two opensource Vulkan drivers.
Continue reading “Optimizing Vulkan for AMD and the tale of two Vulkan drivers”
One of the key differences between OpenGL and Vulkan -and something that needs careful consideration when porting to Vulkan- is the coordinate system. Khronos’ Vulkan working group decided not to use GL’s commonly used coordinate conventions in favor of something more widely used and accurate and that’s the main reason behind this shift.
Continue reading “Vulkan’s coordinate system”
In my Porting AnKi to Vulkan post I went into detail describing how AnKi’s interfaces changed to accommodate the Vulkan backend and how this backend looked like. Eight months have passed since then and a few things changed mainly towards greater flexibility. This post describes what are the differences with the older interfaces, how is the performance currently and what new extensions AnKi is using now.
Continue reading “Porting AnKi to Vulkan part 2”
Someone once said “make it work, make it fast, make it pretty” and I’m happy (and at the same time relieved) to say that the effort of porting AnKi to Vulkan just hit the first major milestone! It’s working! I think this is a good time to share a few thoughts on how this milestone was achieved, the pains and generally the overall experience. Disclaimer: Whatever you read in the following lines reflects my own views and not those of my current employer.
So let’s start from the beginning. Continue reading “The journey of porting AnKi to Vulkan”
This year’s GDC proved to be quite exciting. New technologies, new ideas and some heavyweight announcements. According to the press one of the most exciting presentations was Khronos’ Vulkan API and the demos running on top of it. That really depicted the momentum, the support and the commitment behind the new API.
This article gathers all the publicly shared information behind the new API and adds some personal thoughts in the mix. The fact that I had the pleasure to follow the development of Vulkan API very closely (I was involved early on in the development of a prototype Vulkan driver for ARM’s GPUs) will give some credibility to my personal views. But that doesn’t mean that my views reflect those of my employer. So, whatever you read in the following lines doesn’t necessary reflect the views of my current employer.
Continue reading “Vulkan: The next Khronos graphics API… that is not OpenGL”