I don’t understand how
relates to
I can however imagine how this
can lead to this
Seems like it’s being reported with something 32 bit along the line. Do an online seacrh for that exact amount of GPU memory and you can learn more than I understand.
Indeed you should read messages in between (and/or around).
I agree, your summary is completely incomprehensible.
I should be in bed an not posting but need to get something done with time betwen clicks…
If you are seeing only 4GB where there should be more, it sounds like a 32-bit limitation. If you do a websearch for the exact amount you posted, you will find more information about misreported amount of GPU memory.
Guessing part of the software works in 32-bit.
I see the same with 8GB by the way (4095 in every one of those files).
1 Like
Didn’t thought about it. 32bit is so far now.
Why as operating systems change programs need to be reprogrammed to make effective use of the new norms (and clear out the old rubbish). Clearly PL is using some elements of current operating systems but appear to have put these on to the original programing. No wonder it cant make effective use of modern hardware and operating systems. Its the result of marketing needing new features rather than optimizing the basics and dealing with outstanding problems.
And for some softwares, writing everything back from scratch takes very long.
I remember softimage doing this to create XSI. It took about 4 years to write this very good software, but users and companies couldn’t wait 4 years and jumped to maya which appeared at the right time.
And now no more softimage and no more XSI.
But waiting too much to keep up to date often ends up with outdated software that can’t keep up with the latest hardwares when other softwares can …
1 Like
Which is why its such a bad idea to neglect updating basic elements of a program but just add bits to them.
1 Like
Root algorithms are big endeavors to take when you want to update. It took them several years to upgrade the Working color space which was hardcoded since DxO 4/5 era (2007 !), and was a slightly customized version of AdobeRGB (to say you are not using AdobeRGB). It was good enough for years, but along maturity came experienced users that wanted something else than just flashy sRGB files for internet. I think it is pretty much the same for processing. the DPCore instances that are launched during exports are obviously not very multithreaded. It surprises me because it seemed that even with 2 or 4 exports at the same time, I could get 100% load on my 6 cores intel 6850x, or 18 cores 10980xe, I will check and make more comparisons.
how about you switch OFF / disable all GPU in DxO PL and try to export files with all NR disabled - see if purely CPU load ( w/o AI/ML NR ) can be increased that way + try > 4 parallel processing
GPU execution units typically do not require 64 bits. I think most of them are currently 32-bits, while some registers are even smaller. For Ampere, see [NVIDIA Ampere GPU Architecture Tuning Guide] NVIDIA Ampere GPU Architecture Tuning Guide. For Ada Lovelace (e.g. RTX 40x0) it might be similar.
I will try to do that, but I am already late with our annual photo book and my wife waits for my exports :-). Kidding.
I use mainly canon R5 (45mpxels), still have some Pentax 645z (51Mpxl) files to process for some prints, some GFX100s files (102Mpxl) 1dxMark III and very recently R3. So three typologies of files : 20-24Mpxls, 45-51 Mpxl, and 100+Mpxls
Something also: I use a Eizo CG319x for my main edits and proofing work, so 4k display, and use also second 4k wide gamut Dell display for the picture selection windows. At 100% the soft has to display considerably more pixels (8Mpxl) that on a 1080p display (2Mpxls). So when I use local corrections + repair tool and alternate back and forth between the two modes it takes a lot of time and is very slow. A bit quicker with the 1dxMark III files (20Mpxls only).
I don’t know the exact details but it is a noticeably quicker when i disable OpenCL. I will make my next export with disabling the deepPrime XD support by the GPU during export to figure out.
Thank you but no more need to. I encountered it today after I had edited an automask, duplicated and inverted it, on a linear DNG exported from a stacking tool using RAW files - it felt like minutes.
Generally I edit the shots in PL and then stack. Today I was “inspired” by all the pain spoken of in relation to DNG here an thought I’d give it a go.
MAC users are reverting back to 7.1.0 (which also happens to be the latest version number for Windows on which I encountered the issue). 7.1.0 is the only one I have for Windows so I can’t try if an earlier version is better.
Also see here: "Correction Review" Keeps Sticking - #14 by User_Number_777
I am able to make it a bit slower with enough other local adjustments, but edited automasks make it really bad (It was worst with the DNG.)
I have just upgraded to 7.2 latest upgrade today, and I upgraded the nvidia drivers just after. I still have to have a full working session but in a CPU only setup (without OpenCL, RTX only for DeepPrime support)) I feel a noticeable upgrade in the responsiveness. instead of 6-8 seconds to go in/out the local adjustments mode I have 3-4 seconds now. It is better.
Still not as quick as I want but an improvement nevertheless. Has anyone similar feedbacks?
PL 6.11.0 window here (not 6.12.xx - I keep what seems to work and do not upgrade until new feature interest me - things are so volatile around here and I don’t like dangerous life … anyway not with my photo editing software) :
About 3 seconds too to create preview to work with local adjustments (just tested this now with a fresh image without any local adjustment - don’t know if this time increase when bunch of local adjustments are aplied - I think so but not sure).
45mp raw.
After a day long session of photo editing and process, I am sorry to report that what I initially thought to be an improvement did not confirm…at all. DPL 7.2 is still super slow when going back and forth local adjustment mode and with repair (rubber) mode. Adding a local (like U point) adjustment zone may take up to 7-10 seconds to display 100% ratio.
Sorry DPL Team but this is very very slow. MAJOR need of improvment.