AMD has revealed an API that gives developers direct access to GPUs using ...

General Discussions
#1

AMD has revealed an API that gives developers direct access to GPUs using the GCN architecture.

Now that AMD is powering all four major gaming platforms – namely the Wii U, Xbox One, PlayStation 4 and PC – the company has finally revealed its secret weapon to bind these platforms together: the low-level high-performance “Mantle” graphics API. This will allow developers to “speak the native language” of AMD’s Graphics Core Next architecture used in modern AMD-based graphics cards and APUs.

“http://www.tomshardware.com/news/amd-mantle-api-gcn-battlefield-4,24418.html”

#2

What does that means for us? Java programmers…

#3

I thought this might’ve had something to do with GPU acceleration that they’re intending to add to Java.

I’m too busy to compare the two articles, but for anyone interested:

#4

Mu question is, how will it affect OpenGL and the future of the APIs. Could it not have been abstracted under OpenGL ?
Or maybe the cgn supported cards actually have their implementation on top of mantle but having access to the raw mantle gives additional benefits.

The information is kinda lacking or I just don’t see it.

#5

Mantle is mostly targeted at titles that will be deployed on both next-gen consoles and PC. Console developers take advantage of the direct hardware access they enjoy on those platforms and both PS4 and Xbox One have AMD hardware under the hood. Mantle will enable the reuse of the same optimized paths on the PC. Everyone else will also be able to use it of course, but I’m not sure many will.

Both OpenGL and Direct3D need a lot more work to enable low-level access to the GPU and, in any case, abstracting over the hardware differences will be hard and probably not as optimal as a proprietary API. But we’ll definitely see more work in that direction for both APIs and the gap will close.

As for Java, Mantle will be just another API to bind with JNI to. But you need to keep in mind that this will not be just another set of function pointers that, by calling them, magically increase your draw calls per second. Instead of handles, there will probably be a lot of direct pointers to GPU-specific data structures and misc buffers and it’s going to be awkward to work with in Java. The power will be great; better reuse of buffers for reduced memory/bandwidth pressure and you’ll be able to do novel things that enable new algorithms and effects. It’s just going to be horribly unnatural and unsafe to use from Java. There’s also been some info during JavaOne that the sun.* package will be inaccessible in Java 9 with Jigsaw modularization. Not sure what that means exactly yet, but it’s scary to think how we’re going to be able to deal with all that without sun.misc.Unsafe.

Anyway, AMD is obviously taking full advantage of the unique opportunity it has with so much hardware being deployed with its GCN architecture underneath. As much as I don’t appreciate proprietary APIs (see CUDA), this is a decent step towards moving the PC to the living room, which I really want to see happening. Imagine a Mantle optimized game running on SteamOS; direct GPU access on top a very lightweight platform that minimizes kernel - user space context switches. The efficiency will be awfully close to that of a console and it’d still be an open(-ish) platform.

#6

I’m a bit worried. Sun and Oracle already refused several times to provide a public API to release the native memory reserved by direct NIO buffers, they are almost unusable in performance-critical code without a mean to trigger their “destruction”.

#7

AMD are also adding new high performance OpenGL extensions as explained here.

#8

