<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-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">></span><span lang="EN-US">
</span>I'm not sure what you mean by this. If you mean the current sandbox code that uses JNI will need to be rewritten, then yes, that will be a rewrite, which is why I advocate to take advantage of FFM sooner rather than later. If you're mostly copying from
D3D9 then it does save some effort on the JNI side. D3D12 (or any DLL) doesn't know what's calling it, whether it's C++ or Java, so there shouldn't be a difference in "integration". At least not when I called native libraries, but perhaps I'm missing something.
I can also give a concrete example on some code snippet in our D3D9 or 12 if it helps clarify my intention.<o:p></o:p></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">I understand that, I think I had to word that poorly earlier on. My point is that 12’s hardware abstraction is much thinner compared to 9 or even 11. This exposes some inner workings
of GPUs which now have to be accommodated by the application rather than the GPU driver. Of course I don’t disagree that you can do this in Java, I suspect with proper bindings you could also write a working backend in any language you pick, no matter how
high or low level. It is just my prior experience with 12, it makes a bit more sense to handle those fully natively from C/C++ code.<o:p></o:p></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 lang="EN-US" style="mso-fareast-language:EN-US">></span><span lang="EN-US">
</span>As for what to move to the Java side, there could be a performance tradeoff between an increased number of native calls and the ability of the JIT to optimize them.<o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" 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">Regarding performance implications, it is true that this current approach reduces calls to native side, and I would even say to a quite significant margin in some cases. As an example,
take one simple nRenderQuads() call - once we internally batch enough quads and Ring Buffer for them is used up enough, it submits current Command List onto the GPU for execution. However, because D3D12 is essentially context-less compared to older D3D versions
or ES2, we need to start the next Command List by re-recording some initial GPU commands that will “restore” the pipeline before we can call another Draw. Otherwise bad things will happen, especially with Prism expecting a context-based approach in the first
place. This is all done by D3D12RenderingContext.cpp and friends.<o:p></o:p></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 lang="EN-US" style="mso-fareast-language:EN-US">The whole reason this is done is to parallelize GPU and CPU work as much as possible (although this still needs fine-tuning to truly maximize the FPS, but I digress). D3D9, D3D11, ES2
– in all these the driver does that for you, in 12 (and Metal) you have to do this on your own if your application needs to (and in our case it does). Similar situation with NativeBuffer I mentioned in my previous message - if we want to create a D3D12 Resource
that’s allocated directly on VRAM and fill it with data, we need to do a whole lot of work, including a manual GPU call to copy the data to VRAM. Simplifying it to a simple Init() call that can be called from Java side just makes sense.<o:p></o:p></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 lang="EN-US" style="mso-fareast-language:EN-US">> </span>
One of FFM's goals is to eliminate the need to create a bridge DLL like prism_d3d12. I don't know if it's technically feasible with regard to how native memory management works and because it works with C and not completely with C++.<o:p></o:p></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">Technically, D3D12 is purely a C++ API which also integrates a bit with Windows API for classic HWND handles and for synchronization with Windows’ Event Handles. I do still access it
despite JNI requiring C-style entry points, but there are some technicalities to handle with how and when you can free 12’s resources (mostly to make sure you don’t free them while GPU is still using them).<o:p></o:p></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 lang="EN-US" style="mso-fareast-language:EN-US">Again, I don’t deny that we can do all this work I mentioned above in Java. My point is, skipping the bridge DLL, while possible and might have some Java advantages, still seems like
not the most feasible approach with what D3D12 demands from the application. And there’s still the licensing side (forgot that word existed last message… the wonders of being ESL =) ) of jextract-ing D3D12 headers, which I am definitely not an expert on.<o:p></o:p></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 lang="EN-US" style="mso-fareast-language:EN-US">If we do decide to use FFM, I would rather expect using it with current structure – to access built-by-us prism_d3d12.dll and to call APIs that it exposes. But, all that is still not
a priority for this backend right now - we might take a look at it later down the line.<o:p></o:p></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 lang="EN-US" style="mso-fareast-language:EN-US">Lukasz<o:p></o:p></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 lang="EN-US" 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> Thursday, 17 October 2024 18:33<br>
<b>To:</b> Lukasz Kostyra <lukasz.kostyra@oracle.com><br>
<b>Cc:</b> openjfx-dev <openjfx-dev@openjdk.org><br>
<b>Subject:</b> Re: [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">Hi Lukasz,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Yes, FFM is quite a bit to take in. I haven't mastered the newest version myself yet.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal">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 lang="EN-US">also see and </span>would like to tackle before the backend reaches a "mature
enough" state. When working on 3D part of JFX I <span lang="EN-US">also </span>saw that there is some <span lang="EN-US">data</span> duplication happening<span lang="EN-US">,</span> especially with Light/Mesh/MeshView code. I'd like to trim this as well, but
it was not a priority yet<span lang="EN-US"> - I preferred to have a working code now and all sorts of cleanups or reorganizations like that can come later</span>.<br>
<br>
Regarding FFM - that is an interesting idea that we could explore<span lang="EN-US"> at some point</span>, but I'm not sure if we could (or even should) move <span lang="EN-US">all the implementation details</span> to Java and limit native calls to just D3D12.
There are a <span lang="EN-US">few</span> problems with that:<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Because FFM saves a lot of handwriting of fragile JNI code, the sooner it's adopted, the less headache you (or collaborators) will have. So while it's true that there's a minimal working level the code should be brought to, adopting FFM
will mean rewriting a lot of JNI code. This is why I suggest going with FFM as soon as that minimal level is reached. It has advantages in type safety and compiler checks that JNI does not have, including the ability to use objects-structs mapping instead
of breaking them down to JNI-supported primitives (long -> jlong etc.).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <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-right:0cm">
<p class="MsoNormal"> - 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 lang="EN-US">. Rewriting those in Java feels like quite a bit of a task in itself, and might create more problems
than it solves.</span><o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">I'm not sure what you mean by this. If you mean the current sandbox code that uses JNI will need to be rewritten, then yes, that will be a rewrite, which is why I advocate to take advantage of FFM sooner rather than later. If you're mostly
copying from D3D9 then it does save some effort on the JNI side. D3D12 (or any DLL) doesn't know what's calling it, whether it's C++ or Java, so there shouldn't be a difference in "integration". At least not when I called native libraries, but perhaps I'm
missing something. I can also give a concrete example on some code snippet in our D3D9 or 12 if it helps clarify my intention.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"> <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-right:0cm">
<p class="MsoNormal"><span lang="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.</span><o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'm not sure what this means either :p The abstraction that exists or will exist in C/C++ that surrounds the D3D API can exist instead in Java. It's the same abstraction level.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <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-right:0cm">
<p class="MsoNormal"> - There might be some<span lang="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.</span><o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">OK, I don't know how this works with licensing if that's what you mean. I've used jextract (and even wrote a JavaFX GUI wrapper for it) on 3rd party headers and technically didn't see many issues.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <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-right:0cm">
<p class="MsoNormal"><span lang="EN-US">The most reasonable/probable FFM use </span>would <span lang="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.</span><o:p></o:p></p>
</blockquote>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">One of FFM's goals is to eliminate the need to create a bridge DLL like prism_d3d12. I don't know if it's technically feasible with regard to how native memory management works and because it works with C and not completely with C++.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">As for what to move to the Java side, there could be a performance tradeoff between an increased number of native calls and the ability of the JIT to optimize them. There are tricks there that we could use. There will be quite a bit to
explore when the minimal working state is reached. By the way, Metal could use it too if it's not very far out, but I certainly would not replace the current ES and D3D9 code with FFM.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, Oct 17, 2024 at 5:04 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-right:0cm">
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US">Hi Nir,</span><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">Thanks for suggestions!
<span lang="EN-US">Apologies for being a bit late, needed to wrap my head around FFM before responding.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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 lang="EN-US">also see and </span>would like to tackle before the backend reaches a "mature enough" state. When working on 3D part of JFX I
<span lang="EN-US">also </span>saw that there is some <span lang="EN-US">data</span> duplication happening<span lang="EN-US">,</span> especially with Light/Mesh/MeshView code. I'd like to trim this as well, but it was not a priority yet<span lang="EN-US"> -
I preferred to have a working code now and all sorts of cleanups or reorganizations like that can come later</span>.<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">Regarding FFM - that is an interesting idea that we could explore<span lang="EN-US"> at some point</span>, but I'm not sure if we could (or even should) move
<span lang="EN-US">all the implementation details</span> to Java and limit native calls to just D3D12. There are a
<span lang="EN-US">few</span> problems with that:<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> - 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 lang="EN-US">. Rewriting those in Java feels like quite
a bit of a task in itself, and might create more problems than it solves.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="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.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> - There might be some<span lang="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.</span><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"><span lang="EN-US">The most reasonable/probable FFM use
</span>would <span lang="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.</span><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"><span lang="EN-US">Lukasz</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Nir Lisker <<a href="mailto:nlisker@gmail.com" target="_blank">nlisker@gmail.com</a>>
<br>
<b>Sent:</b> Tuesday, 15 October 2024 14:28<br>
<b>To:</b> Lukasz Kostyra <<a href="mailto:lukasz.kostyra@oracle.com" target="_blank">lukasz.kostyra@oracle.com</a>><br>
<b>Cc:</b> openjfx-dev <<a href="mailto:openjfx-dev@openjdk.org" target="_blank">openjfx-dev@openjdk.org</a>><br>
<b>Subject:</b> [External] : Re: JavaFX Direct3D 12 rendering pipeline for Windows</span><o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">This is exciting news!<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I looked at the code quickly. Here are my thoughts.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> 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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks for this herculean effort!<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Mon, Oct 14, 2024 at 7:10 PM Lukasz Kostyra <<a href="mailto:lukasz.kostyra@oracle.com" target="_blank">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>
</div>
</div>
</blockquote>
</div>
</div>
</body>
</html>