3 ms·

Tutorials... That's your frame of reference? How can you expect to learn much when the quality of tutorials is well.. In the gutter. Not only an extra arg, but

Tutorials... That's your frame of reference? How can you expect to learn much when the quality of tutorials is well.. In the gutter. Not only an extra arg, but dereferencing everywhere the arg is used. The constant memory is quite easy to exceed, 64k is nothing. Still, you can't modify constant memory from in the kernel so it's really a different beast entirely. CUDA has clean persistence. Really, that's the big bonus for using it. Dynamic parallelism too on certain cards. And the cuFFT and various libs. Really, I don't know what you expect when you talk shit on CUDA as if it's anti-trust and monopolistic. Recall that it came before OpenCL and much of OpenCL was based on it and the recommendations given by Nvidia to the committee. If you use fermi devices like the Titan and tesla, CUDA is going to give you more power in terms of both code and architecture output of nvcc to tune for performance. CUDA is awesome and so is OpenCL but don't shit on CUDA because open-source has your panties in a knot.

foxhill 13y ago
no, my frame of reference is all the talks, workshops, and presentations i've attended, papers i've read, and real code i've seen and worked with. setting a single scalar argument requires no extra dereferencing in the kernel. if you're setting an array of values, then you'd need to dereference (via array indexing), but you'd need to do that in CUDA too. besides, even if you did have to dereference it, writing it into a private variable would save future dereferences, and even a basic optimising compiler would do this by default. and you talk about persistent global state as if you'd want that. global variables (in any language) are generally considered bad practise. OpenCL 2.0 has dynamic parallelism, too. .. are you being serious? maybe monopoly means something different to me? exactly, how many brands of GPU have official support for CUDA? yes, CUDA came before OpenCL, and nvidia are (still) a part of "the committee" - khronos. but it was apple that created OpenCL, handing it to khronos after they came up with 1.0. that said, it was neither apple or nvidia, that came up with the idea of compute on the GPU. BrookGPU is the real project that kick started GPGPU. i hate to nit-pick, but the Titan is kepler, not fermi. architecture output of nvcc? i don't even know what you mean. for the codes in which i've written both OpenCL and CUDA, the performance difference is almost measurement noise. my complaint of using CUDA in rust is as follows - rust is an open language, being created by an "open source" company. it makes absolutely no sense to me, that a company with free software principles should make their language dependent on a specific vendor. i don't think that's an outlandish complaint. imagine if rust only compiled for intel CPUs. or only worked in windows.
- goldenkey 13y ago
  OpenCL: __kernel myKernel(int* theMem){ *theMem = 0xDEAD; } CUDA: __device theMem; __kernel myKernel(void){ theMem = 0xBEEF; } nvcc has a lot of nice flags to set max register count as well as smi architecture or compute_architecture. It's a little bit more flexible than OpenCL. http://camolab.googlecode.com/svn/trunk/mycode/cuda/nvcc-help.txt http://camolab.googlecode.com/svn/trunk/mycode/cuda/nvcc-hel... Anyhow, Mozilla's decisions are Mozilla's alone, you shouldn't bad angry at anyone _but_ Mozilla for taking the bait.
  - foxhill 13y ago
    you are mistaken. //kernel __kernel myKernel (int val){ //... } //host int val = 10; clSetKernelArg(kernel, 0, val, sizeof(int)); similarly, for architecture/max reg count, clBuildProgram(..., "-cl-nv-arch sm_35 -cl-nv-maxrregcount 20",...); i'm not angry at anyone. i disagree with mozilla's decision. that is all.
    - goldenkey 13y ago
      Setting a kernel argument in this manner can only be used for inputs to the kernel. Any output you want to read (either in a subsequent kernel or from the host program) must be written to a buffer or an image. In your case, that means you need to create a single-element buffer and pass the buffer to the kernel.
      - foxhill 13y ago
        well, either way, in the snippet of code you just posted, your assignment is still a dereference. CUDAs &theMem is a pointer to somewhere in memory, OpenCL's theMem is a pointer to somewhere in memory. in the back end of CUDA, it's doing the same thing as what you would explicitly do in OpenCL. we could talk about minor language difference for days. really, there is no major difference between OpenCL and CUDA (and that's one of the main reasons i'll write CUDA code - when i know my code will only ever run on nvidia GPUs). but when i write OpenCL code, i know it will run on all GPUs, and CPUs, and any accelerator that has an OpenCL stack.

