I was looking at SPIR-V specs and it mentions two different types of compute shaders: Compute shaders and compute kernels. The latter seem to be aimed at CL 2.x but I was wondering if they will also be available in Vulkan. From my cursory reading of the specs, it looks like the compute shaders are aimed at the current GL compute shader model and lacks powerful constructs such as dynamic parallelism (also called device-side enqueue).
With the release of the initial specs for Vulkan, what is Khronos’s position/opinion on us taking the specs and assembling a private compilation for personal curiosity and testing purposes? I have been absolutely curious about this since I heard about it, and to make it better ya’ll have given us incredible flexibility with the interoperability and structure. I’ll be honest to say I’m dying to try something, I just wanna make sure I’m not doing something I’m not supposed to. Nice work ya’ll!
You can’t call it compliant to vulkan. Before you publish you should join Khronos as an implementer. It’s free and gives you access to the conformance test suite. You can join as an adopter (for a fee) and if you then can pass the conformance tests you can advertise it as compliant to the spec using the logos and trademarks.
But to be clear the only vulkan-related spec we have available now is the spir-v spec.
The Mantle spec is property of AMD and they have different rules.
Thanks for the advice! I have already registered as an implimenter and sent in my initial conformance test, I am presently awaiting a response. I look forward to seeing what this new technology will bring with it, there are a ton of possibilities!
Happy Hacking!
I still don’t get the point of this so called “Vulkan”. There’s already AMD Mantle, Apple Metal, Direct3D 11 and the new crippled OpenGL 4.5, why add more to the list of mess? Who is going to implement it if we ever get any specification?
If I were you I would stick to improving OpenGL by removing the crap you have been adding to it since OpenGL 2.1 and work on improving display lists and context/windowing management interface. NVIDIA is doing a great job by adding low level extensions similar to what “Vulkan” or “Mantle” has. So…please don’t cripple OpenGL more.
Because only one of those is cross-platform: “the new crippled OpenGL 4.5”.
I’d ask on what basis you consider it “crippled”, but that would only derail the discussion from Vulkan. You know, the point of this thread.
Well, Vulkan is kinda like Mantle 2.0, so I’m guessing AMD at a minimum. Preliminary Vulkan implementations already exist for both Intel and NVIDIA platforms, as demonstrated during the Vulkan presentation at GDC. So I’d say the desktop space is well-covered.
In the mobile space, PowerVR, ARM, and Mali have shown preliminary Vulkan implementations. Again, at the GDC presentation. Neither Apple nor Qualcomm have stated that they will have Vulkan support, but both of them are listed among the companies helping to build Vulkan.
Furthermore, Valve is pretty dedicated to seeing this through. As are a number of game engine developers.
In short: Vulkan is happening. Whether we see it this year, or whether it beats D3D12 out to the market, or whether it beats it in the marketplace remains an open question. But one way or another, Vulkan is going to happen.
In the future, before you make declarations of this nature, you should educate yourself on what is currently known.
[QUOTE=gloptus;31223]I still don’t get the point of this so called “Vulkan”. There’s already AMD Mantle, Apple Metal, Direct3D 11 and the new crippled OpenGL 4.5, why add more to the list of mess? Who is going to implement it if we ever get any specification?
If I were you I would stick to improving OpenGL by removing the crap you have been adding to it since OpenGL 2.1 and work on improving display lists and context/windowing management interface. NVIDIA is doing a great job by adding low level extensions similar to what “Vulkan” or “Mantle” has. So…please don’t cripple OpenGL more.[/QUOTE]
All of those expect openGL are proprietary and the designers have a vested interest in not releasing the full spec or allowing others to call themselves compliant to it.
and openGL is too bogged down with legacy crap at this point to do another deprecation sweep like they did in 3.*
One of the biggest annoyances with openGL is that the driver has to assume many things to be able to get to the fast path, so much so that drivers includes game specific optimizations for popular games just to get a reasonable performance.
Clean sweep is kind of the only option to avoid legacy API calls bogging down the driver.
Also vulkan is based entirely on display lists, each command buffer is a display list that is optimized on creation on a separate thread while the main thread keeps pushing draw calls to the GPU.
So, the “crap you have been adding to it since OpenGL 2.1” would have to include such hardware features as:
- integer textures
- geometry shaders
- tessellation
- uniform buffer objects
- image load/store & shader storage buffer objects
- atomic counters
- compute shaders
And that’s only a partial list culled from off the top of my head. I could easily find more.
All of this “crap” is something retained by your vaunted NV_command_list. So NVIDIA doesn’t agree with you.
And that doesn’t mention the API niceties like:
- The ability to specify these from within shaders:
** binding indices for samplers
** locations for uniforms
** attribute indices for vertex shader inputs
** fragment shader output locations - separate programs
- interfacing variables between shaders by resource indices rather than names
- program binaries
- separation of vertex buffers from vertex formats
- a decent debug layer, that allows you to assign names to objects
- Direct State Access
This is also “crap” that NV_command_list doesn’t remove. Though obviously the debug layer isn’t quite so useful anymore.
NVIDIA is doing a great job promoting NVIDIA. NV_command_list, by design, relies on a number of NVIDIA-only extensions. And one of these, NV_vertex_shader_unified_memory, is pretty much unimplementable on some hardware. So NV_command_list is a non-starter as far as cross-platform is concerned.
NVIDIA really likes OpenGL, and they really like supporting some of the old stalwarts of the API that have the ancient, legacy codebases. For the, NV_command_list will be one more reason for them to stick with NVIDIA hardware. And that’s fine, for them.
At the end of the day, OpenGL and Vulkan are for two different groups of programmers. Some programmers need performance above all else, even cleanliness of code and their own sanity. For them, Vulkan is there. OpenGL is for programmers who need performance, but they also want a decree of safety and basic sanity, or who don’t need performance all that much.
The existence of Vulkan does not hurt OpenGL. OpenGL will continue to exist and be developed; Khronos is dedicated to this.
To be fair, that’s not the most compelling reason to have a new API. It’s much more a question of what you gain by building it off of OpenGL.
Basically, not very little. Look at NV_command_list. Your vertex setup data has to be done via NV_vertex_buffer_unified_memory. Your uniform blocks have to be handled via NV_uniform_buffer_unified_memory. Your textures must use ARB_bindless_texture. And so forth.
After all of that, what’s left that’s still core OpenGL?
- Basic state-change functions (glBlendFunci), though even those work in a different way
- Buffer/texture object creation and storage management
- Program compilation and management
- Framebuffers, though even they are heavily modified
So why bother making it based on OpenGL? At the end of the day, you’re not using all that much of the old API. So why not make a new one?
Not to mention that, even with NV_command_list, you’re still higher level than Vulkan. With Vulkan, applications have direct, low-level control over memory allocation, residency, and usage. And while ARB_bindless_texture does give you residency control over each texture, that’s going to be less efficient than having one call make an entire memory block resident. And that block could cover multiple textures as well as buffers. There’s also DMA control, explicit queues and so forth.
Lastly, by building a new API from the ground up, Vulkan gets to develop a new software stack with important features. Debugging and validation as a layer, rather than each implementation doing it themselves. You can’t really do that with some kind of OpenGL extension; it’s a part of the core functionality of the software, rather than the language.
So the Khronos clowns took AMD’s failed Mantle junk and did a search and replace on the source files to add the ‘gl’ prefix.
And then got some ten year old to come up with the laughably idiotic Vulkan name.
Hopefully the rumors are true that moves are being made to create a new team and organization to handle OpenGL development and this Vulkan fiasco dies off as quickly and quietly as Mantle did and the long term damage to OpenGL is minimized.
I think the operation was:
> cat Mantle.spec | sed -s ‘s!gr!vk!’ > Vulkan.spec # The prefix you’re looking for is vk.
Idiotic or not, it WILL dominate the industry. You may return to your home under the bridge now. 
:doh: The Vulkan prefix is “vk”, not “gl”.
You know, your insults would be more effective if they didn’t contain glaring factual errors. Granted, they’d still be laughably absurd. But at least they’d show basic competence.
Thank you for your contribution to this thread.
What rumors? The rumors you just started by declaring that there are rumors? And in what way does Vulkan “damage” OpenGL? Vulkan doesn’t replace OpenGL; Khronos has already stated that OpenGL will continue to be developed alongside Vulkan.
[QUOTE=Alfonse Reinheart;31231]
Vulkan doesn’t replace OpenGL; Khronos has already stated that OpenGL will continue to be developed alongside Vulkan.[/QUOTE]
I hope it does. OpenGL should be retired. Having one clean high-performance cross-platform API is absolutely sufficient. If someone need a higher-level API, thats what engines are for. OpenGL had a good run but after Vulkan is implemented on major platforms, it essential purpose boils down to support of legacy software. Which is not a really good reason to invest into an API.
All in all, the sooner OpenGL dies off and Vulkan gets accepted as the new graphics API, the better for open standards and cross-platform applications/games. Let’s be realistic here: almost nobody is using OpenGL nowadays for games, because its so messy to debug and does not guarantee predictable performance. In contrast, Vulkan becomes a very reasonable alternative to DirectX.
That’s not “realistic”. That’s a very desktop-focused view. Or rather, very Windows desktop-focused.
Many games use OpenGL. The vast majority of mobile games use OpenGL ES, which is no less “messy to debug” and no more likely to “guarantee predictable performance” than desktop GL. Every Linux or MacOSX port of a Windows game uses OpenGL. Desktop OpenGL. NVIDIA even brought desktop OpenGL 4.5 into the mobile space.
The only non-console place where OpenGL is not commonly being used is on Windows desktop. And while certainly a major platform for games, it isn’t everything.
The thing more likely to cause OpenGL’s “death” is the continued middleware-ization of graphics development. As engines get more commonly used, the developers using those engines don’t have to care about whether they’re using Vulkan, OpenGL, D3D12, or whatever. They just code to the engine and let the engine developers worry about the details.
Oh sure, OpenGL’s time will pass. It’ll continue to exist in some form for the benefit of ancient CAD software and the like, possibly via an open-source implementation written against Vulkan. But its eventual passing will primarily be due to the availability of solid middleware, rather than Vulkan directly.
I think you are being a little bit too strict here. All I was trying to say is that having a single cross-platform high-performance graphical library will likely improve the current state of cross-platform PC applications and game titles. OpenGL can’t do it — unless it is completely redesigned (as you have already mentioned above). Having a viable alternative to DirectX will hopefully encourage more game developers to design their PC titles with cross-platform compatibility in mind instead of sticking with Windows as primary PC gaming platform.
[QUOTE=Path_3;31229]So the Khronos clowns took AMD’s failed Mantle junk and did a search and replace on the source files to add the ‘gl’ prefix.
And then got some ten year old to come up with the laughably idiotic Vulkan name.
Hopefully the rumors are true that moves are being made to create a new team and organization to handle OpenGL development and this Vulkan fiasco dies off as quickly and quietly as Mantle did and the long term damage to OpenGL is minimized.[/QUOTE]
Exactly. Well said.
[QUOTE=Alfonse Reinheart;31231]:doh: The Vulkan prefix is “vk”, not “gl”.
You know, your insults would be more effective if they didn’t contain glaring factual errors. Granted, they’d still be laughably absurd. But at least they’d show basic competence.
Thank you for your contribution to this thread.
What rumors? The rumors you just started by declaring that there are rumors? And in what way does Vulkan “damage” OpenGL? Vulkan doesn’t replace OpenGL; Khronos has already stated that OpenGL will continue to be developed alongside Vulkan.[/QUOTE]
Why do you take it personal offence when someone gives their own opinion and views about something?
OpenGL may retire after we see “Vulkan” in action, and not only games. Computer graphics is much much more than video games.
OpenGL is not high-level API, at least not any more. Have you done any NVIDIA register combiner code?
[QUOTE=greyfox;31232]
All in all, the sooner OpenGL dies off and Vulkan gets accepted as the new graphics API, the better for open standards and cross-platform applications/games. Let’s be realistic here: almost nobody is using OpenGL nowadays for games, because its so messy to debug and does not guarantee predictable performance. In contrast, Vulkan becomes a very reasonable alternative to DirectX.[/QUOTE]
So “Vulkan” success depends on death of OpenGL? This is very promising.
OpenGL may not be the most favourable API for video games but it’s the only choice for Apple platforms, embedded graphics, mobile devices, and yeah…CAD applications!
A: I am offended by the sheer level of ignorance, sloth, and chutzpah it takes to not realize that Vulkan API calls use “vk” as a prefix, yet still loudly declare one’s opinion on the API. That offends me as a programmer; we should be better than that.
B: Opinions given by someone who can’t even get basic facts right should be discarded on that basis alone. Someone that ignorant of Vulkan is functionally incapable of giving useful feedback. If their opinion is actually valid, then they can return after educate themselves or someone who isn’t ignorant can state the opinion properly.
C: The opinion, ignoring the silly part, was not given in a respectful fashion. It was purely an emotional appeal, with no subsntative discussion of the API or the problems with it. The opinion was not defended or substantiated by any actual facts. This makes it nothing more than what “some guy on a forum” thinks.
D: The opinion is a strawman. Vulkan is decidedly not Mantle. Nor is Mantle bad.
E: Even ignoring all of that, the feedback was in no way useful to the purpose of this thread. It’s nothing more than a short rant from a guy on a forum about how Vulkan is too much like Mantle and that makes it bad for some reason that he won’t bother to explain. That opinion is without value to anyone (who doesn’t already agree with it, at which point, you’re just preaching to the choir).
There is a difference between honest dislike for legitimate reasons and some forumite raging against something he doesn’t understand. Path_3’s post was the latter. If you want to have a rational, substantive, and useful conversation on the merits of Vulkan, its relationship to Mantle, the merits of Mantle, or even the quality of the name, fine.
But you cannot say that what he posted was anything other than bile. The only reason you like it is because you agree with it, not because he presented a good case for his position.
Yes. Have you ever had to manage synchronization manually on a GPU? Have you ever had to manage GPU memory (and no, NV_vertex_array_range doesn’t even begin to cover it)? Ever issue DMAs and clear the appropriate caches so that the GPU could see the data? Ever implement the mapping of memory storage? When allocating textures in OpenGL, do you have to figure out exactly how many bytes you need for texture sizes/formats?
No? Then you’re not low-level. OpenGL isn’t high-level, to be sure. And it never was, even when it was pure fixed-function. But there is a difference between “high-level” and “higher level”. OpenGL is undeniably higher level than Vulkan.
I say this from the very bottom of my heart: screw CAD developers!
It is because of CAD developers that the Longs Peak effort failed. They didn’t want a new API, and they forced the ARB to abandon the effort in favor of the terrible “compromise” position of core/compatibility profiles. Oh sure, we’d still need Vulkan even if we had a Longs Peak-based OpenGL 3, but at least modern OpenGL would be the cleanest example of an immediate renderer out there. I have nothing but hatred for these developers, who halted an important cleanup effort just because they didn’t want to re-write some of their code.
Well tough luck, CAD developers. Because Valve, Epic, and most other game engine developers are on board the Vulkan train, and they’ve got more clout than you. You can get on if you want, but you’re not derailing us anymore. So either jump on the train or stay with your pathetic OpenGL 1.x-based immediate-mode renderers that you don’t ever want to rewrite.
You reap as you sow.
As for the rest, “embedded graphics” and “mobile devices” are already on-board with Vulkan. Oh sure, outdated ES 1.1 devices aren’t, but devices that use ES 2.0 will eventually be upgraded into devices with graphics chips that can support Vulkan.
For high-performance mobile applications, the future is either Vulkan or Apple Metal. The only question is whether Apple will support Vulkan on their systems.