Want to use DirectX 12 [DX12] for GW2? Here's a guide on using the D912PXY on Windows 10

[Mack.3045]

> @"TheQuickFox.3826" said:

> https://github.com/megai2/d912pxy/issues/318

> Posted

 

Megai has patched this fix for you.

 

https://ci.appveyor.com/project/megai2/d912pxy/build/artifacts

[TheQuickFox.3826]

> @"Mack.3045" said:

> > @"TheQuickFox.3826" said:

> > https://github.com/megai2/d912pxy/issues/318

> > Posted

>

> Megai has patched this fix for you.

>

> https://ci.appveyor.com/project/megai2/d912pxy/build/artifacts

 

Yes, yes! I already got it installed and running.

[Quadeard.8457]

Hi guys. Not sure were I should drop my question so I try here (were else?).

I'm running D912PXY + some other addons trough GW2 Addon Manager, as well as GShade. All this works perfectly.

 

My problem is that I'm unable to game capture or window capture GW2.exe with OBS Studio. Capture screen is blank, then sometimes OBS crashes. The only way is screen capture, wich is annoying.

**Can anyone successfully capture GW2.exe with d912pxy + GShade trough OBS ?**

[Mack.3045]

> @"Quadeard.8457" said:

> Hi guys. Not sure were I should drop my question so I try here (were else?).

> I'm running D912PXY + some other addons trough GW2 Addon Manager, as well as GShade. All this works perfectly.

>

> My problem is that I'm unable to game capture or window capture GW2.exe with OBS Studio. Capture screen is blank, then sometimes OBS crashes. The only way is screen capture, wich is annoying.

> **Can anyone successfully capture GW2.exe with d912pxy + GShade trough OBS ?**

 

Hi, that would be an issue with OBS specifically and how it hooks into what's being rendered. I'd jump on the d912pxy discord channel and ask there. Otherwise ask the guys who author the OBS software.

Good luck!

[KrHome.1920]

> @"Quadeard.8457" said:

> Hi guys. Not sure were I should drop my question so I try here (were else?).

> I'm running D912PXY + some other addons trough GW2 Addon Manager, as well as GShade. All this works perfectly.

>

> My problem is that I'm unable to game capture or window capture GW2.exe with OBS Studio. Capture screen is blank, then sometimes OBS crashes. The only way is screen capture, wich is annoying.

> **Can anyone successfully capture GW2.exe with d912pxy + GShade trough OBS ?**

OBS has several conflict issues. The one you are experiencing might just be another one.

 

https://obsproject.com/wiki/Known-Conflicts

[dandamanno.4136]

> @"Ashantara.8731" said:

> > @"Mack.3045" said:

> > I'd jump on the reshade discord channel and check there

>

> So you are telling me that everyone on here who is using ReShade is doing so _without_ a "Skip UI" option? :o The text labels are so blurry, it's unbearable to the eye.

 

This is a bit late but I made my own UIMask .PNG file and replaced the blank one inside the "reshade-shader/textures" folder. You can use a program like GIMP (GNU Image Manipulation Program, these forums block the acronym :s ) and import a screenshot from the game, and then paint over the areas that you use for your static UI elements in white, and the rest of the image in black (I may have the colours reversed). It was tricky but with some tutorials using GnuIMP I found online I got it done.

 

Then while in game you set "UIMask-Top" at the top of the active effects you don't want to affect your UI, and UIMask-Bottom after said effects.

 

https://github.com/crosire/reshade-shaders/blob/master/Shaders/UIMask.fx

[Quadeard.8457]

> @"Quadeard.8457" said:

> Hi guys. Not sure were I should drop my question so I try here (were else?).

> I'm running D912PXY + some other addons trough GW2 Addon Manager, as well as GShade. All this works perfectly.

>

> My problem is that I'm unable to game capture or window capture GW2.exe with OBS Studio. Capture screen is blank, then sometimes OBS crashes. The only way is screen capture, wich is annoying.

> **Can anyone successfully capture GW2.exe with d912pxy + GShade trough OBS ?**

 

Hello guys. I solved my problem !

OBS uses BitBlt capture method for the game capture or default window capture. This method doesn't handle hardware accelerated app. The same happens when you try to capture Chromium or Discord for exemple.

You have to capture the game with window capture and select **Windows Graphics Capture (WGC)** method. The downside is that WGC adds a yellow border to your game window (not to the stream though) and always records the cursor position. This is by design by Windows for security reasons.

[Mack.3045]

