On Thu, 5 Nov 2026 14:33:48 GMT, Christopher Schnick <[email protected]> wrote:
>> ## Description >> >> This PR is for review and integration of Direct3D 12 Rendering Pipeline into >> JavaFX mainline. We released three Early Access (EA) versions of this >> implementation while keeping the development ongoing on [JavaFX >> Sandbox](https://github.com/openjdk/jfx-sandbox/tree/direct3d12) and reached >> a stage where it is ready to be integrated into mainline. Any further work >> and potential fixes will be done on mainline. >> >> At the time of writing, this PR is identical to the [JavaFX Sandbox D3D12 >> branch](https://github.com/openjdk/jfx-sandbox/tree/direct3d12) with only >> one difference - the Sandbox defaults to D3D12 backend. This PR, however, >> does *NOT* change the default rendering pipeline on Windows. D3D9 remains >> the default rendering pipeline and D3D12 is optional - it can be selected by >> providing `-Dprism.order=d3d12`. To verify which pipeline is actually in use >> `-Dprism.verbose=true` is recommended. >> >> ## Details >> >> Below are general changes introduced by the backend: >> >> ### JSL changes >> >> - Introduced `HLSL6Backend` class which translates JSL shader code into >> HLSL6 code. D3D12 introduced HLSL Shader Level 6 support and won't support >> existing HLSL shaders used with D3D9, as those are compiled for unsupported >> Shader Level 3. >> - D3D12-specific shaders are kept in >> `modules/javafx.graphics/src/main/native-prism-d3d12/hlsl6` >> - Shader compilation is done with DXC instead of FXC (FXC does not support >> SL6). DXC is bundled in Windows SDK which JavaFX already integrates with. >> - Backend also generates C++ headers with Shader resource binding >> information, used by the native-side >> >> ### Build changes >> >> - Added new build tasks for generation and compilation of HLSL6 shaders for >> D3D12 >> - Added tasks to compile D3D12 native backend code >> >> ### Prism changes >> >> - Added D3D12-specific Java classes (package `com.sun.prism.d3d12`) and a >> Java-to-JNI layer (package `com.sun.prism.d3d12.ni`) >> - Java implementation is mostly similar to D3D9 implementation, with only >> some minor changes needed to accommodate slightly different presentation >> behavior of the new runtime >> - JNI interface is relatively high level to reduce the amount of JNI calls >> for performance >> - Added a native Prism backend implementation using D3D12 runtime (stored in >> `modules/javafx.graphics/src/main/native-prism-d3d12`) >> - Written in C++ 20 >> - Uses only interfaces available via Windows API with no third-party >> libraries - WinAPI, Windows COM interface system and "bare... > > Ok yeah that makes sense. Looking at D3D12NI_DEV_RET_IF_FAILED, what happens > if the code is e.g. `DXGI_ERROR_DEVICE_RESET` instead of > `DXGI_ERROR_DEVICE_REMOVED`? I think there are several more potential codes > that the macro does not check at the moment > @crschnick Since D3D10 losing the graphics device is considered a much more > fatal and non-regular scenario than in was in D3D9. In 9 you had to actually > handle it in "standard" situations - switching windowed to fullscreen for > example would trigger it, I think also changing Stage dimensions or > minimizing/restoring the app could trigger it, then you would have to > recreate the Device and used resources. D3D9 backend in JavaFX was built to > handle scenarios like these, hence it has much more robust resource tracking > on Java-side. In D3D12 losing the device (or as 12 calls it, having your > device removed) is a tragic should-not-ever-happen situation and only comes > up if there is some sort of API use error on implementation side. In other > words, when everything is properly executed and bug-free in D3D12 there > should never be a lost/removed device that we would have to manage. I'm not sure I agree with this reasoning. A device reset can happen due to a driver update (which is a completely normal thing) or due to a device timeout caused by another application. In both cases, a graceful recovery path is better than breaking the JavaFX application permanently until it is restarted. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2346#issuecomment-6661598189
