> There likely will not ever be one either ... because new hardware usually has Vulkan
You're discounting artificial constraints like, Microsoft only allowing content onto the store if it uses D3D12 for 3D rendering, or only supporting D3D12 on devices like Hololens.
Yes, on desktops, aside from Mac (already covered by MoltenVK), Vulkan is pretty much going to be everywhere, but there are lots of target platforms other than desktops where companies with a vested interest in pushing their own API will have the ability to do so.
This is the driving force behind the Vulkan Portability Initiative. Hopefully as we see more back-ends for the VPI, the Vulkan ecosystem will continue to grow exponentially and become dominant, regardless of the underlying API exposed by a given target platform.
Oh...Uhm...Sorry about that.. (Θ︹Θ)ს
Just wanted to raise awareness of Vulkan, which many were ill-informed about judging from the responses I got. I didn't think it'd get nearly as big as it did...
> Vulkan™ Support(1): Vulkan™ is the successor to OpenGL and a descendant of AMD's Mantle. Vulkan™ is a powerful "low-overhead" graphics API that gives software developers deep control over the performance, efficiency, and capabilities of Radeon™ GPUs and multi-core CPUs. More information on Vulkan™ can be found at https://www.khronos.org/vulkan/.
> (1)Product is conformant with Vulkan 1.0 Specification. Vulkan™ and the Vulkan™ logo are trademarks of the Khronos Group Inc.
I own a MacBook and Linux is running there just fine. Just make some free space on your machine, install http://www.rodsbooks.com/refind/ and off you go. I used Antergos (arch fan) and Fedora and was ready in just about 30 Minutes, including reading into the topic, preperation and installation.
If you are really scared, just buy an external USB3.0 harddrive and boot from it – its super easy i've tested dozen of Linux distributions that way.
You can just use the compute functionality of Vulkan (no swapchain) and maybe accelerate it using either VK_KHR_ray_query or VK_KHR_ray_tracing_pipeline. You could follow the NVIDIA ray tracing tutorials or you may take a look at Ray Tracing in one Weekend. There are also a lot of examples on shadertoy.
On top of the website you mention, I have also used the android application AIDA64 for quick look up of the capabilities (it is in the "devices" menu) (https://play.google.com/store/apps/details?id=com.finalwire.aida64&hl=en). The inability to update GPU drivers is indeed a huge handicap as there can be significant changes in the capabilities. Ex: my tab s3 became capable of doing multi draw indirect following an update.
Afaik that one has been discontinued. For my Intel Linux development box I moved to using https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa or I just built mesa from source myself (with the steps from my gist at https://gist.github.com/SaschaWillems/47be6970a3e99a3d30e1).
This slide from Valve's presentation on Vulkan today reveals that Vulkan compatibility will be a minimum requirement for Steam Machine hardware. I would read that to also mean the Vulkan API will be out and ready by the time Steam Machines launch.
On the other hand, you have all these global players involved in Vulkan and none of them would pay the fees? Not even Oculus, Valve, EA, Epic, Blizzard, Unity, who should have interest in GDC?
Don't think they'll delay it that long.
https://www.khronos.org/vulkan
This doesn't sound like they slipped the release by 6 months. Back at SIGGRAPH last year in August they said that they're in a soft freeze and are still looking for a launch later in 2015 "not super early but we should make it".
It's currently free on Amazon too! Might be more convenient for those of you who own a Kindle. https://www.amazon.ca/Vulkan-Programming-Guide-Official-Learning-ebook/dp/B01MXGZR73 I'm in Canada but it appears free to me on the .com site as well.
Is this intentional? I couldn't find any reference to it online until I checked this subreddit. I would have thought there would be a press release if it was released as free, especially if the "sale" is temporary.
vkguide and vulkan-tutorial are good starting points for understanding how to set up a Vulkan project.
If you haven't done any graphics programming ever, I have recently came across a free course by Autodeskthat I really liked. It uses ThreeJS as its demos and some of the demos don't work anymore but it is a really good course to get you accustomed with what is waiting for you in 3D graphics world.
Additionally, I would suggest to create a development board (e. In Notion or Trello) and keep track of what you are doing and you might want to do. It will help you to always be on track and not get burned out because the the journey you are taking is going to be pretty vast and sometimes bumpy. After your first triangle draw, set up smaller goals for yourself and achieve them to keep yourself motivated.
lol i try my best too. Next video should be finished by Tuesday, and that will cover the basics up to drawing a triangle. Following that I'll release 3 to 4 videos per month for the next few months.
I've never tried setting up VSCode for MSVC on windows, but if I did I'd start here : https://code.visualstudio.com/docs/cpp/config-msvc
> Pulling a political coup wasn’t easy — it was tried in the mid-2000s as “OpenGL 3.0”, but since there were less graphics vendors in the day, and since game developers were not allowed as Khronos members, NVIDIA was able to wield enough power to maintain the status quo.
This is historically inaccurate. That version of OpenGL that was never released was largely the work of Michael I. Gold, an NVIDIA employee. NVIDIA employed the spec lead and inventor of the key innovations.
An old Khronos doc: > Gold, Michael - Technical Lead of the Core OpenGL team , NVIDIA > > Michael Gold joined NVIDIA in 1997 and is currently Technical Lead of the Core OpenGL team where he has been a driving force behind the industry's highest quality implementations. As NVIDIA’s ARB representative, Michael has been instrumental in the evolution of OpenGL; and is now a catalyst for the “new object model revolution” as a primary innovator behind key portions of OpenGL 3.0.
But doesn't the perspective matrix shift W by an amount proportional to Z? Projective space pretty much looks like this https://www.desmos.com/calculator/kgacxisn5k
and altering W (in the desmos graph Y) is a bit like tilting the projective plane and projecting again, causing the characteristic foreshortening. But wouldn't Z=0 be perfectly undistorted then? Is Z=0 somehow offset to be at the near plane?
At the moment, I install dolphin from the PPA:
https://launchpad.net/~dolphin-emu/+archive/ubuntu/ppa for info
Then install the experimental build which is: sudo apt-get install dolphin-emu-master
From there, the graphics options are set by defualt to use the experimental Vulkan Drivers - and once you go to boot a rom, it pops up with a few messages in succession:
'Failed to create Vulkan instance' and another pops up after: 'Fifo shutting down while active', when I close this one I get a new dialog claiming 'Failed to initialize video backend!
This guy in the forum post I linked earlier said:
Yes Dolphin compiles fine, but apparently you can't start a game with the Vulkan driver. It seems that the Vulkan library packages provided by Canonical don't have XLIB support compiled in them, only XCB.
You seem to have to install/copy the libraries and binaries from the LunarG Vulkan SDK to get the Vulkan support in Ubuntu.
I dont think thats right though. I appreciate you offering to help! Hopefully you can :D
Not the op but think these might be the PPAs, from my sources.list: You already know the dangers of jacked up video drivers and ubuntu, so use at your own risk ;-)
Edit: these were not the vulkan shown PPAs below, this appears to be: https://launchpad.net/~canonical-x/+archive/ubuntu/vulkan
Currently using nvidia-355, which I'm pretty sure is the newest version. I currently need to use this official PPA to do so but it's going to be in the mainline soon enough.
"Fields like pNext and sType are initialized by the wrapper." Yeah I forgot to remove them!
Currently I'm using MinGW-64 4.9.2. https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.2/threads-posix/seh/
Quick note for people of the future.
I found this slideshow that seems interesting for this topic: https://www.slideshare.net/tlorach/vkfx-effective-approach-for-vulkan-api
I personally find frame graphs to be a bit on the overkill side for what I want to do with my hobby engine and I also feel like its more intended to deal with barrier/synchronization issues between renderpasses than writing less code (which is what I'm looking for). As far as abstracting descriptor sets specifically goes, I find the idea of moving everything to data more preferable. I had the thought of implementing something like what was presented in those slides independently, but found that somebody was already working on it. It seems like he'll release the source to github some day in the coming months, so I'll be on the lookout.
Ok this is getting weirder every minute... I wanted to print out the loaded extensions with the following code:
std::vector<const char*> extensions; unsigned int glfwExtensionCount = 0; auto glfwExtensions = glfwGetRequiredInstanceExtensions(&glfwExtensionCount); for (unsigned int i = 0; i < glfwExtensionCount; i++) { std::cout << glfwExtensions[i] << std::endl; extensions.push_back(glfwExtensions[i]); }
After executing the program nothing got printed to the console. So I tried to print out the number of loaded extensions, glfwExtensionsCount
. This returned 0
which seemed quite strange to me. The official glfw documentation stated the following:
> const char** glfwGetRequiredInstanceExtensions ( uint32_t * count )
> [out] count
Where to store the number of extensions in the returned array. This is set to zero if an error occurred.
So I tried to check the result of glfwVulkanSupported()
to check if GLFW could find the Vulkan loader. This returned GLFW_FALSE
which equals 0
.
After this I took my old code which was made with the vulkan-tutorial.com (it uses GLFW) and tried to debug it. The glfwGetRequiredInstanceExtensions(...)
function returned
VK_KHR_surface VK_KHR_xcb_surface in this program.
EDIT: So I am currently working on fixing some GLFW issues, maybe they are the cause.
Cryengine vulkan is on track for July release
https://www.cryengine.com/news/new-push-coming-to-github-ce-54-sneak-peek
Which, I think just leave FrostBite and Anvil as the "big" not-supported engine out there.
Various thoughts from a person who doesn't know much about these things:
I have the impression that there are certain things that OpenCL and CUDA can do that GLSL compute shaders cannot. Like, some way to have a kernel dynamically launch another kernel, or something? And (on NVIDIA hardware) some way to take advantage of special super-fast inter-thread communication within a warp (32 threads running in lockstep) that works like shared memory sort of but is even faster?? And also there are some, like, specific math functions and stuff that are in OpenCL but not in GLSL, I think. Although that only matters for performance if they're directly supported in hardware I suppose. But maybe some of them are.
I've only barely used OpenCL, and I haven't tried CUDA at all, so I'm vague on all that stuff. But I think maybe if you want the very best performance then you need to use the latest version of OpenCL or CUDA, and not a GLSL compute shader running on Vulkan (or a GLSL compute shader running on OpenGL)? (And also, that seems to mean that you're stuck with either OpenCL on AMD or CUDA on NVIDIA, because NVIDIA doesn't seem to support the latest OpenCL, and obviously AMD does not support CUDA.)
That said, one can do lots with GLSL compute shaders in Vulkan. They are fast and good. Just not fastEST maybe? Or I could be wrong. Anyway I'm using them in a project and they are working fine for me.
There's also the question of whether one wants to use mainly floats or mainly doubles. That seems to be something that influences hardware choice more than it influences software platform choice, maybe? Or maybe it's both. I dunno I just use floats, because I'm more on the gaming side than on the scientific simulation side and gamers have GPU hardware that much prefers 32-bit values at present. I kinda wish I could use doubles though.
There may be Vulkan-OpenCL integration someday: https://www.khronos.org/vulkan/faq#khronos-apis-opencl
Apple is a member of the Vulkan work group. They're 100% going to support Vulkan.
Not to mention that Apple would love developers to move from DirectX to Vulkan.
https://www.khronos.org/vulkan
Scroll to the bottom
If you look at the slides(slide 13 in the first and slide 5 in the second) you'll see apple is part of the Vulkan team or at least a member there of. Also on the Vulkan page Apple's logo is present.
People in this thread probably want something like <strong>https://devdocs.io/vulkan/</strong> if they would just update to the latest version of the Vulkan spec(it currently only has 1.0.59 of the spec). Maybe Khronos should host something similar or someone can spin up their own version of devdocs with the latest spec because right now the whole specification is such a pain to navigate when I just want to look up a description for a device-limit or valid input for a create-info structure or info on an extension that isn't just a stray .txt on the github repo that manages to be the only google result.
As a developer just trying to look up proper documentation it's a bit of a shaky mess to track down specific slivers of info on a particular usage pattern or description of a struct-member.
Yes, Samsung has already cooperated with EpicGames releasing an android vulkan demo, how long will it take samsung to ship this new driver and push the update?
Validation Layers are part of the Vulkan SDK. You can enable several different validation layers (like object lifetime, parameters checking etc.) or one default-debugging layer which combines several other validation layers (standard validation). And when You enable them and execute any Vulkan application, layers start checking if everything is done according to the specification and print warning or error message in standard output. If You forget to destroy Vulkan objects (or if they are not automatically destroyed with vulkan.hpp's Unique Handles) then they will also print information about that.
Free sample of the Vulkan Cookbook available on Amazon has a paragraph about enabling Validation Layers.
In the free sample of the "Vulkan Cookbook" available at Amazon You can see a chapter about enabling validation layers. I hope this will be help enough for You ;-).
C++ is hard, mostly because while it's newest features make life easier, there's too damn many of them!
Use libgen.io to download helpful textbooks like the latest edition of C++ Primer, Effective STL, and Effective Modern C++. These can rapidly get you up to speed, and will help you leverage the best of the new C++11/14/17 features!
constexpr
is a great example, as #define
is a bit ambiguous on the exact type of a defined variable: constexpr
makes your constants compile-time constant ("baked" into the executable, usually), and gives you strict typing.
edit: if you'd like more input, I can certainly give a deeper look into your code to help give you more pointers on important C++ features you should try to leverage. I just didn't want to seem too critical :)
I personally also recommend this: http://www.opengl-tutorial.org/ I learned OpenGL 1.x some years ago and there were great changes with the release of OpenGL 3.0/3.3! These tutorials helped me refresh my knowledge and to close the gap to the newer stuff!
If you like books I could also recommend you this http://www.amazon.de/OpenGL-SuperBible-Comprehensive-Tutorial-Reference/dp/0321902947/ref=sr_1_1?ie=UTF8&qid=1433392715&sr=8-1&keywords=opengl+bible . It has it's weaknesses, but it's a good addition to other sources!