I haven’t run into problems myself, including trying to replicate what you have tried on Windows. I have the latest GPU drivers. (studio drivers from nVidia)
One problem that sometimes would happen is if the program runs out of scratch disk memory or VRAM on the GPU. Than some of the things you mentioned happened to me in previous versions, few months ago. I don’t know if you have enough GPU VRAM and or scratch disk, but that is only thing that comes to mind at the moment, providing you have the latest GPU drivers and that drivers are not problem.
I have read that latest nVidia Drivers “game ready” drivers, have flickering issues.
Nvidia released Windows hotfix driver 536.09 to fix display flickering for some users
How to know how much VRam is needed ?
What does it depend on ? Image resolution of course, but then ?
Can this vary depending on how the image is processed ? Probably yes.
Can recent graphics cards lack vram for photolab? probably not ?
So how to evaluate this ?
Interresting topic to choose a graphic card for photolab.
Definitely. I use only studio drivers, never gaming drivers, because I prefer stability and don’t really play games. My understanding is that Game ready drivers are the same as studio drivers but prioritize support for latest game releases vs studio drivers that prioritize first of all compatibility and stability, and often are timed to be released with new software that supports some latest AI or similar technology. I think development teams at nVidia and these companies stay in touch to make sure all is running smoothly.
And if things have not changed, production drivers are tested by big production studios, and some professionnal software maker to operate smoothly and with stability.
Another problem is that with ReShape I can no longer adjust grid points using the arrow keys. I was able to get it to work once, with the mouse positioned very carefully over one of the points, but not since then.
Arrow keys started working for me again (on and off), but unfortunately ReShape broke in other ways after that, changing what is displayed on screen in a continuous loop. It’s especially delicate if I use horizon, perspective, and volume deformation correction. At one point the crop tool stopped displaying anything in the image preview, including the image. Switching images recovered that.
After playing a lot (and much ‘nonsense’ to try functions) everything was fine,
but the moment I activated ReShape again that ‘continous looping’ started … until I hit Enter. *)
Then playing again and reactivating ReShape once more – no more looping.
*)
Maybe it had to do with the GPU (NVidia GTX 1060 6GB) not being fast enough to follow computing
while the 1st reactivation.
With the image I’m working on now, enabling ClearView Plus (globally or locally) generates an internal error. Global adjustment: the image simply disappears in the viewer. Local adjustment: I get the loop between 25% and 100% zoom and the image and an internal error. Perhaps not coincidentally, I’ve already applied corrections to horizon, perspective, volume deformation, and ReShape. The outer parts of the image are blurry again, too. PL eventually crashed when I tried to adjust Chroma and Luma for a control line applying ClearView Plus. This brings me to three tickets submitted to DxO today to report four problems.
@Egregius (@MSmithy & @JoPoV) Yesterday I installed a copy of VP4 and reshaped and zoomed and while moving around the zoomed image this happened more than once. i.e. DxPL 6.11 lost the will or ability to render. This is on my i7-4790K (24GB + 1050Ti-8GB).
as I zoomed in and on another occasion when zooming had stopped as I tried to zoom out.
In all cases an ‘Esc’ returned me to the normal view.
This “feature” (the error message) also occurred on my Ryzen 5600G (36GB) with 3060(12GB) and then I finally got this to happen after much scrolling around at 350%
I’m not a developer, but I’m suspecting there is a memory leak bug somewhere. I used to get the similar problems when I would limit my scratch disk space and when DXO needed a temporary scratch disk to put the texture to draw it on screen, if it didn’t have enough disk space (scratch disk) it would give that error. Closing DXO and clearing up some space and trying again usually resolved it. So my theory is that if you have enough scratch disk space and GPU VRAM and all that, maybe its a memory leak bug, where DXO keeps on eating up memory like there is no tomorrow, and does not clear it out when its not needed. Just my theory.
@MSmithy where do you consider that scratch disk space would be!?
I didn’t seem to get the problem with some basic tests I undertook on the 5600G (new build) with PL6.5 but I may not have been persistent enough!? The 5600G is a cloned system and sorting out licence issues is proving interesting so my daily machine is still the slower and smaller i7.
The 5600G is showing 13.2GB of memory in use (of 36GB) and has a similar configuration of Boot (C:) and Boot extension (E:), both SATA SSD drives with plenty of space and most of the HDDs are identical in make and size. The old i7 also has an NVME used for the ‘Cache’ but the 5600G ‘Cache’ is held on potentially the slowest drive on the machine (which I have just changed to E:)!?
Changing the ‘Cache’ to E: (a SATA SSD) changed nothing both errors can be recreated on the 5600G albeit the “frozen” rendering takes a while before DxPL fails to render a section of the image
So we have two features which I cannot tie down to “just” the DxPL6.7.0 release!
Neither of the two machines is short of memory, neither are short of disk or VRAM. The 5600G is about twice as powerful as the i7 and the 3060 leaves the 1050Ti in the dust but I an not sure that the graphics cards are actually doing anything except displaying the image!
I checked and the only activity is from the on board graphics cards because of the way that I have connected my three monitors to my three machines (all via HDMI switches), mostly via the onboard graphics and one connection from the graphics card!!??
Not sure if that is rhetorical question, but nonetheless…
Personally, I have a SSD hard drive that I use for scratch disk, based on settings in Windows. Usually its the same disk as the Operating System, usually C drive. but you can change it to be something else. Many people use external or secondary fast SSD disk as extra “RAM” known as scratch disk.
As you have noted in your case that should not be the problem than. For me it would sometimes be cluged up by other stuff, if I’m downloading something over night and I might put it on the “scratch disk” temporally etc. In my case once I freed up the space on it, lot of similar problems with DXO did not show up. So I though maybe that is the case with you. If its not, only other thing I can think of is either driver bug or DXO bug, probably related to memory leakage.
Could it be some kind of conflict with drivers or something with on board GPU and external one? Did I understand your correctly? In my case I have older intel integrated GPU that I deactivate and use external GPU for everything. To avoid problems.
