Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Is Vulkan the future?
#1
Over the holidays I did a bit of searching and trying to view anything I could regarding OpenGL ES on YouTube, but this search always seemed to land on a vid about Vulkan. Most of the actual OpenGL ES vids or tutorials I found seemed to be focused on Android.  I suppose this does show a need for a book such as "The Fundamentals of C/C++ Game Programming"


With regards to Vulkan, one particular vid I found was from GDC 2018 titled "Getting explicit: How Hard is Vulkan really?" where a  group of folks from various studios described their adventure with Vulkan.  They all seemed to admit that it did take a bit more work to get something going with Vulkan, but once they had it up and running it was relativity easy to other functions working.  The interesting part was from the Dustin Land from id Software where he mentioned that idTech has been completely ported to Vulkan and they are no longer using OpenGL outside of legacy support.

The panel at the end of the vid was even more interesting where most of the folks on the panel mentioned that for any open positions that they had, they had no openings for OpenGL and are only looking for those with Vulkan experience.

https://www.youtube.com/watch?v=0R23npUCCnw


There is even an effort to get Vulkan support with the Raspberry Pi 4 and the VideoCore IV GPU but not much real progress here.
https://www.phoronix.com/scan.php?page=n...-Code-Drop

The NVIDIA Jetson Nano does have Vulkan 1.1 support and seems to work fine with some of the samples I have found. 
https://www.khronos.org/conformance/adop...t-products

Although there is a Mali-T760 support with Vulkan 1.0, I have yet to get it to work with the Tinkerboard running Armbian with manual installed Mali drivers.

It does seem like the industry is moving toward Vulkan so It will be interesting to see how this all progresses as more support is added to Vulkan.
Reply
#2
My own pitiful attempts to get Vulkan working have just been frustrating, and at the moment I can't see the real benefit over OpenGL in any flavour. DirectX 12 is also painful stressful to use.

I can't honestly say at this point I know enough to give a valid opinion, but I do hear that it is being adopted more and more in engines, so will take hold soon. But what advantage it has over well written OpenGL  currently escapes me.
Brian Beuken
Lecturer in Game Programming at Breda University of Applied Sciences.
Author of The Fundamentals of C/C++ Game Programming: Using Target-based Development on SBC's 



Reply
#3
From what I have seen the main advantage with Vulkan is that it utilizes less of the CPU and takes advantage of features in the GPUs. Most of vids I had seen just kept referencing that OpenGL (ES) is old and a new way of thinking is needed. It does a take bit more processing power to show any performance advantage though. For the Ray Tracing, a NVIDIA RTX is needed so that makes it a bit limiting.

They still do not have full Metal support at this point but are working on it.

Since it a bit more lower level than OpenGL, it does take more work to do the same thing OpenGL does.

It is supposed to be cross platform, so there is no ES version for embedded systems. A good example is Adobe Premiere Pro Rush which was built with Vulkan.

Vulkan is certainly something to keep an eye on.
Reply
#4
its on the way

https://www.raspberrypi.org/blog/vulkan-...-triangle/
Brian Beuken
Lecturer in Game Programming at Breda University of Applied Sciences.
Author of The Fundamentals of C/C++ Game Programming: Using Target-based Development on SBC's 



Reply
#5
Yeah, i had seen the mention of support for the VideoCore VI so it is cool that the RasPi folks are working on it now.

From what I am seeing, the push is to move new development from OpenGL(ES) to Vulkan since it is cross platform.

For the RasPi, it does seem like it will be sometime before we see any real libs to use though.
Reply
#6
I've been going on and off between Vulkan and OpenGL.
Vulkan is nice because it gives you finer control over graphics, but at the same time it sucks because you have to set up a whole lot more.
Currently working with OpenGL, might move to Vulkan in the future if it really makes a difference performance-wise.
Reply
#7
I'm currently doing my main project over on my www.patreon.com/brianbeuken page in OpenGLES3.1
I've decided my next project is going to be a Vulkan project, just to learn it and put it into some practical use... not in a hurry though, I've done a few tutorials in the last year and it still leaves me cold... but....for the sake of science I will endure...
Brian Beuken
Lecturer in Game Programming at Breda University of Applied Sciences.
Author of The Fundamentals of C/C++ Game Programming: Using Target-based Development on SBC's 



