Target drive too slow

Discussion in 'CloneBD' started by Ch3vr0n, Apr 1, 2018.

  1. Ch3vr0n

    Ch3vr0n Translator NL & Mod

    @Pete @Reto @Fabian

    There must be something "wrong" with the "encoder output" progress bar or the algorithm when using CUDA (GTX 1080)

    It doesn't matter which type of conversion i do, that progress bar constantly fluctuates and very often goes as high as 90-100%. Even when outputting to my 850 Evo, so i figured, well maybe with the meltdown patches something did change. So i splashed out on a 512GB Samsung 960 Pro, which is the fastest consumer drive on the market.

    Did it change anything? No, not a damn thing. Still peaks at 100%

    Now the twist: if i switch from CUDA to Intel QuickSync (HD Graphics 530, from my 6700k, stock speeds) that doesn't happen. "Encoder output" stays at 0% like it should, from beginning to end even on my "slow" 850 EVO!

    Logs:

    Test title: The foreigner
    Conversion: To MKV


    Target drive: 850 EVO
    HW Acc: QuickSync
    Quality: Highest
    FPS: 210-235
    Encoder Output: 0-2% throughout (except a small spike at the end)
    CPU CloneBD: 35-37%
    CPU Other: 26% (firefox active)
    CPU inactive: 34-40%
    Time Elapsed: +-13min
    File: CloneBD.1.1.9.4.The Foreigner.cbdlog

    Target Drive: 850 EVO
    HW Acc: CUDA
    Quality: Highest
    FPS: 300-320
    Encoder Output: 98-100% throughout! (at 40% encoding drops to 0% for maybe 5 seconds, then back to 100%)
    CPU CloneBD: 35-37%
    CPU Other: 26% (firefox active)
    CPU inactive: 34-40%
    Time Elapsed: just over 8min
    File: CloneBD.1.1.9.4.The Foreigner_1.cbdlog

    Exact same thing when swapping to my 960 Pro
     

    Attached Files:

  2. Fabian

    Fabian Developer

    This is normal behavior. GPU HW encoding is asynchronous to CPU and I/O processing.

    There is also a difference in workload distribution between Intel QuickSync and nVidia CUDA. Some processing on nVidia cannot be assigned correctly and is just assigned to the Output stage. All processing bars are purely cosmetic.
     
  3. Ch3vr0n

    Ch3vr0n Translator NL & Mod

    I don't know when this started happening (maybe the last 10-15 [beta] versions ago), but I do know that the earlier builds didn't have this 'problem'. Even with cuda, that 4th progress bar remained at 0.

    Did something change somewhere down the line that could have his cosmetic effect?

    PS: any idea when https://forum.redfox.bz/threads/full-disc-3d-support.73953/ will be added? ^^

    Sent from my Nexus 6P with Tapatalk
     
  4. Fabian

    Fabian Developer

    The change is related to colorspace transformation that is partly done in GPU.

    Your CPU Other and CPU Idle values are identical. Therefore the CPU Usage of CloneBD must also be identical as all 3 values add up to 100%. The difference in processing time is due to the higher number of Processing Units of the nVidia GPU.

    If all stages for decoding, encoding and colorspace as well as picture transformation can be done in the GPU then it is done in the GPU. There is no way to precisely measure each stage inside the GPU, unless you sacrifice a lot of GPU power just for that. That's why the encoding stage (Encoder Output) shows higher values.
     
  5. Ch3vr0n

    Ch3vr0n Translator NL & Mod

    If colorspace is now done by the GPU, doesn't that increase the workload and therefore the target drive should definitely be able to keep up, or am I misunderstanding things?

    Ah well, at least things are normal then. Now I just wish HW accelerated 3D support comes soon.

    Sent from my Nexus 6P with Tapatalk