[quote=“gouessej link=topic=30855.msg286252#msg286252 date=1381176029][quote author=Spasi,post:6,topic:44368”]
There’s also been some info during JavaOne that the sun.* package will be inaccessible in Java 9 with Jigsaw modularization. Not sure what that means exactly yet, but it’s scary to think how we’re going to be able to deal with all that without sun.misc.Unsafe.
[/quote]
I’m a bit worried. Sun and Oracle already refused several times to provide a public API to release the native memory reserved by direct NIO buffers, they are almost unusable in performance-critical code without a mean to trigger their “destruction”.
[/quote]
Sorry, I forgot to follow-up on this. There’s been additional info on Unsafe specifically. It’s going to be cleaned-up and move into the official JDK in Java 9. It’s obviously too popular to kill.

I’m not sure what kind of trouble you’re having with buffer deallocation. Have you tried using a large buffer as a memory pool and using .slice()d buffers out of it? Also, direct buffers are simple wrappers around Unsafe.allocateMemory() and Unsafe.freeMemory(). Why not use those directly and construct the ByteBuffer instances out of the pointer .allocateMemory() returns?

#9

As I understand it there are moves to getting “structs” into Java at some point, so there’s hope it’ll be useful for someone yet. Of course the idea of writing to the metal (and indeed, only AMD’s metal, at that), is kinda useless to most people who aren’t building bespoke hardware and software solutions. Even a console writer would be loathe to bother because it means a lot of extra effort for a minimal performance gain and then having to ignore it all anyway when the inevitable PC port (read: Steambox) comes along.

Cas :slight_smile:

#10

I’m a bit worried. Sun and Oracle already refused several times to provide a public API to release the native memory reserved by direct NIO buffers, they are almost unusable in performance-critical code without a mean to trigger their “destruction”.
[/quote]
Sorry, I forgot to follow-up on this. There’s been additional info on Unsafe specifically. It’s going to be cleaned-up and move into the official JDK in Java 9. It’s obviously too popular to kill.
[/quote]
Thanks. I feel better now. Where can I get some more information about those public APIs? We’ll have to use different code paths depending on the Java version but as long as it works, it’s ok for me.

In some cases, it is difficult to plan how much native memory I’m going to use when launching my applications, I can vaguely estimate that but my own code isn’t the only one to use the native heap. I often use the direct NIO buffers obtained from the public API and I use Oracle/Sun/Apache proprietary API only to destroy them. Most of the direct NIO buffers that I use are created by third party libraries, I can override a mechanism to get them and destroy them quite easily but using Unsafe.allocateMemory would require some modifications of the architecture and some maintainers don’t want to expose any API to release the native memory (it has been a source of debates for JMonkeyEngine 3 and I handle that in my own code for Ardor3D).

This might be interesting ;D

#11

I don’t think there are any details yet. Just tyus morning I came across this link in /r/java:

http://mail.openjdk.java.net/pipermail/discuss/2013-October/003162.html

#12

Yesterday’s presentation: AMD Mantle Technical Deep Dive. There were two more but those are not available publicly yet. No code was shown either, but it’s still a nice abstraction layer above the hardware; it won’t be much more code than using OpenGL. Highlights:

  • Multi-vendor and multi-platform. Obviously it’ll start as AMD and Windows 7/8 only, but it’s not tied to any of that. They’re hoping it will become an industry standard.
  • It completely eliminates CPU bottlenecks. An FX8350 underclocked to 2GHz can drive an R9 290X with no loss in frame rate. They claim a FX8350 is just as fast as an i7-4770K.
  • They’re targeting 100k draw calls (compared to the 3k-10k cap today). RTS games with 3000 units on screen, 25000 discrete objects simulating and moving.
  • Explicit multi-threading. Basically your application’s threads are the rendering threads, there’s no threading at the driver level. This is a huge deal considering Java’s concurrency features.
  • Multiple threads, driving multiple command queues, executing on multiple GPUs. Full application-level control, multi-GPUs will be able to get to 90%+ scaling. Can do AFR, SFR or your own custom scheme.
  • GPU page table remapping exposed. Used to implement AMD’s Partial Resident Textures, can now be used however you like.
  • Generalized resources, everything is either “memory” or “texture”. Usage hints are gone (and so is driver behavior unpredictability as a result), you now explicitly tell the driver how you’re using a resource and when that usage changes. The driver then handles low-level details like flushing, compression/decompression, etc. When you do have to stall, you can control when it happens and that it happens only once.
  • New binding model that’s as flexible as bindless, but without complicating the shaders.
  • Monolithic pipelines. You build (almost) all state in advance, binding is done without validation. Some state is left out of pipelines, to avoid combinatorial explosion (they profiled existing engines to determine which state should be left out).
  • Pipeline serialization, which includes pre-compiled shader code, for low start-up times.
#13

I use and prefer nvidia so do half of the market so having it implemented into major online games would cause large issues on pcs without AMD technology.

#14

It’s a valid concern, but I think you missed the first point in my post:

[quote]Multi-vendor and multi-platform. Obviously it’ll start as AMD and Windows 7/8 only, but it’s not tied to any of that. They’re hoping it will become an industry standard.
[/quote]
I intentionally mentioned it before everything else. It’s very important that both AMD’s Mantle and Nvidia’s G-Sync are to be open (or at least licenseable) and eventually become industry standards. Unlike, say, Nvidia’s CUDA and PhysX.

#15

Do you know how one programs the GPU with Mantel, GLSL or something new?
What is with all the low level rasterization stuff(stencil, depth, blending …) just a copy from OpenGL or something new?

#16

[quote=“Danny02,post:15,topic:44368”]
They did not say (unless I missed something). I don’t think it’s going to be something new though. I did read something about HLSL last month and they should easily provide GLSL extensions if necessary. Also, @grahamsellers mentioned OpenGL extensions that will provide Mantle-like functionality & performance.

[quote=“Danny02,post:15,topic:44368”]
Yes, such standard GPU features are identical across all APIs. Depth-testing and blending were actually mentioned in the presentation as two pieces of state that are not included in the monolithic pipelines.

#17

More details in these slides: Mantle for Developers (Frostbite, DICE)

edit: more slides: How Mantle Changes the Game (Nitrous, Oxide)

#18

Q&A with developers, very interesting stuff.

Info from past couple of days: There is a validation layer on top of Mantle which is “indeed extremely important and very valuable. also makes it significantly easier than on PS4” according to DICE. Seems AMD is taking profiling, debugging and integration with other tools (e.g. PerfStudio) very seriously.

#19

Issue is though they could use different apis and could have bugs with individual processes meaning the languages would be different on both.

#20

You do know that all those systems don’t use the same language, correct?