Updated original post to reflect pre-release version 2.4 and change notes.

[Polish Hammer.6820]

So i had this installed before but it was an old version and I want to update to the newest one. However the zip file I download doesn't include an installer. How do I install the latest release? Windows defender didn't remove it either. It just isn't included.

[Mack.3045]

> @"Polish Hammer.6820" said:

> So i had this installed before but it was an old version and I want to update to the newest one. However the zip file I download doesn't include an installer. How do I install the latest release? Windows defender didn't remove it either. It just isn't included.

 

Hello, i just downloaded a fresh zip of 2.4 and unpacked. The installer file is there. Not sure what is happening on your end !

[LotharAB.4963]

> @"Mack.3045" said:

> > @"Polish Hammer.6820" said:

> > So i had this installed before but it was an old version and I want to update to the newest one. However the zip file I download doesn't include an installer. How do I install the latest release? Windows defender didn't remove it either. It just isn't included.

>

> Hello, i just downloaded a fresh zip of 2.4 and unpacked. The installer file is there. Not sure what is happening on your end !

 

I don't see install.exe file in new 2.4 build as well even before unpacking it (so it's for sure not deleted by defender):

 

Edit: NVM - By mistake, I downloaded source code instead of release... :#

[Mack.3045]

Hi all. For anyone wanting to you reshade with the latest build d912pxy 2.4.1 build without issues, I recommend using the latest Gshade available here.

 

https://t.co/40fsp8fjEz?amp=1

 

 

Just select the DX12 option when installing.

 

Enjoy !

[alcopaul.2156]

so the client hooks up to DX9 which hooks up to an Interface that hooks up to DX12 libraries and from there, you do the reverse just for the client to display graphics?

 

DX9 is backwards compatible and it is assumed that old software runs fast on new software, right?

[Mack.3045]

> @"alcopaul.2156" said:

> so the client hooks up to DX9 which hooks up to an Interface that hooks up to DX12 libraries and from there, you do the reverse just for the client to display graphics?

>

> DX9 is backwards compatible and it is assumed that old software runs fast on new software, right?

 

Hi :)

 

Good question!

 

I'll give a in-depth technical explanation to answer your question and explain the mechanisms used to go from dx9>translation layer>dx12 render pipeline by using the d912pxy with GW2.

 

**Dx912pxy and the D3D12 transitional layer.**

 

**What does this do?**

This translation layer provides the following high-level constructs or components (and more) for the GW2 engine to implement in the rendering pipeline.

 

**Resource binding**

The D3D12 resource binding model is quite different from D3D9 and prior. Rather than having a flat array of resources set on the pipeline which map 1:1 with shader registers, D3D12 takes a more flexible approach which is also closer to modern hardware. The translation layer takes care of figuring out which registers a shader needs, managing root signatures, populating descriptor heaps/tables, and setting up null descriptors for unbound resources.

 

**Resource renaming**

D3D9 and older have a concept of DISCARD CPU access patterns, where the CPU populates a resource, instructs the GPU to read from it, and then immediately populates new contents without waiting for the GPU to read the old ones. This pattern is typically implemented via a pattern called "renaming", where new memory is allocated during the DISCARD operation, and all future references to that resource in the API will point to the new memory rather than the old. The translation layer provides a separation of a resource from its "identity," which enables cheap swapping of the underlying memory of a resource for that of another one without having to recreate views or rebind them. It also provides easy access to rename operations (allocate new memory with the same properties as the current, and swap their identities).

 

**Resource sub-allocation, pooling, and deferred destruction**

D3D9-style apps can destroy objects immediately after instructing the GPU to do something with them. D3D12 requires applications to hold on to memory and GPU objects until the GPU has finished accessing them. Additionally, D3D9 apps suffer no penalty from allocating small resources (e.g. 16-byte buffers), where D3D12 apps must recognize that such small allocations are infeasible and should be sub-allocated from larger resources. Furthermore, constantly creating and destroying resources is a common pattern in D3D9, but in D3D12 this can quickly become expensive. The translation layer handles all of these abstractions seamlessly.

 

**Batching and threading**

Since D3D9 patterns generally require applications to record all graphics commands on a single thread, there are often other CPU cores that are idle. To improve utilization, the translation layer provides a batching layer which can sit on top of the immediate context, moving the majority of work to a second thread so it can be parallelized. It also provides threadpool-based helpers for offloading PSO compilation to worker threads (d912pxy 2.4.1 uses a configurable PSO cache amount plus native DX12 caching at the driver level ) Combining these means that compilations can be kicked off at draw-time on the application thread, and only the batching thread needs to wait for them to be completed. Meanwhile, other PSO compilations are starting or completing, minimizing the wall clock time spent compiling shaders.

 

