Support forum for DG Tools

Stupid me. I know what is wrong. Standby...

Well, maybe...

Please re-download and try again. Please reload the browser page before starting the download just to make absolutely sure. Also, copy all the files not just DGIndexNV.exe.

New screenshot

This version can playback video! Thanks for your quick help in diagnosing this issue Donald.

That is good to know.

Thanks for helping me to debug this issue. I don't have any 1.x series cards here anymore.

Ominously, the build for sm_11 now says:

1>CUSTOMBUILD : nvcc warning : The 'compute_11', 'compute_12', 'compute_13', 'sm_11', 'sm_12', and 'sm_13' architectures are deprecated, and may be removed in a future release.

In order not to lose a lot of cards, we'll have to stick to CUDA 6.5 as long as we can. I certainly don't want to support multiple variants of DGDecNV requiring different build environments!

EDIT: It occurred to me that I might be able to ship the old cubins already built with the older CUDA toolsets. I just wouldn't be able to enhance or rebuild them unless I keep multiple environments around. It's not likely I will need to revise a simple color space conversion CUDA program. That's all the cubin does, i.e., convert NV12 to RGB24 for display. So maybe things are not so terrible. Of course that assumes that CUDA toolkit 6.5 module loads still work for older cubins, which may be optimistic.

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.

I used this nVidia documentation for developers page:

http://docs.nvidia.com/cuda/index.html

Click on "Programming Guide" on the left-hand menu, expand section 2, and click on "2.5. Compute Capability" for the brief list. It appears nVidia also has a more comprehensive list of which GPU supports what on a separate page.

Groucho2004 wrote: I tested build 2048 with my GT240, everything seems to work fine.

That's a relief.

Indexing speed of raw streams is unchanged but for m2ts it's indeed almost twice as fast compared to 2047.

Which is serendipitous, because blurays are M2TS, so they are indexed in about half the time as before.

I tried an MKV and it seems to index faster as well.

Hm, I indexed a full length movie 99min@24fps (Import) and it took about 10min to index.
AVC/MKV from external HDD.

I notice something different about the indexing. The status seems to be in a frozen status where the time just doesn't let it go.
The # of frames seem to only change at intervals of 1000.

There is a speed improvement.
Found an old log from 2047 that indexed the same video remux.

2047= Elapsed: 0:13:23
2048= Elapsed: 0:10:37

sparktank wrote:The status seems to be in a frozen status where the time just doesn't let it go.
The # of frames seem to only change at intervals of 1000.

Yes, it now updates only every 1000 frames when indexing. Is what you call "frozen" something beyond that or you just mean it is "frozen" until the next 1000 frames are done?

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.