Vulkan, artist formerly known as glNext
category: code [glöplog]
Hm, now that https://www.khronos.org/vulkan is announced, any thoughts? I wonder if it'll impact 4k intros in any way =)
Thanks for this, been waiting to see what happens.. I remember filling out a form to guess the name and made something silly up, sad they didn't go for it :D
So it does look like a heavy Mantle influence as was predicted in some places.
I guess it'll take a while for availabilty to come through.
4k advantages? Whats up the shader, still GLSL at launch, but a pre-compiled intermediate format will follow (better for limited IP protection/obsfucation) which could also some space savings in 4ks
So it does look like a heavy Mantle influence as was predicted in some places.
I guess it'll take a while for availabilty to come through.
4k advantages? Whats up the shader, still GLSL at launch, but a pre-compiled intermediate format will follow (better for limited IP protection/obsfucation) which could also some space savings in 4ks
(man i wish this place had an edit feature)
I'm betting that mantle will go away.
Yeah, from what I've read it seems like at the moment the API is the same with different function names and AMD will just keep the DLLs available for a while until Vulkan diverges from it.
Have noticed people are already calling it Vulcan!, its going to get confusing!
Have noticed people are already calling it Vulcan!, its going to get confusing!
What about NVIDIA? Their logo is listed but they didn't say a word about it
Quote:
a pre-compiled intermediate format will follow which could also some space savings in 4ks
What are you basing this on? Seems like a pretty dubious claim, as they have NO incentive to make the compiled format small.
In case you wonder how the API looks like:
so essentially
so essentially
Code:
s/^gl/vk
^^ And those keys are right next to each other too.
No need to bet. They already said they advice devs to use DX12 or Vulkan instead.
Quote:
I'm betting that mantle will go away.
No need to bet. They already said they advice devs to use DX12 or Vulkan instead.
Quote:
I'm betting that mantle will go away.
Was it ever here? :)
Apparently today AMD is going to announce what they will be releasing from Mantle 1.0 (API reference... header files, libs, SDK?) and when...
And then they'll probably go into PR-mode and say they're now working on Mantle 2.0, which is actually Vulkan.
"Aoooow. 22 positions in a one night stand..."
Quote:
Quote:a pre-compiled intermediate format will follow which could also some space savings in 4ks
What are you basing this on? Seems like a pretty dubious claim, as they have NO incentive to make the compiled format small.
Yup quite right. I figured as it will accept SPIR-V bytecode shaders, which can be compiled (from glsl in the first phase), or for the masochistic handwritten, sounds like there's potential there.
Here's the spec. https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf
( found via http://vulkan-tutorial.com/ )
So really it'll be a diffrence between (once compressed)
glsl code + code to compile & link create program (assuming gl like setup) * bind to attributes / set uniform
vs
BLOB of spir-v data, pre-compiled or hand written + code to load it + direct mapped gpu memory access to variables used in shader (no uniform/attributes type stuff)
Quote:
What about NVIDIA? Their logo is listed but they didn't say a word about it
From the Vulkan press release:
Quote:
“NVIDIA is a strong supporter of OpenGL and we are actively engaged in the development of Vulkan,” said Barthold Lichtenbelt, senior director of Tegra graphics software at NVIDIA. “Vulkan’s focus on enabling portable, high-performance games and engines will drive cutting-edge content across the range of NVIDIA’s gaming platforms including PC, mobile and cloud.”
Quote:
s/^gl/vk
hmm, to me it looks more like s/^gr/vk
(gr = mantle's prefix)
anyway, a lot of hype going on..
it's nice that we have more modern APIs that match the hardware more closely and have reduced CPU overhead. And for sure the improved flexibility and compute integration is good.
But people sometimes seem to forget that these new APIs won't magically give you more fillrate/ROP e.g. And typical demoshit usually isn't pushing an awful lot of batches either..
it's nice that we have more modern APIs that match the hardware more closely and have reduced CPU overhead. And for sure the improved flexibility and compute integration is good.
But people sometimes seem to forget that these new APIs won't magically give you more fillrate/ROP e.g. And typical demoshit usually isn't pushing an awful lot of batches either..
@sol_hsa: My guess: It will make them 5+ks ;)
Stripping the API down to the essentials has been a long overdue move.
I do like GL but for many years I've been advocating to put all that legacy stuff in a -standard- support/utility library.
(maybe not all of it, but things like glBegin, glVertex, glRotate, .. they _are_ useful if you prototype stuff)
Stripping the API down to the essentials has been a long overdue move.
I do like GL but for many years I've been advocating to put all that legacy stuff in a -standard- support/utility library.
(maybe not all of it, but things like glBegin, glVertex, glRotate, .. they _are_ useful if you prototype stuff)
(last but not least: the intention of Vulkan is to finally get rid of the Desktop GL vs. Mobile GL|ES split. One API to rule them all!)
p.p.s.: I think the name sucks. "OpenGL" has a better ring to it, IMHO.
at least it fits the temperature AMD cards like to reach at 100% workload
Quote:
(last but not least: the intention of Vulkan is to finally get rid of the Desktop GL vs. Mobile GL|ES split. One API to rule them all!)
Wow, they figured that out only 6 years after MS showed the way? :)
Now we just need to wait another 6 years for drivers to appear.... and then we can chuck out all our old hardware, because they never get driver updates for APIs they're perfectly capable of running.
If only someone would think of putting the runtime into a shared library, interfacing with a low-level driver interface, so you can update the runtime to implement a new version of the API without requiring a driver update...
I guess at this point I don't even need to point out the bytecode-compilation thing anymore... I think you get my drift :)
Please elaborate on the "byte compilation thing" (not sure what you meant -- I don't do byte compilation)
but yea, it's amazing how long it took the major players to realize such "simple" things ;)
Number One Rule for API design: Keep it simple, stupid :D
but yea, it's amazing how long it took the major players to realize such "simple" things ;)
Number One Rule for API design: Keep it simple, stupid :D
Quote:
Please elaborate on the "byte compilation thing" (not sure what you meant -- I don't do byte compilation)
Intermediate bytecode, that SPIR-thing they introduced recently.
Direct3D has been working like that since they introduced shaders in DX8.
I can't get over how clueless Khronos is for taking THIS long to figure out why it's such a good thing to send intermediate bytecode to drivers rather than having the driver compile the whole thing.
Quote:
I do like GL but for many years I've been advocating to put all that legacy stuff in a -standard- support/utility library.
(maybe not all of it, but things like glBegin, glVertex, glRotate, .. they _are_ useful if you prototype stuff)
The thing is, all that glBegin etc. stuff can (and in my opinion should) be in user-level library, possibly even statically linked to your application. Having an open source 'legacy support' library on top of, say, vulkan, would be the way to go.
Errr... but glBegin hasn't been current in Modern Desktop OpenGL since 2.1, came out in 2006 and glBegin etc were deprecated! it was also removed entirely in GL ES 2 (2007) thasn't been used either.
So you're talk about GL features deprecated approx 8 years ago in both the desktop and entirely removed embedded versions.
To me it, it doesn't look like a huge leap to go from a Modern GL coding style to something like Vulkan. However, I have always doubted whether many desktop GL developers really stopped using the non-deprecated stuff.
I do agree that, just like what has happened with ANGLE to provide OpenGL ES over DirectX, that similar projects for both 'classic' OpenGL and modern GL could be valid to help adoption.
So you're talk about GL features deprecated approx 8 years ago in both the desktop and entirely removed embedded versions.
To me it, it doesn't look like a huge leap to go from a Modern GL coding style to something like Vulkan. However, I have always doubted whether many desktop GL developers really stopped using the non-deprecated stuff.
I do agree that, just like what has happened with ANGLE to provide OpenGL ES over DirectX, that similar projects for both 'classic' OpenGL and modern GL could be valid to help adoption.