I have noticed that unlike previous versions, the 8.2.1 update has stopped removing the core task and releasing its memory on WIndows 11 Pro. I usually watch memory usage and processor usage in the task manager while running with DeepPRIME and DeepPRIME XD/XD2s and after an export is completed, the Photolab core task used to disappear but with 8.2.1 it remains and holds on to several GB of ram. As a work around I have been killing the core task after it completes the export and that seems to work ok but I am wondering if there might be a bug in the 8.2.1 build 847 release. Are any others seeing this behavior?
Jim
@Jim_S I have been testing exports and have noticed that GPU memory is not freed up after an export has completed.
This is a PL7 run (on a GTX 1050Ti card)
versus a PL8.2.1 run (on an RTX 3060 card)
Until PL8.2.1 is terminated
This is PL7.11 running the same benchmark as PL8 above and the GPU memory use if less and there is only a small amount of GPU memory freed at the end of the export
The chart shows PL8.2.1 GPU usage versus no DxPL versus PL7.11.1 running a 10 image export, then running with no export before starting a 60 image export with a slight decrease in GPU usage after the export is completed.
I noticed the differences a lot more on the GTX 1050 Ti runs, DP XD2s annihilates the GTX card!
PL8.0 and PL8.1 didn’t exhibit this but PL8.2.1 does. Something changed in the latest update - at least on my system.
May I suggest you report this to DxO via a Support Request … They might not be aware of the issue (?)
1 Like
I can confirm this issue.
After export on HD with all four denoisers GPU hangs on 10-15% GPU load with PL 8.2.1 which was not the case with former releases.
NVIDIA driver:
566.03-quadro-rtx-desktop-notebook-win10-win11-64bit-international-dch-whql.exe
DXO support request issued.
2 Likes
@Jim_S Sorry I didn’t get all the info last night so this is after a short 10 image export from PL8 and 3 copies
BUT this this is after the equivalent export run with PL7.11.1
i.e. no difference !
So I switched to my old i7-4790K which has PL7.10.0 installed and started an export there with 2 copies and got the following during the export (edited with tidier outputs from the rerun)
and this after the export had completed
So the new behaviour is a “feature” of PL7.11.1 and PL8.2.1.
So my lack lustre differences which I remembered as more dramatic from some tests I conducted a few days ago were because of the change in behaviour between PL7.10.0 versus PL8.2.1 (earlier tests) and PL7.11.1 versus PL8.2.1 conducted last night!
PS:- I haven’t touched PL7.11.1 since I wrote the above and this is its current state i.e. unchanged and with the extra processes still running.
Great minds think alike John, I actually submitted a support ticket before coming to the forum. The initial response I got was to try to reinstall the release, which I did and it didn’t change anything. I was wondering if others were seeing the same thing or if there was something unique about my computer setup. If others report the issue it may get some attention. Thanks to those who have (winnie_pooh).
Jim
1 Like
@Jim_S A standard response, how many faults are actually fixed that way only DxO Support know.
I have submitted a fault report along the lines I detailed above, i.e. that the problem is not in PL7.10.0 but is in PL7.11.1 and PL8.2.1.
However, after an export with PL7.11.1 which left 3 export processes running I did another export with 3 export processes and PL7.11.1 appeared to reuse the previous 3 processes which were still running and were left running again after the export.
Then I increased the export tasks to 5 and PL7.11.1 started with a new export worker and added to that until all 5 workers were present but at the end of the export those export workers vanished!?
A repeat of that test did the same thing, as the 5 workers became redundant (the run was only for 10 images) they were closed one by one!?
Reverting to 3 for another run and all 3 were left running after the export completed!!
So work that one out.
"A standard response, how many faults are actually fixed that way only DxO Support know. " the old one was delete the database as the cure all. Again only they knew how well that worked and clearly that one can’t be used now for most users.
As a workaround to what problem?
Initial export on PC requires several seconds to initialize but next exports start much quicker, partially because DopCore processes are already there. OS and Apps start to free memory if needed (if memory management is designed “properly”), so don’t worry. Actually this is an obvious, standard way to make app run quicker. I would guess many users wanted it to work this way.
1 Like
@Wlodek But it has never been a standard way to do it and it only saves a little time at the start of the process!? It has merit for those users who use exporting to make up for the lack of a proper full image viewer in the product where keeping an export worker on “standby” would minimise the time but then introduce it as a feature not as an inconsistent bug and one that users can control.
Yes it might have small benefits but as my test showed with 5 copies it is not a new standard way of processing because that continues to do it the “old” way.
The “old” way works this way, as the first image is being exported DxPL starts 1 export worker, when that one has finished it then starts 2 workers for the next two images, as one of those finishes it starts an additional worker and continues this way until all workers are running, 3 in my first test and 5 in my subsequent test, overkill for 10 images but …
As it then runs out of images to process at the “other end” it starts to close workers until they are all gone or rather that is the way that it has always worked @DxO_Support-Team.
My original concern was less about main memory but rather GPU memory and that was what I reported in my first post here but I thought I had seen both heavier GPU memory usage with DP XD2s versus DP XD (which is correct) but that memory was not being relinquished at the end of the export, i.e. another manifestation of the problem reported here as it turns out
So I had seen the lack of GPU memory release but had not seen the export workers left running, holding on to system memory and GPU memory.
But when I repeated the test neither PL7 nor PL8 seemed to be releasing much GPU memory at all, i.e. because the workers stacks (sorry processes) were still running, as per this topic.
But my earlier tests were with PL7.10.0 (old method of releasing processes) versus PL8.2.1 (new “faulty” method of not releasing export processes, sometimes) and my new tests were with PL7.11.1 versus PL8.2.1 both of which have the “fault”.
@Wlodek If it a new way of doing things it may help a little with the next export but in the meantime it clutters up the machine and takes memory that is not going to be available for other activities plus it doesn’t appear to have been implemented consistently!?
It is either an unannounced “feature” but incorrectly implemented or someone has been “fiddling” with the code and made a mistake and you know which one I believe it is!
If you want to know how much memory is involved then look at my post at Has anyone noticed 8.2.1 doesn't delete core task after processing - #7 by BHAYT and do the sums!
PS:- In my book any unannounced feature is a bug.
1 Like
After restarting PL 8.2.1, the GPU load fluctuates between 5-20% using RTX4000 and Intel(R) UHD Graphics 630.
The load curve looks like a sawtooth curve.
As soon as the two PL windows are minimized, the GPU load drops to 5-7%.
After maximizing the two PL windows, the GPU load is up to 5-20%.
These two tasks seem to be responsible for the GPU load.
Once the two PL windows are minimized, the GPU load of these two tasks seems to disappear and other tasks use the GPU within 5-7%.
Given the above, I’m no longer sure if this particular behavior should be considered a bug.
It looks more like a feature. Once PL windows are maximized, the base load of 5-20% on the GPU is used to process all user interactions with the UI without delays and allow smooth operation of the software.
But that is only usfull if you use PL all the time. If every few days its locking up resources as will only be cleared with a reboot. If every program left running segments you could be in problems
The question is whether this is an intentional design or rather an unintentional design error.
Especially Lightroom, Photoshop, Luminar Neo, Affinity Photo but also DXO Viewpoint 5 and DXO FilmPack 7 do not show this behavior when inactive.
So the question remains, what does DXO expect from this particular programming technology if the rest of the industry can cope with 0% GPU load on NVIDIA graphics cards when inactive?
It is not a green technology, but rather unnecessary power consumption that is noticeable in the electricity bill and battery life.
1 Like
@winnie_pooh But the behaviour is not consistent, i.e. we have export workers left running with 3 copies but closed down tidily with 5 copies running so which is right and which is wrong, which is by intent and which is by error?
Given the way that it has always worked suggests that closing has always been the norm then anything other than that is a fault and if it is to be introduced as a feature then users should be given the option to select which behaviour they want, the “old” way or the “new” way.
Currently we have both, according to my test results!?
@John7 as far as I can tell it is cleared when the product is terminated but not before depending on the number of export copies selected.
@winnie_pooh Its a bug because it is not consistent in its behaviour plus it increases the long-term system and GPU memory footprints unnecessarily.
PS:-
The dip at the start of the 5 copy export is DxPL shutting down the remaindered export processes left running after a 3 copy run before starting the standard process as normal (ramping up the export copies) and then terminating normally at the end.
System memory usage is high because I forgot to terminate the Ramdisk again!!