3 ms·

it's not the standard programming model in CUDA. the library functions compile down to the same PTX, it's the exactly the same toolchain wether you use nvcc or

by foxhill 13y ago

it's not the standard programming model in CUDA. the library functions compile down to the same PTX, it's the exactly the same toolchain wether you use nvcc or clBuildProgram - if you could provide an example indicating otherwise, i'd very much like to see it. you most certainly can set a kernel-wide global in OpenCL, and it does not need to be a buffer object. and you don't need to re-set it between kernel invocations (this would be true even if it were a buffer object). OpenCL is certainly verbose, but honestly, given that you may have multiple implementations of it on the same machine, i don't really see how it could be done any simpler (at least from the C API perspective). i use CUDA and OpenCL every working day. it is literally what i am employed to do.

goldenkey 13y ago
Standard programming model? Please stop. You have two options with CUDA, no one is tying your hands in a knot, NVidia doesn't have a committee setting standards on which of their 2 flavors of toolkit you need to use. You are so biased it hurts. Considering you use OpenCL at work every day it would help all the hackers here if you don't spread mistruths. There are no statics in opencl unless they are in constant memory and set in the program source. And we both know constant memory is quite limited and this fact would require you to interpolate your data into a byte array to sprintf it into source. There are no persistent global in opencl. You must pass all your globals to your kernel. We both know setKernelArg is persistent across kernel calls- but who cares? In CUDA you don't need an argument and you don't need to dereference it either. Way better. http://www.khronos.org/message_boards/showthread.php/6437-Global-variables-in-OpenCL http://www.khronos.org/message_boards/showthread.php/6437-Gl...
- foxhill 13y ago
  as in, it's not how any tutorial or walk through i've ever seen has tried to teach the user about CUDA, it's not something nvidia talk about primarily in their documentation of the language. if it's so common, why isn't it being used in rust? please, continue to make fallacious statements about me and what i think. i really don't care. regardless, there are three (not two) programming models in CUDA - high level (CUBLAS/FFT), CUDA runtime, and the driver API. constant memory is 64k on an M2050, a GPU from 3 years ago. if you want to set more than 16 thousand floating point constants.. well, you probably want to put that in main memory. i use OpenCL and CUDA, every day. and sorry for misunderstanding what you were saying, but really? you think passing in an argument is such a hassle? yes, setKernelArg is persistent across calls - so i'm confused why you're saying you don't care? it does exactly what you've been complaining it can't do (and, yes, it requires an extra kernel argument, oh my). you've been constantly bashing OpenCL - nothing more than a document, the contents of which are decided by a committee of people, none of whom are myself - implicitly praising CUDA, and you call me biased? you don't even know what i think about either of them.
  - goldenkey 13y ago
    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.

by foxhill 13y ago

goldenkey 13y ago

Standard programming model? Please stop. You have two options with CUDA, no one is tying your hands in a knot, NVidia doesn't have a committee setting standards on which of their 2 flavors of toolkit you need to use. You are so biased it hurts. Considering you use OpenCL at work every day it would help all the hackers here if you don't spread mistruths. There are no statics in opencl unless they are in constant memory and set in the program source. And we both know constant memory is quite limited and this fact would require you to interpolate your data into a byte array to sprintf it into source. There are no persistent global in opencl. You must pass all your globals to your kernel. We both know setKernelArg is persistent across kernel calls- but who cares? In CUDA you don't need an argument and you don't need to dereference it either. Way better. http://www.khronos.org/message_boards/showthread.php/6437-Global-variables-in-OpenCL http://www.khronos.org/message_boards/showthread.php/6437-Gl...

foxhill 13y ago
as in, it's not how any tutorial or walk through i've ever seen has tried to teach the user about CUDA, it's not something nvidia talk about primarily in their documentation of the language. if it's so common, why isn't it being used in rust? please, continue to make fallacious statements about me and what i think. i really don't care. regardless, there are three (not two) programming models in CUDA - high level (CUBLAS/FFT), CUDA runtime, and the driver API. constant memory is 64k on an M2050, a GPU from 3 years ago. if you want to set more than 16 thousand floating point constants.. well, you probably want to put that in main memory. i use OpenCL and CUDA, every day. and sorry for misunderstanding what you were saying, but really? you think passing in an argument is such a hassle? yes, setKernelArg is persistent across calls - so i'm confused why you're saying you don't care? it does exactly what you've been complaining it can't do (and, yes, it requires an extra kernel argument, oh my). you've been constantly bashing OpenCL - nothing more than a document, the contents of which are decided by a committee of people, none of whom are myself - implicitly praising CUDA, and you call me biased? you don't even know what i think about either of them.
- goldenkey 13y ago
  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.