**Residency management (memory management)**

This layer incorporates the open-source residency management library to improve utilization on low-memory systems.

 

The other component here to consider is user hardware.

 

If someone is already CPU/GPU bound in DX9 natively with GW2 then i wouldn't expect the D912pxy to help.

The end-user also needs a GPU that supports/ is capable of rendering with the DX12 api.

 

If there's CPU/RAM/GPU/VRAM resources available/untapped, then definitely expect an uplift in performance. Ultimately, try it for yourself and see :)

 

 

[Little Howl.5231]

I've been using 2.4.1 since release - works a treat. Thanks for the technical info Mack !

[alcopaul.2156]

> @"Mack.3045" said:

> > @"alcopaul.2156" said:

> > so the client hooks up to DX9 which hooks up to an Interface that hooks up to DX12 libraries and from there, you do the reverse just for the client to display graphics?

> >

> > DX9 is backwards compatible and it is assumed that old software runs fast on new software, right?

>

> Hi :)

>

> Good question!

>

> I'll give a in-depth technical explanation to answer your question and explain the mechanisms used to go from dx9>translation layer>dx12 render pipeline by using the d912pxy with GW2.

>

> **Dx912pxy and the D3D12 transitional layer.**

>

> **What does this do?**

> This translation layer provides the following high-level constructs or components (and more) for the GW2 engine to implement in the rendering pipeline.

>

> **Resource binding**

> The D3D12 resource binding model is quite different from D3D9 and prior. Rather than having a flat array of resources set on the pipeline which map 1:1 with shader registers, D3D12 takes a more flexible approach which is also closer to modern hardware. The translation layer takes care of figuring out which registers a shader needs, managing root signatures, populating descriptor heaps/tables, and setting up null descriptors for unbound resources.

>

> **Resource renaming**

> D3D9 and older have a concept of DISCARD CPU access patterns, where the CPU populates a resource, instructs the GPU to read from it, and then immediately populates new contents without waiting for the GPU to read the old ones. This pattern is typically implemented via a pattern called "renaming", where new memory is allocated during the DISCARD operation, and all future references to that resource in the API will point to the new memory rather than the old. The translation layer provides a separation of a resource from its "identity," which enables cheap swapping of the underlying memory of a resource for that of another one without having to recreate views or rebind them. It also provides easy access to rename operations (allocate new memory with the same properties as the current, and swap their identities).

>

> **Resource sub-allocation, pooling, and deferred destruction**

> D3D9-style apps can destroy objects immediately after instructing the GPU to do something with them. D3D12 requires applications to hold on to memory and GPU objects until the GPU has finished accessing them. Additionally, D3D9 apps suffer no penalty from allocating small resources (e.g. 16-byte buffers), where D3D12 apps must recognize that such small allocations are infeasible and should be sub-allocated from larger resources. Furthermore, constantly creating and destroying resources is a common pattern in D3D9, but in D3D12 this can quickly become expensive. The translation layer handles all of these abstractions seamlessly.

>

> **Batching and threading**

> Since D3D9 patterns generally require applications to record all graphics commands on a single thread, there are often other CPU cores that are idle. To improve utilization, the translation layer provides a batching layer which can sit on top of the immediate context, moving the majority of work to a second thread so it can be parallelized. It also provides threadpool-based helpers for offloading PSO compilation to worker threads (d912pxy 2.4.1 uses a configurable PSO cache amount plus native DX12 caching at the driver level ) Combining these means that compilations can be kicked off at draw-time on the application thread, and only the batching thread needs to wait for them to be completed. Meanwhile, other PSO compilations are starting or completing, minimizing the wall clock time spent compiling shaders.

>

> **Residency management (memory management)**

> This layer incorporates the open-source residency management library to improve utilization on low-memory systems.

>

> The other component here to consider is user hardware.

>

> If someone is already CPU/GPU bound in DX9 natively with GW2 then i wouldn't expect the D912pxy to help.

> The end-user also needs a GPU that supports/ is capable of rendering with the DX12 api.

>

> If there's CPU/RAM/GPU/VRAM resources available/untapped, then definitely expect an uplift in performance. Ultimately, try it for yourself and see :)

>

>

 

I like the part that it goes multicore when rendering.

 

and by your definition, there's lots of going on with the DX12 and your interface/translation layer says it handles them all meticulously.

 