Reply
#8
(05-19-2024, 12:15 PM)Brian Beuken Wrote: I'm currently doing my main project over on my www.patreon.com/brianbeuken page in OpenGLES3.1
I've decided my next project is going to be a Vulkan project, just to learn it and put it into some practical use... not in a hurry though, I've done a few tutorials in the last year and it still leaves me cold... but....for the sake of science I will endure...

I've been speedrunning through a Vulkan tutorial series yesterday, and intend on continuing.
My impressions so far:
The code is surprisingly cleaner than if I were to use OpenGL, but I really don't like the very fucking long class names they're using.
Having been coding in C almost exclusively for 1 year, I came to love things like `strncmp()` or `snprintf()`.
Now in Vulkan it's like `device.enumerateDeviceExtensionProperties()` or `instance.destroyDebugUtilsMessengerEXT()` (yes, I'm using C++ for Vulkan), which takes up a lot of horizontal space, so prepare not being able to program on a 9:16 monitor without using line breaks like a maniac!

The other problem I noticed is that it seems like the API's change all the time.
I've been following a tutorial that uses Vulkan 1.2, I use Vulkan 1.3.
I didn't know if this is a version problem or an OS problem (he's using Windows, I'm using OpenBSD), but this part of the code didn't work for me, because it says that `eWarning`. `eVerbose`, and `eError` are not members of `vk:: DebugUtilsMessageTypeFlagBitsEXT`, and that you can't use `vk:: DebugUtilsMessengerCreateInfoEXT()` as a constructor, even though it's available.
As it turned out, the problem was the extremely verbose function names I ranted about 1 paragraph ago, because simply copy/pasting his code ended up fixing the problem.
Because I noticed I was using the wrong function names all along.

But what is clearly a version related problem is `vk:: DispatchLoaderDynamic()`, because on Vulkan 1.3 I'm getting the warning "Definition of implicit copy assignment operator for 'DispatchLoaderDynamic' is deprecated because it has a user-declared copy constructor".

I also intend to experiment with Swift and Metal after releasing a game written in Vulkan.
Not because I like Apple, but because I'm just curious about it.
Reply
#9
Update from 1 week later of full time Vulkan programming (and still far from anything playable in sight), I actually start to enjoy Vulkan.
So much so, I just bought the Vulkan Programming Guide book in both English and Japanese (both 2nd hand though).
The Japanese one arrived today, the English one is expected to arrive tomorrow.

The reason why I enjoy Vulkan now is because even though there's tons and tons of boilerplate (currently roughly 2000 lines of code, barely any of it goes to actually rendering stuff on the screen), it really teaches you how the GPU, CPU, and RAM actually work in the process, and you'll realise really quick how much OpenGL has been holding my hand all this time by providing almost everything for me just so I can render stuff to the screen as soon as possible.
In Vulkan you actually have to set everything up from the ground up, kind of akin to how GUI programming used to be in the very early days of Xorg back in 1984, when it could take months before you could even show an empty window on the screen.

It's not the best API to work with if you want to make a quick buck real quick, and probably not a good idea to teach it in a single semester (I'd recommend 2 to 3 semesters for that), but it really is the best API if you want to build an engine from the ground up and learn how the computer exactly works, and I really enjoy this whole process.

For those who are wondering, I'm using this playlist, I found it to be really good and he explains quite a lot of things in depth to make you better understand various concepts, I downloaded the entire playlist to my local machine using yt-dlp, because 1) I can watch in 1080p without having to connect to the internet, and 2) YouTube sucks.
The only thing I dislike about this guy is that at one point he completely rewrites everything off-camera, and the only way to get in line with his new code is to just copy/paste from his Github repository, which is pretty unhelpful.

I've read through a few pages of the Japanese Vulkan book while riding a train, so a few more episodes to go, and I'll just transition to the book instead.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)