tux2603 / DeepDream

Nice little modular interface for running deep dreams on image sets
MIT License
7 stars 2 forks source link

subprocess for conda - command failed #10

Open ptah4i opened 3 years ago

ptah4i commented 3 years ago

Get the following error when running main.py with -no-gpu flag.

Processing /opt/images/source/IMG_0539.jpg /opt/miniconda/envs/cpu/.tmp9fz0yk__: line 3: 29149 Killed ./dream.py --num-iterations 1 --octave-count 4 --octave-scale 1.3 --steps-per-octave 10 --maximize inception_4c/output --jitter 32 --no-gpu ERROR conda.cli.main_run:execute(33): Subprocess for 'conda run ['./dream.py', '--num-iterations', '1', '--octave-count', '4', '--octave-scale', '1.3', '--steps-per-octave', '10', '--maximize', 'inception_4c/output', '--jitter', '32', '--no-gpu']' command failed. (See above for error)

I’m running on a DigitalOcean droplet with Ubuntu 20.04. Need help please!

tux2603 commented 3 years ago

Would you be able to supply the following information?

Since your running without GPU, it might also be useful to have the CPU and core count, but isn't necessary

ptah4i commented 3 years ago

Singularity 3.6.8 Kernel 5.4.0-67-generic Ram 1,5GB free CPU info Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 40 bits physical, 48 bits virtual CPU(s): 1 On-line CPU(s) list: 0 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 63 Model name: DO-Regular Stepping: 2 CPU MHz: 2494.100 BogoMIPS: 4988.20 Virtualization: VT-x Hypervisor vendor: KVM Virtualization type: full L1d cache: 32 KiB L1i cache: 32 KiB L2 cache: 4 MiB NUMA node0 CPU(s): 0 Vulnerability Itlb multihit: KVM: Mitigation: Split huge pages Vulnerability L1tf: Mitigation; PTE Inversion; VMX conditional cach e flushes, SMT disabled Vulnerability Mds: Mitigation; Clear CPU buffers; SMT Host state u nknown Vulnerability Meltdown: Mitigation; PTI Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled v ia prctl and seccomp Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization Vulnerability Spectre v2: Mitigation; Full generic retpoline, IBPB condit ional, IBRS_FW, STIBP disabled, RSB filling Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Not affected Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtr r pge mca cmov pat pse36 clflush mmx fxsr sse s se2 ss syscall nx rdtscp lm constant_tsc arch_p erfmon rep_good nopl cpuid tsc_known_freq pni p clmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsav e avx f16c rdrand hypervisor lahf_lm abm cpuid_ fault invpcid_single pti ssbd ibrs ibpb tpr_sha dow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsa veopt md_clear

tux2603 commented 3 years ago

The ram might be an issue. How much swap space do you have available? The process would usually use 3-5 GB of ram during testing depending on the resolution of the images and how many are being processed.

ptah4i commented 3 years ago

I have now create a swap space of 3GB and use smaller images. Now the process runs without any error but I get no result.

tux2603 commented 3 years ago

What are you passing for the destination directory?

ptah4i commented 3 years ago

I’m running it as root with

# ./main.py --no-gpu -s /home/DeepDream/s -d /home/DeepDream/d

In the source directory is one image (1.JPG).

ptah4i commented 3 years ago

Ok. I think it’s solved.

The “subprocess - command failed” issue seems to be related to the image size/hardware specs.

If you use .JPG instead of .jpg the process aborts without a error message.

Now it’s working! (smallImage.jpg) Thanks for your attention!

tux2603 commented 3 years ago

No problem. I'll go through and fix the program so it detects .JPG files as valid

ptah4i commented 3 years ago

As a side note. I’m running another DeepDream generator on this VPS with large images without any problem. Maybe there is a fix for the subprocess issue too.

tux2603 commented 3 years ago

It's quite possible that the other generator is using a different model by default. If the model they're using is smaller, then that would explain why it uses less system resources. If you're able to find the model they use and it's compatible with caffe you can try using it.

There would also be some overhead from the model being run in singularity, but that shouldn't be more than a few megabytes