but say if the client goes DX9 -> interface/translation layer -> DX12, will the graphics rendering be from DX12 to the interface/translation layer and finally to the GW2 client?

[Mack.3045]

> @"alcopaul.2156" said:

> > @"Mack.3045" said:

> > > @"alcopaul.2156" said:

> > > so the client hooks up to DX9 which hooks up to an Interface that hooks up to DX12 libraries and from there, you do the reverse just for the client to display graphics?

> > >

> > > DX9 is backwards compatible and it is assumed that old software runs fast on new software, right?

> >

> > Hi :)

> >

> > Good question!

> >

> > I'll give a in-depth technical explanation to answer your question and explain the mechanisms used to go from dx9>translation layer>dx12 render pipeline by using the d912pxy with GW2.

> >

> > **Dx912pxy and the D3D12 transitional layer.**

> >

> > **What does this do?**

> > This translation layer provides the following high-level constructs or components (and more) for the GW2 engine to implement in the rendering pipeline.

> >

> > **Resource binding**

> > The D3D12 resource binding model is quite different from D3D9 and prior. Rather than having a flat array of resources set on the pipeline which map 1:1 with shader registers, D3D12 takes a more flexible approach which is also closer to modern hardware. The translation layer takes care of figuring out which registers a shader needs, managing root signatures, populating descriptor heaps/tables, and setting up null descriptors for unbound resources.

> >

> > **Resource renaming**

> > D3D9 and older have a concept of DISCARD CPU access patterns, where the CPU populates a resource, instructs the GPU to read from it, and then immediately populates new contents without waiting for the GPU to read the old ones. This pattern is typically implemented via a pattern called "renaming", where new memory is allocated during the DISCARD operation, and all future references to that resource in the API will point to the new memory rather than the old. The translation layer provides a separation of a resource from its "identity," which enables cheap swapping of the underlying memory of a resource for that of another one without having to recreate views or rebind them. It also provides easy access to rename operations (allocate new memory with the same properties as the current, and swap their identities).

> >

> > **Resource sub-allocation, pooling, and deferred destruction**

> > D3D9-style apps can destroy objects immediately after instructing the GPU to do something with them. D3D12 requires applications to hold on to memory and GPU objects until the GPU has finished accessing them. Additionally, D3D9 apps suffer no penalty from allocating small resources (e.g. 16-byte buffers), where D3D12 apps must recognize that such small allocations are infeasible and should be sub-allocated from larger resources. Furthermore, constantly creating and destroying resources is a common pattern in D3D9, but in D3D12 this can quickly become expensive. The translation layer handles all of these abstractions seamlessly.

> >

> > **Batching and threading**

> > Since D3D9 patterns generally require applications to record all graphics commands on a single thread, there are often other CPU cores that are idle. To improve utilization, the translation layer provides a batching layer which can sit on top of the immediate context, moving the majority of work to a second thread so it can be parallelized. It also provides threadpool-based helpers for offloading PSO compilation to worker threads (d912pxy 2.4.1 uses a configurable PSO cache amount plus native DX12 caching at the driver level ) Combining these means that compilations can be kicked off at draw-time on the application thread, and only the batching thread needs to wait for them to be completed. Meanwhile, other PSO compilations are starting or completing, minimizing the wall clock time spent compiling shaders.

> >

> > **Residency management (memory management)**

> > This layer incorporates the open-source residency management library to improve utilization on low-memory systems.

> >

> > The other component here to consider is user hardware.

> >

> > If someone is already CPU/GPU bound in DX9 natively with GW2 then i wouldn't expect the D912pxy to help.

> > The end-user also needs a GPU that supports/ is capable of rendering with the DX12 api.

> >

> > If there's CPU/RAM/GPU/VRAM resources available/untapped, then definitely expect an uplift in performance. Ultimately, try it for yourself and see :)

> >

> >

>

> I like the part that it goes multicore when rendering.

>

> and by your definition, there's lots of going on with the DX12 and your interface/translation layer says it handles them all meticulously.

>

> but say if the client goes DX9 -> interface/translation layer -> DX12, will the graphics rendering be from DX12 to the interface/translation layer and finally to the GW2 client?

 

No, the rendering pipeline is GW2 Client, Game DAT, DX9, D912PXY >DX12API - your monitor :)

[Aaron malouf.9423]

Hi, i want to install this but im worried about maybe getting a time out or possibly banned by using this. is it safe to use ?

[Mack.3045]

> @"Aaron malouf.9423" said:

