PL6.10.0 maxing out the processor on Win 10 when working on an image

,

Well I’ve just finished working though 400 RAW images and then exporting them as JPEGs using PL 6.9 without any of the CPU maxing out performance issues I was having with PL 6.10, and the export times were what I’ve been used to. So for me it;s further confirmation that there’s a problem that’s been introduced in the development of 6.10.

1 Like

@SAFC01 I am glad you have a workable system, even if it meant going back to an earlier release. Hopefully that one can be identified and fixed.

My case was not a problem I typically encounter, it happened when browsing a particular image and its 4 VCs but with DeepPrime acceleration set to ‘CPU only’ and the image had DP XD set.

I just tried it on the 5600G with the 3060 card and the problem is present on the PL6.7 release. Because the machine has a processor roughly twice as powerful as the i7 it can cope somewhat better but this is what Process Lasso was showing

Please remember this is PL6.7 and just browsing the image with DP XD selected and 'DeepPRIME acceleration = ‘Use CPU only’!!

Hopefully no-one is experiencing that particular issue and I would suspect no-one is because the settings I was using are just weird, but then so is the problem!!

Nothing that signifcant to report other than I’ve had an initial response from DxO support asking me copy a file to the PL logs folder (which presumably triggers a more detailed log to be written), install the latest version of PL6 (i.e. 6.10 Build 284), use PL to trigger the problem, and then send a couple of the logs files.

With PL6.10 the CPU utilisation hit 100% each time I selected a different image in the filmstrip in PhotoLIbary (never going into Customise mode at all), and an export also took longer than usual. As soon as I reverted to PL6.9 the problem disapperared.

@SAFC01 So the same problem as mine except that taking my image to another machine (actually accessing the same image via the LAN) with PL6.7 the problem was still present but in your case PL6.9 appears not to have the same issue

You are correct that the file you were asked to copy triggers specific logging to help diagnose the problem.

see also → Exporting to disk takes extremely long with DeepPRIME XD - #44 by Barbara-S

@Wolfgang Thank for the “heads-up” I had seen that already, however, while I believe that the problems may be related to the two active topics

to name but two!?

This is slightly different and DxO have support requests from both of us, plus additional trace details in the logs!

One issue is that with my image I had problems with PL6.7 but for @SAFC01 “just” going back to PL6,9 fixed the problem!?

I don’t like “weird” differences like that @Barbara-S.

Bryan,

This looks like it might be a valid explanation of my problems with PL6.10, although it suggests the issue was first introduced in 6.9, whereas I’ve found 6.9 Build 267 works fine The description of the symptoms seems to match my experiences pretty closely.

https://forum.dxo.com/t/new-plv6-9-0-build-267-is-very-slow-compared-to-former-version/34567/11?u=safc01

@SAFC01 Paul it may be the reason for the many instances where the product seems to have reverted to the CPU and ignored the GPU, however my personal testing of exports, excluding my “rogue” image, all worked fine and they were on 1050 (2GB), 1050Ti(4GB) and RTX 3060(12GB).

My GTX1050 is particularly small with only 2GB of memory and yet the timings on that system, a near identical system to the GTX1050Ti(4GB) with the same CPU (i7-4790K), the same memory 24GB, similar SSD boot drives etc. etc. but different motherboard manufacturers and different graphics cards were a bit slower (1050 versus 1050Ti) but inline with expectations!

However, it certainly looks like the culprit or a culprit for many. It would be a culprit for mine only if the attempted allocation of GPU memory occurs early in the process, plus I believe I saw the exact same problem on my Ryzen 5600G with the RTX 3060 on PL6.7!?

Excluding that image I mostly escape unscathed but if it fixes your problem and the exporting problem of other users then that would be a very good thing!

Bryan,

As discussed in the thread below, the hotfix seems to correct my problem.

https://forum.dxo.com/t/new-plv6-9-0-build-267-is-very-slow-compared-to-former-version/34567/18#:~:text=2m-,Cecile%2C,Paul,-Reply

1 Like

@SAFC01 Paul I am glad it has fixed your problem and I believe that it will fix the problems of a number of other users who have been experiencing export issues, which is excellent @Cecile-C.

However, my “rogue” image is still a problem

Twin peaks one for the [M]aster and one for VC[1] and a processor fan going like it was trying to take off, all my machines run with there left (as I face them) side off!

So the good news is that a number of users have found new life in DxPL, with their existing systems, the bad news is that I have an image and/or a selection of edits that cause problems on my machines!?

Regards

Bryan

PS:- a reminder, green curve is processor utilisation and red is system responsiveness.

Bryan,

Are you saying, that this problem only occurs on a single image and that it is not repeatable with other images? If that is correct, have you shared this image with anyone else to see whether they’re having the same problem with it?

Mark

1 Like

@mwsilvers I have shared it with DxO support who cannot reproduce my problem but managed to produce another problem when they applied additional edits!?

This image currently causes problems of varying degrees on PL6.7, PL6.10.1, PL7.0.2 BUT in an atypical situation which I discovered by accident when trying to determine how long exports take with only the CPU selected for Noise Reduction.

It occurred while the various PL6.10 export issues were being reported which I could not reproduce on my three machines and the I set the 'DeepPRIME acceleration to ‘CPU only’ but had DP XD selected for the images.

This is PL6.10.1 just browsing each copy in turn and the graphs peaks look short in duration because Process Lasso stalled completely on each of the 5 copies!

This is 7.0.2 just browsing the [M]aster image and it did not seem to stall completely at any point

This is the image and DOP

