Hi Marius,
Thanks for checking. You can get D3D12 to inform you which GPU was used by
adding “-Dprism.verbose=true” to Java properties on launch. You should see
something along the lines of:
=======8<=======
…
OS Information:
Windows version 10.0 build 26100
DXGI Adapter Information:
Intel(R) Iris(R) Xe Graphics
Device ID: ven_8086, dev_46A6, subsys_0B0B1028, rev_0000000C
Device Memory: VRAM 8000000 System 0 Shared 3EE1D3000
D3D12 Device Information:
Intel(R) Iris(R) Xe Graphics
Feature Level: 12_1
Shader Model: 6.7
vsync: false vpipe: true
=======8<=======
You can also cross-check it with D3D, that same property should print similar
information from D3D9.
The only reason I can think of as to why the integrated GPU is sharing some
work despite running JFX on discrete GPU is the way these hybrid systems are
sometimes designed. A lot depends on where the display physically connects to
in the computer, for example on laptops it is a common strategy to wire the
screens and HDMI directly to the iGPU and if dGPU is needed the driver
implicitly clones drawn frames to iGPU’s memory for presentation on the screen
at a cost of some extra work and latency. Some laptops have a way to switch
over the HDMI and integrated display output directly to dGPU, but this is
mostly on the more expensive higher tier gaming laptops and requires some
tinkering in BIOS. Tower PCs can have similar symptoms if displays are
connected to motherboard HDMI/DP ports (which wire to iGPU) instead of dGPU
ports.
In short, unless you use a tower PC and your HDMI/DP cable is connected to the
wrong port I wouldn’t worry about that shared usage that much. If devices
listed by D3D and D3D12 are matching and what you expect them to be, both D3D9
and D3D12 use the same GPU. I think it’s more probable that the problem is, as
I like to sometimes call it, “between the chair and the keyboard” of whoever
wrote the backend. ;) It is highly probable the Nvidia results are viable,
because we did see low and similar performance on discrete GPUs both here and
from others who sent over the results.
Regardless, having two benchmarks would be handy, as long as both of them have
the D3D9 baseline run on the same GPU. The initialization process should be
identical between D3D9 and D3D12 (I essentially wrote it based on D3D9, but
with D3D12/DXGI API) so whatever applies to D3D9 should also apply to D3D12 -
if it doesn’t let me know.
-Lukasz
From: Marius Hanl <[email protected]>
Sent: Thursday, 27 November 2025 21:40
To: Lukasz Kostyra <[email protected]>; [email protected]
Subject: [External] : RE: RE: JavaFX Direct3D 12 - Call for performance testing
help
Hi Lukasz,
I started testing today and noticed that my laptop isn't using the discrete GPU
at all.
So I looked around in the NVIDIA Control Panel and found a setting that
apparently automatically selects the GPU for the application.
The discrete NVIDIA GPU is used for games, while the internal AMD GPU is used
for JavaFX, but also my browser, for example.
When set to use the discrete NVIDIA GPU, he still seems to somewhat share the
work between both GPUs when doing the benchmark.
In my case, I can see 40% utilization for the NVIDIA GPU and 15% for the
internal AMD GPU.
I wonder if I should do two benchmarks: One with the NVIDIA GPU set, and one
where it is not used at all as described above?
And if yes, is there something I need to check for my scenario?
-- Marius
Gesendet: Freitag, 14. November 2025 um 15:10
Von: "Lukasz Kostyra"
<[email protected]<mailto:[email protected]>>
An: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Betreff: RE: JavaFX Direct3D 12 - Call for performance testing help
Hello all,
I got feedback on the previous call for performance testing email that, instead
of using the Bash test script on Windows (and hoping you have Cygwin/MINGW
installed) it would be easier to integrate testing and CSV output functionality
into RenderPerfTest. I made those changes and they are now available on
jfx-sandbox direct3d12 branch (you WON’T find those on main repo yet):
https://github.com/openjdk/jfx-sandbox/tree/direct3d12/tests/performance/animation/RenderPerfTest/src/renderperf<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/tree/direct3d12/tests/performance/animation/RenderPerfTest/src/renderperf__;!!ACWV5N9M2RV99hQ!NACLMPpZKSbTmGhcTtK5jc1rvnIok9sbUdoWjrM6f2va7sR0xDJAwUJbK2RRMBf8vCcZhUaUwsfTjWkJxOQkU0fc$>
Any feedback regarding RenderPerfTest will be updated on that branch
automatically, so it’s indeed a better solution if there’s more feedback to it
:)
New steps for running tests:
1. Download RenderPerfTest from above link (has to be jfx-sandbox repo,
direct3d12 branch) - best to download the entire “renderperf” folder as ZIP as
it contains extra resources needed for the test app
2. Get JavaFX Direct3D 12 build - either download the EA2 SDK from [
https://jdk.java.net/javafxdirect3d12/<https://urldefense.com/v3/__https:/jdk.java.net/javafxdirect3d12/__;!!ACWV5N9M2RV99hQ!NACLMPpZKSbTmGhcTtK5jc1rvnIok9sbUdoWjrM6f2va7sR0xDJAwUJbK2RRMBf8vCcZhUaUwsfTjWkJxIRm1EHi$>
] or build it from scratch from direct3d12 [
https://github.com/openjdk/jfx-sandbox/tree/direct3d12<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/tree/direct3d12__;!!ACWV5N9M2RV99hQ!NACLMPpZKSbTmGhcTtK5jc1rvnIok9sbUdoWjrM6f2va7sR0xDJAwUJbK2RRMBf8vCcZhUaUwsfTjWkJxGGtC5B2$>
] branch (make sure to build with -PCONF=Release; at the time of writing this
email there is no functional difference between the sandbox repo and the EA2
build).
3. RenderPerf can be run with (underlined parts you need to fill in
yourself):
java --upgrade-module-path="<path_to_jfx_sdk>/lib"
--add-modules=javafx.base,javafx.controls,javafx.graphics,jdk.jsobject,javafx.media
--enable-native-access=javafx.graphics -Dprism.order=<backend>
renderperf/RenderPerfTest.java --output-csv -r <runs>
Where:
<path_to_jfx_sdk> - path to directory where JavaFX SDK is located (has to
be where JavaFX bin and lib folders reside)
<backend> - short-hand for which Prism backend to use
<runs> - how many times each test case should run; RenderPerf will average
FPS results from these runs
1. Running RenderPerf like above will produce
RenderPerf_results-<backend>-<date>-<time>.csv in your current directory.
Examples:
1. For D3D baseline test, run:
java --upgrade-module-path="<path_to_jfx_sdk>/lib"
--add-modules=javafx.base,javafx.controls,javafx.graphics,jdk.jsobject,javafx.media,
--enable-native-access=javafx.graphics -Dprism.order=d3d
renderperf/RenderPerfTest.java --output-csv -r 3
2. For D3D12 baseline test, run:
java --upgrade-module-path="<path_to_jfx_sdk>/lib"
--add-modules=javafx.base,javafx.controls,javafx.graphics,jdk.jsobject,javafx.media,
--enable-native-access=javafx.graphics -Dprism.order=d3d12
renderperf/RenderPerfTest.java --output-csv -r 3
Notes:
* Closing the test on warm-up stage will stop the test run early
* Similarly to the test script, RenderPerfTest defines default object numbers
at the beginning as Map<String, Integer> defaultObjectCounts which are used for
running all the tests. Similar remarks as to the test script apply - It would
be preferred to keep these numbers as-is but if needed (test timeouts loading,
or framerate on baseline D3D run is very low (below 15FPS) ) they can be
lowered, as long as they remain consistent between D3D and D3D12 runs.
Thanks once again for your help!
-Lukasz
From: openjfx-dev
<[email protected]<mailto:[email protected]>> On Behalf
Of Lukasz Kostyra
Sent: Thursday, 13 November 2025 15:50
To: [email protected]<mailto:[email protected]>
Subject: JavaFX Direct3D 12 - Call for performance testing help
Hello openjfx-dev,
Because Windows is very open hardware-wise, it is difficult to prepare the
backend for all possible hardware combinations available, especially from
performance perspective. To make sure JavaFX performance does not degrade
compared to old D3D backend we would like to call for volunteers to help
performance-test the backend. These tests will let us get a general idea on how
the backend behaves on different hardware and which areas of the backend to
focus on while moving forward with optimization effort for Direct3D 12.
At this point we tested the backend quite extensively on Intel-based integrated
GPUs and did some testing on a machine running a recent discrete Nvidia GPU. We
are primarily looking for testing Direct3D 12 backend on a system running an
AMD discrete GPU, but any hardware combinations are welcome - the more the
merrier :). Also note that these tests require a Windows machine, as D3D12
backend is Windows-only.
We run performance testing using RenderPerfTest JavaFX app located in the
JavaFX repository under "tests/performance/animation/RenderPerfTest". I wrote a
bash script to use with this app for performance-testing the backend. The
script will run all available demos on RenderPerfTest with a set amount of
objects per test, average the FPS results from each run and output the results
into a CSV file.
How to run perf tests:
1. Download the test script -
https://gist.github.com/lukostyra/bc354a5fd845b82805ffb3380caebe9a<https://urldefense.com/v3/__https:/gist.github.com/lukostyra/bc354a5fd845b82805ffb3380caebe9a__;!!ACWV5N9M2RV99hQ!NACLMPpZKSbTmGhcTtK5jc1rvnIok9sbUdoWjrM6f2va7sR0xDJAwUJbK2RRMBf8vCcZhUaUwsfTjWkJxJApdPYs$>
2. Get JavaFX Direct3D 12 build - either download the EA2 SDK from [
https://jdk.java.net/javafxdirect3d12/<https://urldefense.com/v3/__https:/jdk.java.net/javafxdirect3d12/__;!!ACWV5N9M2RV99hQ!NACLMPpZKSbTmGhcTtK5jc1rvnIok9sbUdoWjrM6f2va7sR0xDJAwUJbK2RRMBf8vCcZhUaUwsfTjWkJxIRm1EHi$>
] or build it from scratch from direct3d12 [
https://github.com/openjdk/jfx-sandbox/tree/direct3d12<https://urldefense.com/v3/__https:/github.com/openjdk/jfx-sandbox/tree/direct3d12__;!!ACWV5N9M2RV99hQ!NACLMPpZKSbTmGhcTtK5jc1rvnIok9sbUdoWjrM6f2va7sR0xDJAwUJbK2RRMBf8vCcZhUaUwsfTjWkJxGGtC5B2$>
] branch (make sure to build with -PCONF=Release; at the time of writing this
email there is no functional difference between the sandbox repo and the EA2
build).
3. Put the script in the same directory as renderperf/RenderPerfTest.java -
I usually copy the contents of tests/performance/animation/RenderPerfTest/src
into a separate directory where the script is located. The script will look in
the current directory specifically for "renderperf" directory containing a
"RenderPerfTest.java" source file.
4. Ensure nothing else is running on your system.
5. Perform a baseline test run with D3D backend:
./run_renderperf_all.sh -j <path_to_jfx_sdk> -b d3d -r 3
When the script is done, this should result in
"RenderPerf_results_d3d-<date>-<time>.csv" file. This will let us establish how
your machine performs on RenderPerf’s test cases on the old D3D backend.
6. Perform a perf test run for D3D12 backend:
./run_renderperf_all.sh -j <path_to_jfx_sdk> -b d3d12 -r 3
This should result in "RenderPerf_results_d3d12-<date>-<time>.csv" file. The
results will be used as a comparison to D3D backend.
Once you are done, reply to this email thread with details what hardware you
ran the tests on and with contents of both CSV files specifying which came from
which test run - I’m pretty sure attachments will be stripped when sending an
email to the mailing list, so to make sure the results get to us you should
paste them inline. Also, include the console output of running any JavaFX app
on D3D12 backend with "-Dprism.verbose=true".
Note that these tests will run for quite a bit of time. Each test case's single
run will take 15 seconds - 5 seconds of warm-up and 10 seconds of actual test
run where FPS is measured. Testing every single case, 3 runs each, for a single
backend takes approximately 40 minutes - ensure your computer won't lock or
turn off the screens during that process.
Test script reference:
./run_renderperf_all.sh -j/--jfx <path_to_jfx_sdk> [-b/--backend <backend>]
[-r/--runs <runs>]
Where:
-j, --jfx - required; path to directory where JavaFX SDK is located (has
to be where JavaFX bin and lib folders are located)
-b, --backend - optional, defaults to "d3d12"; short-hand for which Prism
backend to use. Whatever is set here will be forwarded to "-Dprism.order"
property.
-r, --runs - optional, defaults to 3; how many times each test case
should run. Script will average FPS results from these runs.
Notes:
* Closing currently running test during the warm-up stage (first 5 seconds
since starting the execution of the test case) should stop the test script
early.
* Script starts by declaring an array of test cases and object counts to run.
We recommend leaving those as they are, however if there are tests which do not
load because of a "Timeout" message (the script will then exit early) or
perform significantly worse on D3D backend (below 20 FPS) you can lower the
object count and retry.
Let me know if you have any problems with running the tests. And, in advance,
thanks for your help!
Regards,
Lukasz
