OpenCL kicks butt
I took 184 raw images from 1DX and processed them without OpenCL enabled. It took 9 minutes and 40 seconds, 3.15 sec per image. Then I enabled OpenCL, and processed the same images. It took exactly 3 minutes, or 1.3 sec per image.
This is a great improvement in processing speed. Processing was to 100% quality, no resize, JPEG.
What I noticed is that with OpenCL disabled, all 4 main CPU cores are utilized at 100%, but when OpenCL is enabled, they are loaded only to 50%. It means that the processing can be done even faster, if programmers could put the unused CPU resources to work, so that both GPU and CPU are loaded to 100%. Then I could process at 0.7 sec per image. That would be great!
This is a great improvement in processing speed. Processing was to 100% quality, no resize, JPEG.
What I noticed is that with OpenCL disabled, all 4 main CPU cores are utilized at 100%, but when OpenCL is enabled, they are loaded only to 50%. It means that the processing can be done even faster, if programmers could put the unused CPU resources to work, so that both GPU and CPU are loaded to 100%. Then I could process at 0.7 sec per image. That would be great!
0
-
Your times are luxury 😄
Would you mind telling us your hardware specs?
Cheers
BeO0 -
[quote="atelzzz" wrote:
I took 184 raw images from 1DX and processed them without OpenCL enabled. It took 9 minutes and 40 seconds, 3.15 sec per image. Then I enabled OpenCL, and processed the same images. It took exactly 3 minutes, or 1.3 sec per image.
This is a great improvement in processing speed. Processing was to 100% quality, no resize, JPEG.
What I noticed is that with OpenCL disabled, all 4 main CPU cores are utilized at 100%, but when OpenCL is enabled, they are loaded only to 50%. It means that the processing can be done even faster, if programmers could put the unused CPU resources to work, so that both GPU and CPU are loaded to 100%. Then I could process at 0.7 sec per image. That would be great!
Regarding the CPU and the remaining 50% perccent, then I'm quite interested how you reached the 0.7 s number 😉
Btw, if you want more speed, add another GFX (of the same model), it will go even faster. This will also results in a higher load on the CPU, as it has to feed the GPU faster.
As a comparison, I have a machine that will do 99 5d2/3 raws to native size 8 bit in 36 seconds.0 -
[quote="Christian Gruner" wrote:
Regarding the CPU and the remaining 50% perccent, then I'm quite interested how you reached the 0.7 s number 😉
The number 0.7 was just a guess. It can be very inaccurate.0 -
[quote="Christian Gruner" wrote:
Btw, if you want more speed, add another GFX (of the same model), it will go even faster. This will also results in a higher load on the CPU, as it has to feed the GPU faster.
As a comparison, I have a machine that will do 99 5d2/3 raws to native size 8 bit in 36 seconds.
I will most likely try it, maybe even tomorrow, adding the second graphics card.
I just checked and the second PCIE slot I have is x4. It is not PCIE3.0. If I put the same graphics card in it, as I have in the primary PCIE3.0 x16 slot, will it work? Will it speed up the processing ?
Another thing I noticed (since you are a test engineer) is that JPEG files produced with and without using OpenCL are different in size. The file size on average is 10Mb, and file size difference is about 50Kb to 100Kb.
It can be nothing, but also could be an indication of a bug present somewhere in the code.
I would assume that no matter where you do the processing, CPU or GPU, the resulting JPEG file is exactly the same, byte for byte.0 -
Atelzzz, can you visually detect any difference between a CPU-JPG and a GPU-JPG? 0 -
[quote="BeO" wrote:
Atelzzz, can you visually detect any difference between a CPU-JPG and a GPU-JPG?
No visual differences. I tried to find them switching between the images quickly back and forth, the picture stays the same on the screen.0 -
[quote="atelzzz" wrote:
[quote="BeO" wrote:
Atelzzz, can you visually detect any difference between a CPU-JPG and a GPU-JPG?
No visual differences. I tried to find them switching between the images quickly back and forth, the picture stays the same on the screen.
Maybe you could perform some kind of subtract operation between them in a picture editor such as Photoshop? I'm no expert in this field, but I'd be surprised if PS can't do it.0 -
Put them in two layers, top layer : difference 0 -
[quote="WPNL" wrote:
Put them in two layers, top layer : difference
I did as you suggested, using calculations tool in photo shop, channel by channel.
There are no differences (result is all black) in Red, Blue, Green, Grey channels.
But there is a difference in Transparency channel: the result is all black with a thin, maybe 20 pixels, white line on the right side of the image, and thicker (about 50 pixels?) line at the bottom, not exactly grey, more like a gradient.0 -
Sounds like a bug to me. A minor one, maybe, but still a bug. 0 -
And which image would be the "correct" one, without lines, the CPU or GPU version?
Thanks,
BeO0 -
[quote="atelzzz" wrote:
[quote="WPNL" wrote:
Put them in two layers, top layer : difference
I did as you suggested, using calculations tool in photo shop, channel by channel.
There are no differences (result is all black) in Red, Blue, Green, Grey channels.
But there is a difference in Transparency channel: the result is all black with a thin, maybe 20 pixels, white line on the right side of the image, and thicker (about 50 pixels?) line at the bottom, not exactly grey, more like a gradient.
There are no transparency-channels/alpha channels in the output files of CO, only the 3 RGB channels. Maybe you have added some masks when doing the comparison in PS?0 -
[quote="Christian Gruner" wrote:
[quote="atelzzz" wrote:
[quote="WPNL" wrote:
Put them in two layers, top layer : difference
I did as you suggested, using calculations tool in photo shop, channel by channel.
There are no differences (result is all black) in Red, Blue, Green, Grey channels.
But there is a difference in Transparency channel: the result is all black with a thin, maybe 20 pixels, white line on the right side of the image, and thicker (about 50 pixels?) line at the bottom, not exactly grey, more like a gradient.
There are no transparency-channels/alpha channels in the output files of CO, only the 3 RGB channels. Maybe you have added some masks when doing the comparison in PS?
I must have done something wrong that time, I copied the images to separate layers, I don't know why. The combo boxes were showing Transparency as separate channel in source 1 and 2
I did it again by opening the two images and doing calculations on them directly There were only R, G, B channels this time, no transparency, and there is no difference between the channels.
I put the second graphics card, but this time it gave only 40% increase in speed of converting RAW to JPEG. (0.92 sec per image)
Also, only some RAW format conversions use OpenCL, Canon 1DX is one example. There is no OpenCL support for Fujifilm XT-1, it is all CPU.. Are you planning to add it in the future ?0 -
Still you said you noticed a "file size difference [of] about 50Kb to 100Kb". Can you confirm? If there's indeed a file size difference, where does it come from, since the two files are graphically identical? 0 -
Yes, I confirm it. Just now I converted 1 single file 2 times in a row, changing only OpenCL enabled/disabled flags between the two runs. And the file sizes are different: GPU: 576,820 bytes, and CPU: 576,193 bytes. This was to 80% quality, 2048px long side JPEG. It should be easy to reproduce, or if they can't, that's all right too, it does not give a blue screen or something like that. 0 -
[quote="atelzzz" wrote:
I must have done something wrong that time, I copied the images to separate layers, I don't know why. The combo boxes were showing Transparency as separate channel in source 1 and 2
I did it again by opening the two images and doing calculations on them directly There were only R, G, B channels this time, no transparency, and there is no difference between the channels.
I put the second graphics card, but this time it gave only 40% increase in speed of converting RAW to JPEG. (0.92 sec per image)
Also, only some RAW format conversions use OpenCL, Canon 1DX is one example. There is no OpenCL support for Fujifilm XT-1, it is all CPU.. Are you planning to add it in the future ?
40% is probably expected, but still a significant increase in performance. The reason you don't see 100% percent is due to all the other external factors like read, decompression, write to disk and so on. Especially compressing jpeg takes a bit, and is done on the CPU.
If you benchmark with uncompressed tiffs instead, you will see more more gain in speed by adding a second card.
I cannot comment on plans for potential future futures, so I can't say much about x-trans.
As long as there isn't any visible difference between the 2 shots, a size-difference will have low priority. However, if it, for some reason were visible, it ranks pretty high. We do run comparison-tests to keep this in check.0 -
[quote="Christian Gruner" wrote:
Especially compressing jpeg takes a bit, and is done on the CPU.
Single-threaded?0 -
[quote="BeO" wrote:
[quote="Christian Gruner" wrote:
Especially compressing jpeg takes a bit, and is done on the CPU.
Single-threaded?
We are using the Intel Jpeg library to convert, I don't recall if it is multithreaded or not.0 -
[quote="Christian Gruner" wrote:
40% is probably expected, but still a significant increase in performance.
Yes, just now I did the same test with Photoshop CS6, just for fun, to see where it stands. With all bells and whistles enabled (like OpenCL), it still gives 4.5 sec per image, 5 times slower than C1. Maybe they improved it in latest releases, I do not know. The CPU usage pattern is different: spikes to 100%, staying there for about 1sec, then going down to 0% and staying there also for 0.5 sec.0 -
I wish OpenCL worked well on my Surface Book i7 + NVidia dGPU... that sounds great!
I get display artifacts, and it doesn't appear to render photos reliably (some get bands, some get green speckles, and some are fine).0 -
[quote="gregger" wrote:
I wish OpenCL worked well on my Surface Book i7 + NVidia dGPU... that sounds great!
I get display artifacts, and it doesn't appear to render photos reliably (some get bands, some get green speckles, and some are fine).
Please create a support-case. That way the Support team can feed forward more info to us, and thus we will have greater chance of fixing it.0 -
I did create a support case at some point. I thought this might be an Nvidia Driver issue (even though if I target the Intel 550 HD driver at Capture One, it will do different, but similar artifacting of processed files).
I was hoping the latest Surface Book firmware upgrade would fix it. But it didn't (they didn't rev the Nvidia drivers).
I also tried the latest Nvidia driver following the usual procedure (editing INF files). It changed the behavior, but didn't fix it.
You can try too if you want, but it doesn't fix it.
I'll retry the support case I guess.
[Edit]:
I have 2 open cases now.
208002 from December 2015
213094 from today (2/27/2016)0 -
Those instructions sound very complicated.
Is it not possible anymore with (I assume) Win 10 to just find a decent driver from the developer, download it and get Windows to use it?
Grant0 -
[quote="gregger" wrote:
I did create a support case at some point. I thought this might be an Nvidia Driver issue (even though if I target the Intel 550 HD driver at Capture One, it will do different, but similar artifacting of processed files).
I was hoping the latest Surface Book firmware upgrade would fix it. But it didn't (they didn't rev the Nvidia drivers).
I also tried the latest Nvidia driver following the usual procedure (editing INF files). It changed the behavior, but didn't fix it.
You can try too if you want, but it doesn't fix it.
I'll retry the support case I guess.
[Edit]:
I have 2 open cases now.
208002 from December 2015
213094 from today (2/27/2016)
We have fixed issue with the Surface Book in the just-released CO 9.1, more here: viewtopic.php?f=62&t=223320
Post is closed for comments.
Comments
24 comments