Finally I've got radix sort implementation which is working on AMD OpenCL. This is a link on previous sorting algorithms test. And now we have new more interesting results :) Time of GPU sorting includes time of data downloading from video memory. Sorted structure is single uint2 array for bitonic sort, and two int arrays for radix sort.
Elements 64768:
CUDA:
GeForce 9600GT:
CUBitonic Time: 0.007 FPS: 140.5679 Mem: 69.46 Mb/s
CURadix Time: 0.003 FPS: 342.8180 Mem: 169.40 Mb/s
GeForce GTX 260:
CUBitonic Time: 0.002 FPS: 403.5513 Mem: 199.41 Mb/s
CURadix Time: 0.001 FPS: 752.4454 Mem: 371.81 Mb/s
GeForce GTX 480:
CUBitonic Time: 0.001 FPS: 966.1836 Mem: 477.43 Mb/s
CURadix Time: 0.001 FPS: 1398.6014 Mem: 691.11 Mb/s
OpenCL:
GeForce 9600GT:
CLBitonic Time: 0.008 FPS: 126.9519 Mem: 62.73 Mb/s
CLRadix Time: 0.004 FPS: 252.9724 Mem: 125.00 Mb/s
GeForce GTX 260:
CLBitonic Time: 0.004 FPS: 266.7378 Mem: 131.81 Mb/s
CLRadix Time: 0.003 FPS: 368.3241 Mem: 182.00 Mb/s
GeForce GTX 480:
CLBitonic Time: 0.002 FPS: 579.3743 Mem: 286.29 Mb/s
CLRadix Time: 0.002 FPS: 614.2506 Mem: 303.53 Mb/s
Radeon HD5870:
CLRadix Time: 0.003 FPS: 372.9952 Mem: 184.31 Mb/s
Single SPU:
quickSort SPU Time: 0.031 FPS: 32.5298 Mem: 32.15 Mb/s
radixSort SPU Time: 0.004 FPS: 226.9632 Mem: 224.30 Mb/s
Elements 1036288:
CUDA:
GeForce 9600GT:
CURadix Time: 0.036 FPS: 27.8808 Mem: 220.43 Mb/s
GeForce GTX 260:
CURadix Time: 0.013 FPS: 74.1400 Mem: 586.17 Mb/s
GeForce GTX 480:
CURadix Time: 0.006 FPS: 161.9958 Mem: 1280.78 Mb/s
OpenCL:
GeForce 9600GT:
CLRadix Time: 0.034 FPS: 29.8312 Mem: 235.85 Mb/s
GeForce GTX 260:
CLRadix Time: 0.013 FPS: 79.2959 Mem: 626.93 Mb/s
GeForce GTX 480:
CLRadix Time: 0.007 FPS: 136.2955 Mem: 1077.59 Mb/s
Radeon HD5870:
CLRadix Time: 0.020 FPS: 49.9800 Mem: 395.15 Mb/s
Single SPU:
quickSort SPU Time: 0.695 FPS: 1.4381 Mem: 22.74 Mb/s
radixSort SPU Time: 0.070 FPS: 14.3275 Mem: 226.55 Mb/s
Any idea why is the Elements 64768 benchmark has the timings between CUDA vs OpenCL differ quite significantly? where the Elements 1036288 benchmark has much closer timings.
ReplyDeleteIt seems like command response or copying of small memory blocks is more efficient on CUDA than on OpenCL.
ReplyDeletei hope unigine support CUDA as well & looks like promising
ReplyDeleteCUDA is stupid. Programming for it will only for ~50% of the market which means you'll be doing OpenCL programming anyways.
ReplyDeleteOpenCL IS stupid. Have you tried to write a program in OpenCL? Storing the code into a string? Compiling OpenCL files at run-time? Managing platforms, devices, contexts, kernels, even kernel arguments!!? This is OK to build frameworks (like with the CUDA driver API), but not for regular programmers.
ReplyDelete