> Hi, i want to install this but im worried about maybe getting a time out or possibly banned by using this. is it safe to use ?

 

Completely safe to use. ?

[alcopaul.2156]

> @"Mack.3045" said:

> > @"alcopaul.2156" said:

> > > @"Mack.3045" said:

> > > > @"alcopaul.2156" said:

> > > > so the client hooks up to DX9 which hooks up to an Interface that hooks up to DX12 libraries and from there, you do the reverse just for the client to display graphics?

> > > >

> > > > DX9 is backwards compatible and it is assumed that old software runs fast on new software, right?

> > >

> > > Hi :)

> > >

> > > Good question!

> > >

> > > I'll give a in-depth technical explanation to answer your question and explain the mechanisms used to go from dx9>translation layer>dx12 render pipeline by using the d912pxy with GW2.

> > >

> > > **Dx912pxy and the D3D12 transitional layer.**

> > >

> > > **What does this do?**

> > > This translation layer provides the following high-level constructs or components (and more) for the GW2 engine to implement in the rendering pipeline.

> > >

> > > **Resource binding**

> > > The D3D12 resource binding model is quite different from D3D9 and prior. Rather than having a flat array of resources set on the pipeline which map 1:1 with shader registers, D3D12 takes a more flexible approach which is also closer to modern hardware. The translation layer takes care of figuring out which registers a shader needs, managing root signatures, populating descriptor heaps/tables, and setting up null descriptors for unbound resources.

> > >

> > > **Resource renaming**

> > > D3D9 and older have a concept of DISCARD CPU access patterns, where the CPU populates a resource, instructs the GPU to read from it, and then immediately populates new contents without waiting for the GPU to read the old ones. This pattern is typically implemented via a pattern called "renaming", where new memory is allocated during the DISCARD operation, and all future references to that resource in the API will point to the new memory rather than the old. The translation layer provides a separation of a resource from its "identity," which enables cheap swapping of the underlying memory of a resource for that of another one without having to recreate views or rebind them. It also provides easy access to rename operations (allocate new memory with the same properties as the current, and swap their identities).

> > >

> > > **Resource sub-allocation, pooling, and deferred destruction**

> > > D3D9-style apps can destroy objects immediately after instructing the GPU to do something with them. D3D12 requires applications to hold on to memory and GPU objects until the GPU has finished accessing them. Additionally, D3D9 apps suffer no penalty from allocating small resources (e.g. 16-byte buffers), where D3D12 apps must recognize that such small allocations are infeasible and should be sub-allocated from larger resources. Furthermore, constantly creating and destroying resources is a common pattern in D3D9, but in D3D12 this can quickly become expensive. The translation layer handles all of these abstractions seamlessly.

> > >

> > > **Batching and threading**

> > > Since D3D9 patterns generally require applications to record all graphics commands on a single thread, there are often other CPU cores that are idle. To improve utilization, the translation layer provides a batching layer which can sit on top of the immediate context, moving the majority of work to a second thread so it can be parallelized. It also provides threadpool-based helpers for offloading PSO compilation to worker threads (d912pxy 2.4.1 uses a configurable PSO cache amount plus native DX12 caching at the driver level ) Combining these means that compilations can be kicked off at draw-time on the application thread, and only the batching thread needs to wait for them to be completed. Meanwhile, other PSO compilations are starting or completing, minimizing the wall clock time spent compiling shaders.

> > >

> > > **Residency management (memory management)**

> > > This layer incorporates the open-source residency management library to improve utilization on low-memory systems.

> > >

> > > The other component here to consider is user hardware.

> > >

> > > If someone is already CPU/GPU bound in DX9 natively with GW2 then i wouldn't expect the D912pxy to help.

> > > The end-user also needs a GPU that supports/ is capable of rendering with the DX12 api.

> > >

> > > If there's CPU/RAM/GPU/VRAM resources available/untapped, then definitely expect an uplift in performance. Ultimately, try it for yourself and see :)

> > >

> > >

> >

> > I like the part that it goes multicore when rendering.

> >

> > and by your definition, there's lots of going on with the DX12 and your interface/translation layer says it handles them all meticulously.

> >

> > but say if the client goes DX9 -> interface/translation layer -> DX12, will the graphics rendering be from DX12 to the interface/translation layer and finally to the GW2 client?

>

> No, the rendering pipeline is GW2 Client, Game DAT, DX9, D912PXY >DX12API - your monitor :)

 

that's pretty much the flow that i wanted to see. ;)