<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="en-NL" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Hi Nir,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Thanks for suggestions!</span><span style="mso-fareast-language:EN-US">
<span lang="EN-US">Apologies for being a bit late, needed to wrap my head around FFM before responding.<o:p></o:p></span></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">In many cases I mostly followed D3D9 backend's design, so the similarities can be there. =) But there definitely is room for improvement which I
</span><span lang="EN-US" style="mso-fareast-language:EN-US">also see and </span>
<span style="mso-fareast-language:EN-US">would like to tackle before the backend reaches a "mature enough" state.</span><span style="mso-fareast-language:EN-US">
</span><span style="mso-fareast-language:EN-US">When working on 3D part of JFX I </span>
<span lang="EN-US" style="mso-fareast-language:EN-US">also </span><span style="mso-fareast-language:EN-US">saw that there is some</span><span style="mso-fareast-language:EN-US">
<span lang="EN-US">data</span></span><span style="mso-fareast-language:EN-US"> duplication happening</span><span lang="EN-US" style="mso-fareast-language:EN-US">,</span><span style="mso-fareast-language:EN-US"> especially with Light/Mesh/MeshView code. I'd
like to trim this as well, but it was not a priority yet</span><span lang="EN-US" style="mso-fareast-language:EN-US"> - I preferred to have a working code now and all sorts of cleanups or reorganizations like that can come later</span><span style="mso-fareast-language:EN-US">.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Regarding FFM - that is an interesting idea that we could explore</span><span lang="EN-US" style="mso-fareast-language:EN-US"> at some point</span><span style="mso-fareast-language:EN-US">, but I'm
not sure if we could (or even should) move </span><span lang="EN-US" style="mso-fareast-language:EN-US">all the implementation details</span><span style="mso-fareast-language:EN-US"> to Java and limit native calls to just D3D12. There are a
</span><span lang="EN-US" style="mso-fareast-language:EN-US">few</span><span style="mso-fareast-language:EN-US"> problems with that:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> - There is quite a bit of logic which integrates better on C/C++ side with D3D12, mostly due to 12's low-level-ness</span><span lang="EN-US" style="mso-fareast-language:EN-US">. Rewriting those
in Java feels like quite a bit of a task in itself, and might create more problems than it solves.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"> - Raising the abstraction from 12’s low-level approach instead of just making a “passthrough” is also something that’s quite frequently done, mostly to make the API a bit more useable
and suitable for project’s specific needs (see ex. NativeBuffer abstractifying 12’s heap types into simply data being CPU visible, or code managing mid-frame data like CommandLists, shader constants, 2D vertices etc.). This could also help later down the line
when adding potential new features, simplifying the calls made from Java side.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> - There might be some</span><span lang="EN-US" style="mso-fareast-language:EN-US"> implications related to using jextract on third-party headers that we are unsure of and would require additional
approvals before proceeding with this specific approach.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">The</span><span lang="EN-US" style="mso-fareast-language:EN-US">
</span><span lang="EN-US" style="mso-fareast-language:EN-US">most reasonable/probable</span><span lang="EN-US" style="mso-fareast-language:EN-US">
</span><span lang="EN-US" style="mso-fareast-language:EN-US">FFM use </span><span style="mso-fareast-language:EN-US">would
</span><span lang="EN-US" style="mso-fareast-language:EN-US">be to access a D3D12 backend DLL we create (so basically accessing current prism_d3d12.dll but with FFM and not JNI). But it is something that we can explore in the future, for now I think there are
more higher-priority tasks related to this backend.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Lukasz<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Nir Lisker <nlisker@gmail.com>
<br>
<b>Sent:</b> Tuesday, 15 October 2024 14:28<br>
<b>To:</b> Lukasz Kostyra <lukasz.kostyra@oracle.com><br>
<b>Cc:</b> openjfx-dev <openjfx-dev@openjdk.org><br>
<b>Subject:</b> [External] : Re: JavaFX Direct3D 12 rendering pipeline for Windows<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">This is exciting news!<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I looked at the code quickly. Here are my thoughts.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">My biggest remark is that JNI is still being used, which is being more and more restricted. Recently, Kevin announced that we will be FFM-ready, surely by the time this pipeline is released. I would like to see (and can help, having used
FFM since incubation) D3D12 being based on FFM.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This will also allow less cluttered code to be written with less effort. Consider this mess in D3D12NativeMeshView (exists in D3D9 also, not blaming you for this :) ):<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> private native void nSetLight(long ptr, int index, float x, float y, float z, float r, float g, float b,<br>
float enabled, float ca, float la, float qa, float isAttenuated, float maxRange,<br>
float dirX, float dirY, float dirZ, float innerAngle, float outerAngle, float falloff);<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">That, in a pure Java world, would be `void nSetLight(Light)` with `Light` holding all its parameters. In fact, this could make whole files that just prepare the data for the native layer redundant. At least I know this is the case in the
current D3D9 implementation.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">It might also be the case that the pointer juggling that we do currently (using `long ptr` everywhere) will not be needed because FFM does it for us (Arena takes care of the lifecycle context). However, when it comes to resource deallocation
there are many caveats, so I'm speculating here.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Another design element that I think we can get rid of is the duplication of data structures in the Java and native sides. if Java has a Light, Material, and Mesh, the native side doesn't need them in reality, but in D3D9 (and somewhat in
D3D12) it does have them. Without checking, I suspect that this duplication leads to inefficient memory usage. I speculate that it was done to minimize the number of native calls, a consideration that could be overturned with FFM. In general, a lot of the
code in C++ can be potentially moved to Java, with only the calls to DirectX being left of course.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks for this herculean effort!<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Mon, Oct 14, 2024 at 7:10 PM Lukasz Kostyra <<a href="mailto:lukasz.kostyra@oracle.com">lukasz.kostyra@oracle.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hello openjfx-dev,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">we just pushed a prototype of a new JavaFX Direct3D 12 rendering pipeline<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">for Windows to a new "direct3d12" branch on jfx-sandbox. It is more than an<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">experiment branch - we intend to fully develop the D3D12 backend there.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">We're not necessarily looking for contributions at this point, but if anyone<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">has early feedback about it or wants to try it by building it themselves,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">that would be fine. We also did not test it on a wider range of hardware, so<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">your mileage may vary. While D3D12 pipeline will build by default, D3D9<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">pipeline is still the default pick at runtime. To run anything on D3D12<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">pipeline you need to force it with ex.:<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> java -Dprism.order=d3d12 ...<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Backend supports 2D rendering (albeit with some graphical issues here and there<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">that need to be ironed out) and basic 3D rendering. Expect not everything fully<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">working yet (ex. some gradients on 2D controls are incorrect, or 3D-in-2D will<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">straight up not work) and the performance not matching D3D9 yet. Our goal is to<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">first reach feature completion and then focus on performance.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Lukasz<o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</body>
</html>