DirectX 12 Support?

Does JMonkeyEngine support the DX12 API?

Forgive me if that question is too vague as I’m still new to game development. I’m a software engineer with years of experience working with Java and I can fully explain how I want the back end of my game to work, but am still learning how to interact with the view and the UI thread. I want to be able to do many computations in multiple threads and from the little I understand about DX12, it sounds like CPU intensive games will benefit from the new API.

So any information you guys can provide me regarding JMonkeyEngines compatibility with DX12 will be helpful.

JME doesn’t come with any directx rendering. But if i am not mistaken in the contribution repo on google code there is an implementation of directx, maybe you could use it as a start if you want to implement dx12 by yourself.

But imo, there is no point in using directx with java, the main benefit of java is being multiplatform, if you use directx you lose compatibility on everything but windows.
And i’m not aware of dx12 new features, but why you can’t just use java threads for multithreading?

To add to that in case it wasn’t clear, JME used OpenGL.

1 Like

Thanks for the replies.

I do plan on using Java Threads within my game but am worried that the amount of computation I want to utilize may be too ambitious. DX12 allows for optimization of drawing related tasks and my thought process was that a more optimized drawing and visual system would allow my decision making threads more CPU time.

Drawing (rendering?) is not done by cpu neither in opengl…

There is nothing you can do in DirectX that you can’t do in OpenGL. By using OpenGL you game will run on many devices, not only where Microsoft want to.

So, no, jME3 isn’t compatible with DirectX and I think most users don’t care or don’t want also.


Seems like a case of XY problem

Also, DX12 isn’t out yet. a beta is probably going to be available around 2016. You might end up waiting a few years for it to actually come out and be stable. Also, jME3 is more likely to support Vulkan than DX12 since Vulkan is cross-platform whereas DX12 is Windows only.


Now for a viewpoint from the other side of this question:

DX 12 is one of two new apis designed around the new GPU programming ideas pioneered by AMD’s Mantle API. The other api is Vulcan.

DX 12 is a very exciting API because for the first time it gives direct low-level access to the underlying capabilities of the GPU (both for graphics and compute). For compute in particular, for the first time we’ll have access to running multiple async compute kernels in parallel with other operations.

The big advantage of DX 12 is that it is here NOW. DX 12 is included in every copy of Windows 10, and the Microsoft dev kit includes builtin support for DX 12 TODAY.

In contrast, the people doing Vulkan have indicated that the spec will be released by the end of this year. No promises about the availability of actual implementations have been made, but generally people are expecting some time in 2016.

DX 12 and Vulkan are both very similar in design. Learning to program one will definitely contribute to learning the other.

For us JMonkey programmers it would be fantastic to get DX12 capability built in so we could start using the API immediately. Once Vulkan comes out then it will be relatively painless to move our codes over to Vulkan to gain the cross-platform benefits.

These APIs (DX 12/Vulkan) are very different from older GPU apis, and it will take some time to learn the new ways of thinking. Getting a head start on that would be wonderful.

Please do consider adding DX 12 support!

I believe this would be a huge undertaking and it would narrow the scope of the engine for DX devs to just Windows. As far as I’m aware there are no maintained DirectX bindings for Java either but I could be wrong.

On another note, I believe we will most likely be using Vulkan in JME at some point in the future though :smiley:

1 Like

One advantage of DX 12 (And Vulkan) is that they are considerably smaller/simpler APIs then their predecessors. (Simpler in terms of the number and complexity of the API calls themselves. The concepts in the new APIs will take some getting used to.)

Wrapping DX 12 will be considerably less work than, say, wrapping DX 11. Wrapping DX 12 will not be any more of a huge undertaking then wrapping Vulkan will be.

Also, due to the strong similarities between DX 12 and Vulkan, much of the work done in wrapping DX 12 will be applicable to wrapping Vulkan (once implementations of Vulkan become available).

Starting work on DX 12 now will pave the way for Vulkan in the future, and yield benefits now for those who want to tarkge Windows but still do their development in Java.

This specific task is already dooable with opengl 4.5’s compute shaders. And since multi contexts is supported since opengl 3 i think you actually can even render from multiple async threads. Sure, dx12 offers a nicer cleaner api for such tasks, but it is already here, and was here for a few years. (But nobody seems to use it actually)

The super big downside of dx 12 is that there is currently no card out there supporting it :wink: Also current gen nvidia gpus suck at async compute. badly, really really badly.

The conclusion for me is, if you intend to release the game in the next 3 years, better stick with gl4.4 or dx11.


The DX mindset tends to be entirely different from the OpenGL mindset. I seriously doubt this has changed much in the new APIs.

A huge undertaking to support only one platform on GPUs that don’t actually exist yet. Versus a less huge undertaking to support all platforms. I don’t think we’ll be adding DX12 support.

1 Like

FYI @Momoko_Fan, the main dev for renderer backend is under Linux, so I guess DX 12 will not be provided by him.

