Share Code Between Instances?

[MysteryX]

Quick question. I'm creating 2 alternating DX9 engines when initiating AvisynthShader. BUT, if using several such filters, it creates 2 engines PER call.

Is it possible to share code between instances, so that if you use 5 such functions, it will still only use 2 shared engines for processing, and thus prevent memory usage from skyrocketing?

[raffriff42]

You are describing the DLL (Dynamic-Link Library). When multiple instances are created, Windows knows how to reuse the block of memory, so total memory use will not explode.
https://en.wikipedia.org/wiki/Dynamic-link_library#Memory_management

The code in a DLL is usually shared among all the processes that use the DLL; that is, they occupy a single place in physical memory, and do not take up space in the page file.

[MysteryX]

Would this work?
https://stackoverflow.com/questions/2029272/how-to-declare-a-global-variable-that-could-be-used-in-the-entire-program

[raffriff42]

The link asks about singletons-slash-global-variables, and the responses (rightly IMHO) advise caution. BTW what's a "DX9 Engine?" Do you mean a game engine, like Unity or something? If so, package it in a DLL if it isn't already.

[MysteryX]

AvisynthShader processes through a DirectX 9 engine. 2 engines per instance by default so that MT functions optimally.

[raffriff42]

Something like the Direct3DCreate9 (https://msdn.microsoft.com/en-us/library/windows/desktop/bb219685(v=vs.85).aspx) function, that returns a pointer to an IDirect3D9 interface ?

The IDirect3D9 interface accesses a singleton (https://www.gamedev.net/forums/topic/253227-getting-a-struct-from-a-singleton/) object in memory (I think) and only one such object will be created per process. Direct3D devices, OTOH (for example a screen buffer) are not singletons, and can explode your memory.

[MysteryX]

Yes I'm talking about Direct3D devices, and yes they explode the memory, ESPECIALLY in x64.

Sharing the instances when using several of them in a script could be useful. However, I don't know if the lack of destructor will be an issue.

[raffriff42]

Devices have a Release function in place of a destructor. It's a typical COM reference-counted (https://en.wikipedia.org/wiki/Reference_counting#COM) interface. When all references have Released, the object destroys itself.

Regarding sharing Devices, it's probably not a good idea. For one thing, screen buffers can become invalid at any time -- say, when the user toggles the active monitor. I would try to not obtain a Device pointer until the last possible moment, Release it as soon as possible, and be prepared for unexpected loss of any Device at any time.

May I recommend a website to you and to anyone just getting into DirectX programming, with the amusing name Drunken Hyena DirectX Projects (http://www.drunkenhyena.com/cgi-bin/directx.pl). I wrote only one basic Direct3D application (https://sourceforge.net/projects/frafstestpatt/), but Drunken Hyena got me up and running (relatively) quickly, starting from zero knowledge of DirectX.

[MysteryX]

This was true for DX9, but an updated version of it ensures the device remains valid but only works on Windows Vista and above. The code is working as-is. I'm just looking for possible ways to reduce memory usage; but it's better to just not call many different functions.

[shekh]

afaik dx9 has no concurrency within single device, you should really have just one IDirect3DDevice object.

[MysteryX]

Yes ideally only 1, or rotate between 2 gives slightly better performance. That's why I want to avoid creating more if we're using 2 separate functions in the script.