Support forum for DG Tools

Frozen until the next 1000 frames.
(and a cheap reference to Disney's Frozen) (I'll let it go now)

OK, It should be so fast that it is more of a tiny pause than a freeze.

admin wrote:I have uploaded the revised 2048 with support for sm_11 and beyond. It should support the cards you mentioned. I don't think there are any sm_10 cards that matter. Correct me if I'm wrong about that.

EDIT: You can see which cards we lose here:

http://en.wikipedia.org/wiki/CUDA#Supported_GPUs

We lose:

GeForce GT 420*, GeForce 8800 Ultra, GeForce 8800 GTX, GeForce GT 340*, GeForce GT 330*, GeForce GT 320*, GeForce 315*, GeForce 310*, GeForce 9800 GT, GeForce 9600 GT, GeForce 9400GT, Quadro FX 5600, Quadro FX 4600, Quadro Plex 2100 S4, Tesla C870, Tesla D870, Tesla S870

Too bad, so sad.

Yikes, I thought DG that you still had a 9600GT as me... I guess I have to dig-out the 520 that was glitching somehow early on and that I pulled and put-into a drawer some time ago (you had a problem too iirc), or pop for a 750Ti?

laserfan wrote: Yikes, I thought DG that you still had a 9600GT as me... I guess I have to dig-out the 520 that was glitching somehow early on and that I pulled and put-into a drawer some time ago (you had a problem too iirc), or pop for a 750Ti?

I still have the 9600GT lying in a closet, but not installed in any machine. The 520 glitches are gone with latest drivers.

The cards I run now are:

460
520
620

I hope to get a 750 Ti in not too long.

I posted about the CUDA compatibility issues at the nVida forum:

https://devtalk.nvidia.com/default/topi ... rsion-6-5/

admin wrote:I posted about the CUDA compatibility issues at the nVida forum:

https://devtalk.nvidia.com/default/topi ... rsion-6-5/

Has devtalk been responsive to you in the past? Regardless it's a good try.

I can't get too worked-up about losing 9600 support since your tool works perfectly for me as it is. But you'll clearly need to put a LOOK OUT BELOW! notice on future releases (and still it will sail past a lot of folks I suppose).

I haven't posted there before. We'll see. I could try my contact at nVidia, but in previous discussions he has lamented the lack of backward compatibility for previously compiled CUBINs and I suspect there is nothing he can really do to help, so I don't like to bother him unnecessarily. The posting was intended to notify nVidia that they make serious problems for people with this new precedent (this is the first time they have removed support for an architecture). If there is a solution or it makes them think twice about it, well, that would be fantastic.

If things get really bad, I always have the option to remove the CUDA NV12 -> RGB24 conversion and replace it with a CPU version (like we had in build 2021). Then I am dependent only on CUVID and all the problems go away. The conversion is only required for display in DGIndexNV and so is noncritical. Also, modern CPUs are so fast that not much is really gained by using CUDA for it. If I pull that off, it will be possible to add back support for the obsoleted cards. I could even get fancy and do CPU conversion only on the cards that won't run the CUDA conversion.

My indexing test result for NVIDIA 9600GS; sample file is .m2ts with 61'729 frames:
v2047: 58 sec
v2048: 56 sec

That's hard to understand as I and others saw much more significant speed gains for M2TS.

Scratching my head as well. That's why I posted ....

Edit:
I repeated the test with a much larger file on different drives. Same result, no significant speed improvement with 2048.
I did all the tests with the 32bit binary. I'll try with 64 bit now....

Edit2:
64bit binary makes no real difference.

It seems that the speed is capped by the HD I/O

Maybe you have a slow hard drive and it is masking the code improvements.

How big is the file that took 56 seconds and what is the video type?

File size: 3.87 GB
#Frames: 61'729
Video type: AVC

My PC does a 4.2GB AVC M2TS in 18 seconds. So I guess your disk IO is seriously deficient. You may want to look into that.

Exactly. Benchmark testing with my conventional HD indicates 70.....80 MB/s read or write transfer rates.
So this seems to be the bottleneck in my case.
Anyway, I am happy that v2048 works with my GeForce 9600 GS.

I have a fast spinning mechanical drive with a very large cache interfaced with SATA 600 (not an SSD). HDTune gives me a read benchmark of 190 MB/s.

That's about 2.5 times of what I am getting with my HD. It is clear now why I am not getting more speed gain with v2048. But as long as it works with my system, I am fine.

I never announced the changes for 2048, so here they are. Note that the last two were slipstreamed
today, so if you want them, please re-download and update DGIndexNV and DGDecodeNV.

* Greatly improved the indexing speed (almost twice as fast for transport streams).
Note that you need relatively fast disk I/O to see these improvements. CPU optimizations
can be swamped by slow I/O.

* Updated to CUDA version 6.5 and built with VS2013 Express (Update 3 RC). Note that CUDA architecture
sm_10 support was dropped by nVidia. That means really old slow cards are no longer
supported.

* Made fixes so that alternate languages set via the system locale setting are now properly
handled. This is a "poor man's" substitute for full Unicode support. Full Unicode support
is not possible because it is not supported by Avisynth.

admin wrote:...Note that CUDA architecture sm_10 support was dropped by nVidia. That means really old slow cards are no longer
supported.

The "really old slow" part describes me pretty well!

I suspect your readme is done already but for next time you might want to add some more clues as to what this means 'zackly i.e. I recall that I looked-up my 9600GT (which she's a no work) but don't remember the conditions i.e. what sm_10 translates to in the world of non-techies.

But maybe anudder cuppa coffee and I'll recall...

Good morning, laserfan. Search for sm_10 in that "Search this topic..." box at the top and you will find everything you need to know.

I've added the relevant link to the readme. Thanks for the suggestion.

Build 2049 is now available.

* Added support for 4K/UHD resolutions (but no HEVC yet).

* Added a bunch of cards to the GPU information lookup table.

admin wrote:* Added support for 4K/UHD resolutions (but no HEVC yet).

Excellent! I wasn't sure about this feature.
I've got a bunch of trailers in 2K/4K that I've been using FFMS2.
I just thought they were encoded differently.

Thanks for the update.

I'm happy that you find it useful, sparktank. Thank you for the feedback and good luck for your projects.

I slipstreamed a fix for DGDecodeNV.dll 64-bit that caused it to fail in StaxRip and elsewhere. The 32-bit version is not affected. Please re-download 2049 and update dgdecodenv.dll if you need this fix.

Thanks to staxrip76 for helping me to identify and fix this issue.

I slipstreamed a fix for DGIndexNV.exe that caused it to not properly clean up when the CLI exits using the -e option. This could cause subsequent starts to fail. This may affect 3rd-party GUIs and so users of those apps should consider re-downloading and updating DGIndexNV if they are experiencing any issues.