AMD Mantle API [updating]
- Thread starter MarkoIt
- Start date
GNM is a very good API (full performance, full feature set). I don't see any reason for AAA developers to use any other API on PS4. Vulcan might be good for smaller developers porting their games from mobiles or from PC.
I'm basically thinking it just makes it easier for indie or small developers to find their way on to PS4. Maybe those people wouldn't be using a low-level API like Vulcan on the PC anyway.
Silent_Buddha
Legend
Interesting, so in a way Mantle did become open. Or at least it's progeny, Vulcan, is open. And what AMD wasn't capable of doing on its own, Khronos will hopefully be able to do.
Regards,
SB
Its good to get this confirmation right now.. I will not be surprised to see AMD having a big participation on debug tools, programming tools developpement for Vulkan.
I ask me what impact it could have on professional market for AMD when we look at the stack OpenCL, Vulkan.. ( more and more professional softwares use openCL for computing, physic simulation, raytracing, image treatment etc etc )
I even start to ask me in what position is Nvidia about Vulkan.. we dont hear them much about it. Its maybe only a feeling, but i have not seen much from Nvidia lately and DX12 ( just looking at GDC conferences panel )
Last edited:
D
Deleted member 2197
Guest
I think most players are focused on DX12 at this point, both from the hardware and software perspective. I really don't see Vulkan will have much impact on Nvidia's pre-defined goals for this year ...
Last edited:
Yes i know this, ... but strangely, since "GLnext", Vulkan, Nvidia is so silent ..Or they are so verbose in general... ( and for be honest, i get the feeling " some leader of " the old OpenGL team" are clearly out of the project " .. including him.. ( lol, why everyone want to see him lead anything when we see the result on OpenCL and other Khronos project .. who are all but not supported by nvidia lol .. This guy should have been fired fom Khronos since a good time .
its not only about this.. in professional side .. they are 100% silent on the future of professional computing side.. CUDA ? i dont even remember the last time i have see a conference with future roadmap for it..... On gaming side and embedded technology yes.... but professional side .. i dont remember have seen any annuounces from nvidia since a good while.
Last edited:
That seems be that... or they just dont care anymore to compet in professional market.. ( maybe they dont want to follow the road of IBM .. ).. For be honest, i dont really see with what they could compet software and hardware wise in this market right now.
it seems everything they have put in place is now in a big break. i hope this will change with Pascal.
GTC is in 2 weeks. I'm expecting lots of CUDA announcements then. And developers already have access to CUDA 7 (this is what I've been using, it has some nice features).
The integration of the compute and graphics domains with a common intermediate representation makes me wonder about HSA.
The placement of the HSA runtime was at a level below the OpenCL runtime, when AMD discussed how the two would relate. Even with the latest OpenCL feature set, HSA does promise certain features like exceptions, recursion, memory allocation, and function pointers that are not included.
The addition of a graphics domain to the representation in the higher levels could have some import long-term. The idea that HSA can reside below OpenCL does work best when is equivalent or a superset of the layer above. Perhaps this could be helped if what remains of Mantle dives deeper and fuses with that layer?
The placement of the HSA runtime was at a level below the OpenCL runtime, when AMD discussed how the two would relate. Even with the latest OpenCL feature set, HSA does promise certain features like exceptions, recursion, memory allocation, and function pointers that are not included.
The addition of a graphics domain to the representation in the higher levels could have some import long-term. The idea that HSA can reside below OpenCL does work best when is equivalent or a superset of the layer above. Perhaps this could be helped if what remains of Mantle dives deeper and fuses with that layer?
D
Deleted member 13524
Guest
Ashes of Singularity demo using Mantle:
Also, talks about DX12 and Mantle.
Using a Kaveri and a 290X, they claim the game's bottleneck stands on the 290X.
Also, talks about DX12 and Mantle.
Using a Kaveri and a 290X, they claim the game's bottleneck stands on the 290X.
If the Vulcan compute shaders provide all the OpenCL 2.1 compute features (SPIR-V on both), it would mean that Vulcan would become a direct competitor with CUDA. Not right away, since Vulcan starts with GLSL only. However Kronos has already discussed that C++ based shaders are something that they/partners are already investigating for the future. OpenCL 2.1 C++ SPIR-V compiler already exists, so this might happen sooner than we expect.
OpenCL 1.X and DirectCompute lacked many important features compared to CUDA. OpenCL 2.0 added most of the missing features, and OpenCL 2.1 improved those features and added C++ support. OpenCL 2.1 could compete with CUDA, but NVIDIA doesn't even have OpenCL 1.2 drivers yet, and most likely will never add OpenCL 2.x support. I just hope this doesn't mean that they skip Vulcan as well (as OpenCL 2.1 and Vulcan are so close to each other).
I am personally happy that Mantle didn't become a open API. Mantle was very important, as it pushed Microsoft and Khronos to the right direction (DirectX 12 and Vulcan). Big thanks to AMD for that. But I still remember the old dark ages, when we had to program separate support for each hardware (3Dfx Glide, S3 MeTaL, etc). I don't want to go there again. Vendor locked APIs (such as Mantle and CUDA) are good for hardware iteration and prototyping when standard APIs do not exist. CUDA was also very important for GPU compute evolution in general. But it is starting to be the time to embrace open standards in the compute side as well. OpenCL 2.1 seems excellent, and Vulcan seems great as well. And Microsoft added asynchronous compute to DX 12 (and possibly many other compute improvements that are not disclosed yet).
Last edited:
k, not c. 
I don't know, OpenCL still (I believe) doesn't support join wrt dynamical parallelism, only fork. That's not trivial to implement on the API side and limits many use cases. I suspect there's still a gulf in (working) features, tools, documentation, etc. between CUDA and OpenCL.
But in general, it's not clear to me that OpenCL can compete with CUDA (or that it really should). APIs like CUDA are absolutely needed for various markets in HPC. Often you aren't targeting a broad range of hardware, just a select few. In those situations it makes little sense to use APIs like OpenCL. I'm not suggesting that CUDA > OpenCL, but no matter what happens with OpenCL/DirectCompute/etc. I still think there will be a need for CUDA.
I agree on graphics (mantle) though since there's not many use cases where you're only targeting a select few GPUs (save for consoles, which in general also don't use higher level apis).
But in general, it's not clear to me that OpenCL can compete with CUDA (or that it really should). APIs like CUDA are absolutely needed for various markets in HPC. Often you aren't targeting a broad range of hardware, just a select few. In those situations it makes little sense to use APIs like OpenCL. I'm not suggesting that CUDA > OpenCL, but no matter what happens with OpenCL/DirectCompute/etc. I still think there will be a need for CUDA.
I agree on graphics (mantle) though since there's not many use cases where you're only targeting a select few GPUs (save for consoles, which in general also don't use higher level apis).
The AMD blog post was written before the Khronos press release, and furthermore was written before the Khronos NDA was moved. The 5th is a placeholder; AMD has nothing further to announce that wasn't already in the blog post and the Vulkan announcement.
Jawed
Legend
Yeah, it's pretty obvious, Vulkan is effectively cross-platform, vendor agnostic Mantle. Will anyone bother to enumerate the bits of Mantle lost in Vulkan or the generalisations and improvements in Vulkan over Mantle? Seems unlikely.
More interesting will be a comparison of D3D12 and Vulkan. I got the sense from McMullen's D3D12 presentation that Microsoft has more heavily iterated to get to the ExecuteIndirect model and perhaps one or two other things - but that's just a feeling, no actual evidence, happy to be shot down, etc.
I have to admit D3D12 is actually exciting. I'd hate to be a developer who's within a year of release as I'd totally want to junk D3D11/9 right now, tired old shite. I'm also hopeful that 12 really is the last D3D ever. Let MS iterate on feature levels, but otherwise, the next stop after this is a pure compute model, in my view.
Vulkan might actually be closer to that, as it's on the cusp of a single model for all kernels (courtesy of SPIR-V) that can access any GPU functionality, fixed or compute, in a single kernel. Pixel shaders with dynamic parallelism?... That should get the juices flowing.
More interesting will be a comparison of D3D12 and Vulkan. I got the sense from McMullen's D3D12 presentation that Microsoft has more heavily iterated to get to the ExecuteIndirect model and perhaps one or two other things - but that's just a feeling, no actual evidence, happy to be shot down, etc.
I have to admit D3D12 is actually exciting. I'd hate to be a developer who's within a year of release as I'd totally want to junk D3D11/9 right now, tired old shite. I'm also hopeful that 12 really is the last D3D ever. Let MS iterate on feature levels, but otherwise, the next stop after this is a pure compute model, in my view.
Vulkan might actually be closer to that, as it's on the cusp of a single model for all kernels (courtesy of SPIR-V) that can access any GPU functionality, fixed or compute, in a single kernel. Pixel shaders with dynamic parallelism?... That should get the juices flowing.
In the sense in which slicing an artery gets some juices flowing, that's a completely true statement.