But you’re free to try to provide DX 12 backend. “Principe of OpenSource”: everybody can contribute, and everyone works on what he likes.

1 Like

FWIW, Valve and Google has already started doing work implementing Vulkan drivers on desktop and mobile platforms, there are already a couple of demo videos out there. The main point behind Vulkan is that you don’t need a new GPU to utilize Vulkan, you just need a Vulkan driver to be developed.

Also as mentioned, it is highly unlikely that any of the core devs will implement DX12, as it is Windows only.

Actually DX 12 has already been officially released, and is supported by the major card vendors (though no one vendor supports all the DX 12 features). The best current support for DX 12 is from the AMD side.

I can say this definitively because I am programming in DX 12 on AMD R9 290’s, R9 390’s, and R9 Fury’s under Windows 10 every day.

The main problem on the NVIDIA side is the sketchy support they have initially provided for async compute, though they are working on it. It’s not clear if it is just a driver problem, or a design limitation in their current hardware generation. The AMD GCN architecture has first-class async compute all the way back to the old 7970 cards. There’s a lot of talk flying around on the net right now regarding this topic.

Ok, that’s fine regarding the decision of what to support. I do however want to clear up a couple misconceptions expressed about DX vs OpenCL “mindset”.

DX 12 is a clean break from DX 11. There is not even an attempt to make DX 12 backward compatible with DX 11.

The same is true with Vulkan, and OpenGL.

Both DX 12 and Vulkan are following an entirely new philosophy which is derived from the ideas put forth by the original Mantle API that AMD put out.

Therefore DX 12 and Vulkan have a lot more in common with each other than they do with any previous generation API. There is a lot of overlap between DX 12 and Vulkan APIs because of this heritage. That’s why I say that any work invested in learning or working with DX 12 will be directly applicable to future Vulkan work.

I am also on dx 12 on a nvidia card, but as you said yourself you can’t rely on dx 12, on some cards a few features will work, on some they won’t, and on some they might work sketchy :wink: Sounds like a big nightmare since you have to write fallbacks, and probably fallbacks for fallbacks.

To the specific async compute, i know that every one speaks about, but when it comes to useful implementations i see only gpu side culling as a really performance winning topic. Currently there are only synthetic benchmarks out there designed to show the superior drawcall performance, but in most of those scene you could come away with way less drawcalls if you used some dynamic batching. (Note, GL4.5 supports already every single feature mentioned up to this point)

The other main problem i see comming is the low level access. Considering how the big players mess up the games using a high level abstraction layer i forsee a hard time for the average gamer. The low level stuff might work good on consoles where you have a single hardware environment to consider. But on PC, with gpus VRAM ranges from 1.5GB over to 2, 2.5, 3, 3.7 (pun intended), 4, 6, 8, and even 12 GB you have to optimize your memory strategies / streaming technique for every single capacity. (If you want to get the best out of each card of course)

But i might have seen already to many highly discussed topics showing the future performance but only very few of them made it to deal changing features you can actually use in games.

And then, JME is open source. Sources for dx 12 are available, so go ahead. Nothing stops you from adding support for it. At least most of the generators are able to generate the jave bindings for dx 11. Have never tried dx 12

1 Like

I’m totally against supporting Direct3D and you should wonder why JMonkeyEngine uses several bindings for OpenGL and OpenGL ES (including JogAmp, LWJGL and Android build-in APIs) and why there is no actively maintained Direct3D Java binding. Asking for DirectX 12 support would require to create a Java binding for it which is already something extremely time consuming and to write another backend in JMonkeyEngine by using this new binding whereas the rendering part of JMonkeyEngine is written with OpenGL and OpenGL ES in mind. Come down to Earth, the world won’t stop to live because of the lack of DirectX 12 support. As some other developers wrote here, it’s Windows-only, it’s less appealing. If you really want to use DirectX 12, do it yourself within JMonkeyEngine, implement the missing parts or switch to a fully Windows-only solution instead of expecting such efforts of implementation in a cross-platform 3D engine.

Supporting Vulkan is the job of those sets of Java bindings (planned in JogAmp by the way). I advise you to make some great games with JMonkeyEngine 3 as is and you’ll see that DirectX 12 isn’t absolutely necessary.

1 Like

…i see no reason at all, why would DX12 be a requirement for successful game development/finishing…if your game require careful selection of graphics API in order to execute well, then i assure you that you doing something seriously wrong…bottom line is, OGL runs everywhere(Consoles, Desktops, Mobile), so why would one spend time to work on DX12, while system is already cross platform and perform very well, far better than many commercial systems out there…to bring DX12 (or any DX variant) in to JME, is way too much work for way too little benefit, if any at all…use system as it is, it rocks and its very stable…

1 Like

By the way, the JOGL renderer of JMonkeyEngine 3 supports both OpenGL and OpenGL ES :slight_smile: