looks good
now you have fedora rpms.
it works. Can we do something about Ubuntu 20.04? I could try to compile it with Vulkan sdk.
i dont want to provide a custom vulkan sdk package for this. and the default package in ubuntu is too old. especially as i dont know how much else of the stack would need updating to make the new vulkan features actually work on 20.04
awesome, thank you both!
well IIRC we set the vulkan-headers to >= 1.2.162 because hanatos was using a function that was only part of that release. for testing I enabled >= 1.2.131 but there might be runtime problems.
15.3 fails with missing VkAccelerationStructureKHR
same for ubuntu 20.04 . so you must have updated the vulkan headers on your 20.04 machine.
I only installed the LunarG Vulkan SDK for Ubuntu 20.04 from here:
https://vulkan.lunarg.com/doc/view/latest/linux/getting_started_ubuntu.html
yeah cant use that in the OBS build
I think something is not 100% correct with jpeg export resp conversion to srgb.
This is saved as jpg directly from vkdt, it’s a bit too blueish:
This was created by first saving it is pfm in vkdt, then opening it in Gimp and then saving it as jpg from there. It’s more reddish or less blueish.
And this is how the photo looks in vkdt - on my screen it looks identical to nr. 2:
that does look odd. will try to reproduce once i’m back at a computer.
also have some ui changes to the colour module to make it easier to deepen the blue in your skies… but don’t think i even pushed yet.
1 Like
PC100291.ORF (20.7 MB)
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Here is the raw so maybe it’s easier to reproduce. I did nothing special, as you can see in the screenshot I played around a bit with the zones module and probably changed something in the curve module and the white balance. I noticed this some time ago. It’s best visible in winter landscapes. Maybe this won’t be easy to fix, but I think I just had an idea for another test.
This is the commit for the ui change in the color module, right?
I noticed it, but didn’t test yet. Will test soon.
Can you please make a release or make the changes in a different branch or something for some time?
thanks for the file, i think i have an idea.
nah, that’s not the commit i mean, i don’t think i put it on github yet.
sure, can tag a release and put more wacky things aside on a branch for a few weeks.
Attempt to run vkdt on another machine (debian sid, 16GB ram, Geforce GTX 1050 2GB, nvidia-driver 470.103.01)
[rawspeed] load /media/DataD/Documents/Images/Photos/2020/2021/20211218_Ipoema/20211218_Ipoema_016.NEF in 67ms
[qvk] error VK_ERROR_OUT_OF_DEVICE_MEMORY executing vkAllocateMemory(qvk.device, &mem_alloc_info, 0, &graph->vkmem)!
[ERR] running the graph failed (VK_ERROR_OUT_OF_DEVICE_MEMORY)!
Just after launching vkdt, it works once with some 12 Mpixels RAW, the next time I get back the above message. Same message for any bigger RAW. Works with jpgs.
Anything I could try to make it work ? TIA.
try running vkdt -d mem to see your peak rss whether the image is actually too large (i doubt it).
also run nvidia-smi to see whether you have other processes consuming a lot of memory (blender, bloaty desktop environment, xorg, firefox with a lot of tabs, …?).
1 Like
Thanks hanatos.
Here is the nvidia-msi result (a bit just for 2GB) after having tried to open an image twice (as if the memory ws not freed):
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 470.103.01 Driver Version: 470.103.01 CUDA Version: 11.4 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|===============================+======================+======================|
| 0 NVIDIA GeForce ... On | 00000000:01:00.0 On | N/A |
| 0% 46C P0 N/A / 95W | 1874MiB / 1997MiB | 0% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=============================================================================|
| 0 N/A N/A 866 G /usr/lib/xorg/Xorg 190MiB |
| 0 N/A N/A 1538 G cinnamon 47MiB |
| 0 N/A N/A 3879 G ...b/thunderbird/thunderbird 122MiB |
| 0 N/A N/A 4127 C+G ./vkdt 1394MiB |
| 0 N/A N/A 4181 G ...b/firefox-esr/firefox-esr 113MiB |
+-----------------------------------------------------------------------------+
Before opening a folder:
|===============================+======================+======================|
| 0 NVIDIA GeForce ... On | 00000000:01:00.0 On | N/A |
| 0% 51C P0 N/A / 95W | 1557MiB / 1997MiB | 0% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=============================================================================|
| 0 N/A N/A 866 G /usr/lib/xorg/Xorg 194MiB |
| 0 N/A N/A 1538 G cinnamon 56MiB |
| 0 N/A N/A 3879 G ...b/thunderbird/thunderbird 119MiB |
| 0 N/A N/A 4181 G ...b/firefox-esr/firefox-esr 147MiB |
| 0 N/A N/A 4613 C+G ./vkdt 1032MiB |
+-----------------------------------------------------------------------------+
Here is vdkt -d mem (the 2 first for double-click, sorry, and the last one reopening the same image):
[mem] images : peak rss 0.101562 MB vmsize 0.101562 MB
[mem] staging: peak rss 0.101074 MB vmsize 0.101074 MB
[rawspeed] load /media/DataD/Documents/Images/Photos/2020/2021/20211218_Ipoema/20211218_Ipoema_016.NEF in 107ms
[mem] images : peak rss 484.523 MB vmsize 502.348 MB
[mem] staging: peak rss 120.369 MB vmsize 120.369 MB
[rawspeed] load /media/DataD/Documents/Images/Photos/2020/2021/20211218_Ipoema/20211218_Ipoema_016.NEF in 190ms
[mem] images : peak rss 176.922 MB vmsize 187.769 MB
[mem] staging: peak rss 23.6631 MB vmsize 23.6631 MB
[mem] images : peak rss 0.101562 MB vmsize 0.101562 MB
[mem] staging: peak rss 0.101074 MB vmsize 0.101074 MB
[rawspeed] load /media/DataD/Documents/Images/Photos/2020/2021/20211218_Ipoema/20211218_Ipoema_016.NEF in 70ms
[ERR] running the graph failed (VK_ERROR_OUT_OF_DEVICE_MEMORY)!
With larger images the thumbnail fails once out of two:
[mem] images : peak rss 341.812 MB vmsize 361.562 MB
[mem] staging: peak rss 46.7915 MB vmsize 46.7915 MB
[pipe] could not open config file '/media/DataD/Documents/Images/Photos/2010/2018/20180502_Roussillon/20180503_Roussillon_043.NEF.cfg'.
[rawspeed] load /media/DataD/Documents/Images/Photos/2010/2018/20180502_Roussillon/20180503_Roussillon_036.NEF in 371ms
[ERR] [thm] running the thumbnail graph failed on image '/media/DataD/Documents/Images/Photos/2010/2018/20180502_Roussillon/20180503_Roussillon_036.NEF.cfg'!
interesting, thanks for posting the output. maybe the graphs that compute the thumbnail images cause this. i keep them around initialised, and also two of them, so i can generate thumbnails more quickly. i may have to do this differently for low memory systems.
Without firefox and thunderbird, I can open the 12Mpx images but not above, and not at every vkdt session, as if the memory was fragmented.
i think what happens is that the graphs keep their memory allocations around just in case. this is normally a very good idea, if you’re working on 1000s of images of the same camera in one folder. the thumbnail processing will be identical, the resource allocation can be done once.
so it’ll depend on whether you just load the bc1 thumbnails from disk, or whether your run of vkdt has to compute these first (requiring more memory). i suppose you can try to lower the LOD in the gui when working with larger images for now.
i certainly don’t want to compromise speed for better support of older hardware, so i’m afraid there is no easy fix. it’ll rather have to be something like: detect low memory hardware, switch to thumbnail computation in single thread, free all resources immediately, don’t allow thumbnail generation when working in darkroom mode.
After chasing all the mitigations to handle 32-bit architectures (toolchain, half-float, etc.) in rawproc, I ditched it to concentrate on the important thing, image processing. I don’t have a lot of customers, (well, any, to my knowledge…), so it’s not as big a concern as yours, but at some point you need to decide if it’s important enough to to handle all the extra work, including the regressions in the additional logic… especially important if your mitigations will include alternate processing logic, depending on such things as low memory…
FWIW…