3 ms·

you are mistaken. //kernel __kernel myKernel (int val){ //... } //host int val = 10; clSetKernelArg(kernel, 0, val, sizeof(int

by 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.
  - goldenkey 13y ago
    It's actually not the same thing. I've looked at the PTX disassembly and the difference is that the OpenCL code must perform a dereference while the CUDA code can use a fixed address, (relocatable of course.) The address is relocated based on the loaded base address of the kernel module. So there is a huge gain for certain types of code to save an instruction and possible warping, cache miss, register pressure, etc. Right, OpenCL runs on the Knights Corner/Bridge (PHI - what a piece of crap btw), CPUs, and many other devices, it has its place. And CUDA does too. I write CUDA when I'm on Nvidia devices because of the dereferencing performance as well as the slight speed gain that the double-buffering of workgroups that CUDA supports slightly better than OpenCL. All in all, they're pretty on par, I'm fond of CUDA a little more due to the clarity of its driver API and non-evented model. It's a little bit easier to work with. Anyhow, I think we're done here. I got you to admit that CUDA isn't a piece of monopolistic smudgenry. Which is really all I wanted :-)

by foxhill 13y ago

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.
- goldenkey 13y ago
  It's actually not the same thing. I've looked at the PTX disassembly and the difference is that the OpenCL code must perform a dereference while the CUDA code can use a fixed address, (relocatable of course.) The address is relocated based on the loaded base address of the kernel module. So there is a huge gain for certain types of code to save an instruction and possible warping, cache miss, register pressure, etc. Right, OpenCL runs on the Knights Corner/Bridge (PHI - what a piece of crap btw), CPUs, and many other devices, it has its place. And CUDA does too. I write CUDA when I'm on Nvidia devices because of the dereferencing performance as well as the slight speed gain that the double-buffering of workgroups that CUDA supports slightly better than OpenCL. All in all, they're pretty on par, I'm fond of CUDA a little more due to the clarity of its driver API and non-evented model. It's a little bit easier to work with. Anyhow, I think we're done here. I got you to admit that CUDA isn't a piece of monopolistic smudgenry. Which is really all I wanted :-)