foxhill 13y ago

no, my frame of reference is all the talks, workshops, and presentations i've attended, papers i've read, and real code i've seen and worked with. setting a single scalar argument requires no extra dereferencing in the kernel. if you're setting an array of values, then you'd need to dereference (via array indexing), but you'd need to do that in CUDA too. besides, even if you did have to dereference it, writing it into a private variable would save future dereferences, and even a basic optimising compiler would do this by default. and you talk about persistent global state as if you'd want that. global variables (in any language) are generally considered bad practise. OpenCL 2.0 has dynamic parallelism, too. .. are you being serious? maybe monopoly means something different to me? exactly, how many brands of GPU have official support for CUDA? yes, CUDA came before OpenCL, and nvidia are (still) a part of "the committee" - khronos. but it was apple that created OpenCL, handing it to khronos after they came up with 1.0. that said, it was neither apple or nvidia, that came up with the idea of compute on the GPU. BrookGPU is the real project that kick started GPGPU. i hate to nit-pick, but the Titan is kepler, not fermi. architecture output of nvcc? i don't even know what you mean. for the codes in which i've written both OpenCL and CUDA, the performance difference is almost measurement noise. my complaint of using CUDA in rust is as follows - rust is an open language, being created by an "open source" company. it makes absolutely no sense to me, that a company with free software principles should make their language dependent on a specific vendor. i don't think that's an outlandish complaint. imagine if rust only compiled for intel CPUs. or only worked in windows.

goldenkey 13y ago
OpenCL: __kernel myKernel(int* theMem){ *theMem = 0xDEAD; } CUDA: __device theMem; __kernel myKernel(void){ theMem = 0xBEEF; } nvcc has a lot of nice flags to set max register count as well as smi architecture or compute_architecture. It's a little bit more flexible than OpenCL. http://camolab.googlecode.com/svn/trunk/mycode/cuda/nvcc-help.txt http://camolab.googlecode.com/svn/trunk/mycode/cuda/nvcc-hel... Anyhow, Mozilla's decisions are Mozilla's alone, you shouldn't bad angry at anyone _but_ Mozilla for taking the bait.
- foxhill 13y ago
  you are mistaken. //kernel __kernel myKernel (int val){ //... } //host int val = 10; clSetKernelArg(kernel, 0, val, sizeof(int)); similarly, for architecture/max reg count, clBuildProgram(..., "-cl-nv-arch sm_35 -cl-nv-maxrregcount 20",...); i'm not angry at anyone. i disagree with mozilla's decision. that is all.
  - goldenkey 13y ago
    Setting a kernel argument in this manner can only be used for inputs to the kernel. Any output you want to read (either in a subsequent kernel or from the host program) must be written to a buffer or an image. In your case, that means you need to create a single-element buffer and pass the buffer to the kernel.
    - foxhill 13y ago
      well, either way, in the snippet of code you just posted, your assignment is still a dereference. CUDAs &theMem is a pointer to somewhere in memory, OpenCL's theMem is a pointer to somewhere in memory. in the back end of CUDA, it's doing the same thing as what you would explicitly do in OpenCL. we could talk about minor language difference for days. really, there is no major difference between OpenCL and CUDA (and that's one of the main reasons i'll write CUDA code - when i know my code will only ever run on nvidia GPUs). but when i write OpenCL code, i know it will run on all GPUs, and CPUs, and any accelerator that has an OpenCL stack.