P1102011.xmp (935 Bytes)
P1102011.RW2.dop (50.6 KB)
P1102011.RW2 (23.1 MB)

I will take a look at it myself, if you don’t mind. Is it possible that there is a corruption in the raw file or one of the sidecar files? It’s interesting that you are only having problems with this specific file. That’s happened to me one time in the past and had never occurred before or since. I don’t worry very much about one-off problems like that. Life is too short.

Mark

Just tried PL 6.10.1 and it actually makes the situation much worse for me and my setup. Rather than taking an age to export it now crashes PL on every single export. PL6.7 beckons again.

@mwsilvers Be my guest but remember that this setting is important


followed by a restart.

I believe that other images in the same group were suffering problems but I have focused on the one that caused a problem so bad that it was immediately apparent!

It doesn’t worry me that much but if the problem is more widespread or it actually points to another fundamental problem with the design/coding then it would be good to have it fixed!?

Just repeated the test on the Ryzen 5600G, about twice the processor power of the i7-4790K, on PL6.7 and got this for just moving from copy to copy of the image!

Basically the simple act of browsing from one image to another is consuming nearly all the power of the processor, there is a “buzz” loop built into the software, intentionally or unintentionally and it affects all three of my systems with this rather “odd” combination of ‘Preferences’ and assigned Noise Reduction options.

Have you reported this to DxO?:
https://support.dxo.com/hc/en-us/requests/new

Bryan, why are you looking for problems?

DeepPrime as well DeepPrimeXD need the GPU – so excluding it doesn’t make sense.
Or do I not understand what you are looking for?

@Wolfgang I typically find many of the problems I encounter by accident, that doesn’t change the fact that they are “faults” but it does change the urgency for a need for a fix.

This particular problem came about because of all the reports of increased export time for DP/DP XD with the PL6.10 release. When I tested the various scenarios I had not such problem and reported that fact in the various topics but that just meant I had no problem not that there was no problem.

I guessed that DxPL was happy enough with the slower/older GPU cards but when it came to the actual export the GPU was not being used and @Cecile-C has now indicated why DxPL “downgraded” the GPU and used only CPU.

But at the time of the reports I decided to see if my system would reflect my “hunch” if I set the ‘Preference’ to ‘CPU only’ and tried to test but before I could even get to the export stage my processor maxed out and the machine was “unusable”!

This “unusable” symptom was reported by other users who experienced the export problem but when the export is working correctly there are peaks of CPU and GPU but there is typically the possibility to continue editing while such an export if taking place.

In the case I discovered and reported to DxO Support the system maxes out and is essentially unusable, even my 5600G has a stuttering mouse during the display rendering, way before any attempt to further edit or export the image!!

Given the number of times I have reported my timings I am well aware of the absolute need for a GPU when it comes to exporting images with DP or DP XD. But the problem I have encountered as far back as PL6.7 involves an image of mine, which with ‘Preference’ = ‘CPU only’ and edit=‘DP XD’ yields an unusable machine when just browsing an image - WHY!?

I don’t like mysteries!

If it is restricted to my one image (and DOP) and the peculiar configuration then maybe it is not important.

But all my years supporting mainframe systems taught me that you ignore weird incidents at you own peril!

When an operator told me about an odd message on the ODT (Operator Display Terminal) I did not dismiss it, I started an investigation into where it came from and why and was it a warning about something potentially significant!

My customer’s systems ran 24/7/365(366) they only stopped when agreed between all elements of the customers organisation and our engineering and software support teams. We took every and all strange incidents as potentially significant until proven otherwise or the system crashed, whichever came first!!

Did I say that I don’t like mysteries!

PS:- I took a new image with minimal edits, ‘Preferences’ = ‘CPU only’ on an i7-4790K 1050Ti(4GB) and set DP XD and PL6.10.1 maxed out the processor such that processor monitoring software simply could not collect statistics during the thumbnail and screen rendering!!

Using a stop watch it took about 26 seconds for the system to become usable again after just selecting the image. Changing the choice to 4600 (the i7-4790K in built GPU) still seemed to cause a problem when the system restarted but after that it appeared to be fine.

Returning to CPU only and the problem returned, a restart was made between each such change.

… feels like DPXD is being applied during edits, even though this should not be the case.
→ What happens if you set HQ instead of DPXD and switch to it only before export?

@platypus It sort of does and I can get the symptoms to return if I adjust the Noise Reduction preview window, i.e.

  1. ‘CPU only’
  2. select DPXD image (latest test was on new images a few without DP XD, then 1 DP XD and the rest left unedited)
  3. When the chaos subsides select ‘Customize’, navigate to ‘Denoising Technologies’ and move the preview window and the machine freezes, mouse movement impossible for a short period of time.

However, late last night/earlier this morning I removed all edits (except DP XD) from the image and the problem vanishes, I tried deleting edits from the image one by one and the problem occurs each time but vanished when the last edit was removed!

The time taken to do such tests is ridiculous so which edit causes the problem or whether any edit sends the product down a “rabbit hole” I don’t know!

I did an export test a few minutes ago by selecting 5 images with one DP XD image in the middle of the group and responsiveness was interrupted but mouse movement was mostly possible as shown by this section of Process Lasso output

The time taken was most of this as you would expect

image

Whenever DP XD is selected then chaos resumes. This is two images, one with no edits and then one with edits, just after DP XD has been selected

The second pair of peaks look OK but actually Process Lasso was frozen out of the processor so could not record the graph!

Here is the same images plus a third with the GPU “correctly” selected in ‘Preferences’ after a restart

image

I am still a little concerned about “Edits + DP XD” but that is an issue for another day.