Well, that didn’t last long. Kid reclaimed the GPU, his backup one fried. I put the old one back in my machine, uninstalled the new drivers, but something is keeping the old one from doing better than one port, 1024x768…
Sooo, just ordered a GIGABYTE GeForce GTX 1660 Ti OC 6G 192-bit GDDR6, arrives Thursday…
I think there is a typo. It should be 4090 instead of 1660 
Tyranny of the budget… 
hehe i would not do that. i’m sure there are processing options/user interactions that are dear to you and not supported by vkdt.
it’s similar to dt, it saves a sidecar .cfg file along with the input image (as well as a folder-wide vkdt.db with colour labels/star ratings etc).
to my defense that is stock imgui. i did not change the widgets (yet?).
sounds like an interesting project. will be slower for sure (need to copy back stuff from gpu for display and hand it through the f$^^s*^stack instead. easiest is to call system("vkdt-cli") and save the output to /dev/shm/ i suppose, compiling a library will need some adjustments to makefile and resource path detection (see above).
to tell the truth i’m not sure the 4090 will do anything for raw processing here. faster for sure, but if you’re not rendering 60fps timelapses with 40MP it’d probably not be worth the cost.
Absolutely, but it is worth the cost for gaming. Dual purpose GPU. 
Y’mean I can lose at Solitaire faster? Yay… 
Oh, no need for defense, you’re dealing with and old command-line fool here, had never seen that arrangement before. I’m actually in awe of what you’ve accomplished, with a build process that’s so simple to boot.
Actually, I was thinking of the exported image. I’m noodling around with a suggestion for one-off images (e.g., PlayRaws) where one might not want to bother the db; I’ll relay it when I’ve had a chance to poke at the export code.
Yeah, thinking through that on my morning walk, would be best to preserve the vkdt display in the GPU, find a way to communicate to whatever UI toolkit what’s needed to just decorate it in-situ.
I have some time now to poke through the code, as I DON’T HAVE A USABLE DESKTOP DISPLAY RIGHT NOW, but my kid’s back up and gaming… 
ah. the way i do it is to save the image to /tmp (default download location of my firefox) and then i’ll just point vkdt to that. the db code does not write the vkdt.db file if you give a single image as cmdline argument. i should probably also not write it in case you didn’t change star ratings or labels. anyhow it’s just a simple text file in a directory, it does not create a central link in an index structure or anything. vkdt’s file view is really just showing actual directories on disk, no extra database structure.
right. i think most widget libraries would be able to create some kind of gpu context. it seems qt 5.10 has some support to open a window with vulkan context, probably need to start there and code your way alongside something in src/gui/ replacing glfw on the way.
(i really have to say i’m very happy with imgui though. it’s so bloat free and simple and direct and fast… i’m certainly not going back to one of the dinosaur toolkits. and it has gamepad support! one more thing you should steal from your kid if they have one…)
Yep, that’s my kind of ‘gaming’…
geesh, finally have the whole thing put back together. Also installed a 8TB drive for the photo repository and a 5x1 card reader that still won’t read my Z 6 cards …
Here’s my hwinfo:
glenn@bena:~$ hwinfo --gfxcard --short
graphics card:
nVidia TU116 [GeForce GTX 1660 Ti]
vkdt is still just blazingly fast, and I’m figuring out more of the processing. @patdavid, @darix, could we add .cfg files to the allowed upload list so folks doing PlayRaw with vkdt could upload their sidecars?
Added! Let me know if it works ok.
No joy, not in the list that appears in the error dialog…
Nope, still doesn’t like me… Tried dragging the file here, also tried the upload button.
Confirmed. It does not like my .cfg either :-(((
How does one actually filter for this specific feature using that site?
And in the interim, any other features to look for?
HDMI-VGA dongles are going to be poor display quality and also more expensive as they require active electronics since VGA is purely analog and HDMI is digital only.
HDMI->DVI can be done with passive cables (because HDMI and DVI use the same signaling scheme) at far higher display quality. Well that’s assuming your monitor is DVI-D or DVI-I. Yes, analog DVI does exist but pure-analog DVI implementations are rare.
Since DP to HDMI cables exist that are cheap (I think there’s a backwards compatibility provision in DisplayPort for DP sources and HDMI sinks that allows for passive adapters/cables?), a DP-only card should be fine too.
Edit: WHOOPS didn’t realize I was replying to some serious thread necromancy. 
I’ve been so out of the loop that I didn’t realize the RTX 4000 series had finally launched and the future references to it were so outdated.
i always just click around wildly and never remember what i have done… not a mouse person. somehow find a device, find a specific device report, then click on features → extensions (to the right of core 1.0, core …) and then the search mask will find Float32Atomic.
nope, i didn’t use much more. there’s ray tracing if you want to play quake, and the neural network stuff depends on subgroup size of 32 and 16x16 fp16 tensor cores (but it doesn’t do anything really useful i don’t think, so you can ignore this).
OK, that clarifies; thanks.
I guess there’s no way then to search for all cards that support the feature; the interface is more for finding for drivers and supported features and such related to specific cards.
Was wanting to see non-nvidia cards that support that feature.
i see. i’m not using the atomics super excessively. the colour picker does and i think one more place where a histogram is built. the fallback code path uses stupid integer stuff (atomic compare and swap in a loop), but together with some subgroup / random thinning it performs okay as well. anyhow it’s mostly stuff you’d use in interactive sessions, not for export/plain image processing. darktable used it for some local contrast/bilateral filter which was much more of an image processing perf concern.