Vulkan update: now with added source code
Today we have a guest post from Igalia’s Iago Toral, who has spent the past year working on the Mesa graphic driver stack for Raspberry Pi 4.
It is almost five months since we announced the Vulkan effort for Raspberry Pi 4. It was great to see how many people were excited about this, and today we would like to give you a status update on our progress over these last months.
When we announced the effort back in January we were at the point of rendering a coloured triangle, which required only minimal coverage of the Vulkan 1.0 API in the driver. Today, we are passing over 70,000 tests from the Khronos Conformance Test Suite for Vulkan 1.0 and we have an implementation for a significant subset of the Vulkan 1.0 API.
Progress so far, in pictures
While I could detail here all the features that we have implemented, I am sure that list would get long and boring very quickly for most of you. So, instead, we would like to show you our progress through pics taken from a bunch of the popular Vulkan demos by Sascha Willems running on Raspberry Pi 4:
Hopefully that is more entertaining than a feature checklist and will help you visualize better where we are now compared to January’s coloured triangle.
Before you get too excited though, while these demos are nice, they are still a far cry from actual games and applications. We still have a lot of work to do before the driver can handle these more complex workloads. Even some of Sascha’s demos don’t run yet, whether because of driver bugs or unimplemented Vulkan features. We still have a lot of work ahead of us.
Next up
I would also like to give you an overview of some of the things we will be working on in the coming months:
Our first priority is to support the basic Vulkan 1.0 feature set. This will involve, at least, supporting compute shaders, input attachments, texel buffers, storage images, pipeline caches, and multisampling. There are some other features that we need to support in Vulkan 1.0, such as robust buffer access etc, but those are probably the largest ones we are currently missing.
Once we are feature-complete we will probably move focus to CTS conformance, which will be all about bugfixing, and making sure we handle spec corner cases. And once we are close to conformance, the driver should hopefully be stable and robust enough that we should probably start testing actual Vulkan applications and games to drive further bugfixing work.
Finally, there will be a lot of performance tuning and optimization work that we will probably tackle in the last stages of development.
So as I said before, we still have a long way to go!
Moving development to an open repository
Before we end this post, I would also like to share another important piece of news: starting today, we are moving development of the driver to an open repository. You can find instructions on how to build and install the driver here. I know this is something that many of you have been asking for, and I am sorry that it took us a few months to get here. But I think that now that we have a more stable driver infrastructure in place, and we don’t feel like we are constantly making large changes every other day, development should be a lot friendlier to external contributors than it may have been a few months ago.
So that’s everything we wanted to share today – I hope you are still excited about Vulkan and looking forward to future updates. In the meantime, if you have questions or are interested in contributing to the driver, join us on irc.freenode.net, #videocore channel.
33 comments
rpiMike
Great news, going to build this later.
Is this just for Raspberry Pi OS 32bit or 64bit also?
Witold
Looking at source it looks both 32-bit and 64-bit will be supported, but it is likely only one of the is being worked on and tested continuously at the moment.
xlazom00
Good work
but whole vulkan is really useless if basic staff like tearing isn’t fixed
https://github.com/raspberrypi/linux/issues/3641
Eric_S
Are you talking about X being naughty in general? (Iirc you need to hack it in order to get double/tripple buffering) and it’s misbehaving all over the place.
Because the RPi people are probably not going to solve that for you, unless they completely move to Wayland or something similar.
xlazom00
Same problem with wayland :(
tianlun2001
Umm if the screen tearing is solved, it will be great. Then this beef-up pi can really become a multi-purpose pc. Gaming, development and general purpose pc. The boot up speed is fast, so we can check something fast. Low power requirements….
Witold
Hi,
this is great. Happy to see it is using Mesa and not a custom from-scratch stack, and is now developed in open. Hopefully it can be merged back into mainline Mesa this year.
The progress is amazing, you already have a lot of stuff working.
Have you tried running Mesa Zink on top of your Vulkan implementation? It only supports OpenGL 2.1, and some bits from 3.x, but could be interesting approach.
Also why your second screenshot is showing inf ms/frame (0 fps)? :D
Cheers,
apinheiro
> Have you tried running Mesa Zink on top of your Vulkan implementation? It only supports OpenGL 2.1, and some bits from 3.x, but could be interesting approach.
We haven’t tested it sorry.
> Also why your second screenshot is showing inf ms/frame (0 fps)? :D
Note that this is a really intensive demo. Tested on a skylake i7 with the anv driver you get 7 fps, so getting a drop when using the rpi4 is expected. Also we didn’t do any serious work to improve performance yet, as we are focusing on features.
Eben Upton
We arranged for that screenshot to be sent back to us from just before the Big Crunch. Not actually Inf: just a floating point representation issue ;)
José Commins
Amazing progress! Very impressive to see the screenshots reflecting the work done so far.
Once the spec complies with 1.0, are there plans to support 1.2 or later as rolling updates?
qxsnap
Congrats on this significant milestone of opening up the driver publicly, with a helpful build guide no less. I’ve been holding back starting an OpenGL project in hopes that Vulkan might catch up. Looks very promising and looking forward to all the progress planned for the coming months.
Nedwig
A few questions:
Once 1.0 is finished, will we see 1.1 and 1.2 support? And for the extensions that apply to the RPI, will we see those as well? Timeline semaphores are now what Khronos group recommends for basically everything, and VkFence is basically useless in 1.2, I’d like to see that in RPI, given there is no hardware reason it can’t be there. Additionally I would like to see the `scalar layout` qualifier extension for similar reasons.
Puffergas
A big thank you ! ! !
rpiMike
Make a quick video of 4 demos:
https://www.youtube.com/watch?v=ygBB3D5vryw
Eben Upton
Awesome – thanks for doing this.
Aardappeltaart
Impressive!
And I foresee big performance gains in the near future.
Just use `middle click` to paste, no need for context menus’s ;)
Lawrence
Very nice and awesome job! On the road to a completely open software and hardware platform here we come. With all the recent announcements for the new board and OS while maintaining that low price point, the Pi is becoming just too compelling a system to ignore. Going to download the code and poke around. Hopefully with the driver now in a public repo the community will jump in and help this pick up some serious steam.
laurent
Great job ! Thanks to the foundation and Igalia for this work !
The Raspberry Pi always be a great platform to work/play with, and thanks to the upcoming 5.4 kernel / 64 bits Raspberry Pi OS, and a great Mesa driver, it will just become the best, according to its price and support/community.
Richard collins
Yum. Yes please and thank you. :)
Nathan Scherdin
All I want for Christmas is Vulkan 1.0? :)
Markus
This is great. I am also wondering if there is any path to support OpenCL? I would like to run hashcat on raspberry pi 4.
Chris Stagg
With a possible future release of blender getting vulcan (2.9x expected)… I really hope they consider making it at least function reasonably on the Pi… having hardware drivers ready might give them a nudge…
Of course it won’t do CG for feature films but would at least offer an introduction with the newest tools to make assets, or even grease pencil shorts!
Shayne O’Neill
Blenders a pretty intensive piece of software. Even with a decently specced desktop intel machine, its going to sweat doing complex scenes
ENDER İSKENDER
Thank you.
Mark Richardson
This is great news for enlarging the community and adopters.
We MUST know, how well does DOOM run after this?
Nick
Well that’s a long way from a triangle. :) Great news, and thanks for all the hard work!
Is there any timeline that would allow for an estimation of when each milestone is expected to be reached? I mean 4.5 months from a triangle to this is actually great progress. :) What would be reasonable to hope for 5 months from now?
Forrrge
A Nvidia engineer has just created a vulkan driver for RPI’s up to version 3 that will run Quake 3 at 720p, 100fps, article here
https://www.tomshardware.com/news/nvidia-engineer-vulkan-driver-raspberry-pi-quake-iii-100-fps
Graham Toal
In related news… https://github.com/Yours3lf/rpi-vk-driver/releases/tag/v1.0
Gavin Higham
Will compute shaders actually run on the Raspberry Pi’s GPU, or will they be emulated on the CPU?
Void Frost
Imagine dolphin emulation running on polished Vulkan drivers. Nice work guys, this is a huge step for emulation and processing in general.
Robert
Sounds interesting. Vulkan on raspberry pi.
all the best for the development.
Vicente
Has someone tried to use this for writing fourier transformations?
Renetrox
Congratulations! I hope they do not leave aside the contribution of Martin Thomas with his driver for raspberry pi 3 and derivatives. It is a great feat of true ingenuity and can be an important source of learning without neglecting the fact that other projects can be driven from it. Currently he has said that he needs help with shaders.