3 ms·

I'm afraid there isn't a single best place. What is important first is to learn how GPU architecture is different from traditional before you start learning Cud

by cpcat 10y ago

I'm afraid there isn't a single best place. What is important first is to learn how GPU architecture is different from traditional before you start learning Cuda or linear algebra. Take a look at these sources for absolute beginners. https://thebookofshaders.com/ https://thebookofshaders.com/ http://duriansoftware.com/joe/An-intro-to-modern-OpenGL.-Table-of-Contents.html http://duriansoftware.com/joe/An-intro-to-modern-OpenGL.-Tab... http://learnopengl.com/ http://learnopengl.com/ edit: also when you are ready to pick a language and start writing code, i advise using the universal OpenGL over Cuda.

valine 10y ago
Would you recommend OpenGL? I was under the impression that OpenCL was the equivalent of Cuda and OpenGL was specifically for 2d / 3d rendering.
- hubatrix 10y ago
  Yes my thoughts are the same, so I decided to learn CUDA and port to OpenCL if necessary
- saltcured 10y ago
  I imagine it was a typo, but... I personally have found PyOpenCL and the vispy.gloo OpenGL APIs to be very convenient together (along with Numpy and Scipy of course). If it fits your goals, a useful mental model is that you are programming Numpy ndarray data, and all these tools just fit together to let you manage the data elements, apply transforms, and view them. You should be thinking about the math that solves your domain problem, using alternative mathematical formulations to optimize your algorithms, and only then worrying about using a tuned parallel implementation of that math. I prototype new ideas and visualize results and intermediate data very easily, with easy transitions between using numpy/scipy routines, custom OpenCL kernels, and OpenGL shaders. I've even found myself using OpenGL to do the visual equivalent of "printf debugging" to look at intermediate array results when developing new array operations and wondering what I've done wrong or misunderstood about the problem. It's very instructive to create little sub-problems you can run as independent scripts during dev/test/microbenchmarking cycles. You should iterate on many small experiments, not assume you can design high-performance solution in one top-down adventure. For high performance processing, you eventually need to understand architecture limitations and the impact of different problem decompositions. Non-trivial, multi-dimensional problems need to be decomposed into smaller blocks to get better cache locality for the vectorized/parallel code that will process each block. Otherwise, you won't enjoy the benefits of parallel hardware as all the compute units are stalled waiting for data fetches. I find myself doing more and more meta-programming in Python, where I reason about array shapes and sizes, compute slicing geometries, and then loop to extract and dispatch chunks of data to OpenCL jobs which in turn use a dense form of SIMD or SPMD execution on that block. Python is great for this kind of marshaling work. Also, PyOpenCL makes it trivial to switch between backend drivers. The Intel OpenCL driver is quite good on recent laptop and server CPUs. You might be surprised how much performance you can get out of recent i5/i7 or Xeon E3/E5 CPUs when you use all cores and all SIMD units effectively. Plus, the CPU backend is able to use all system RAM and has a more uniform cache behavior, which makes it more forgiving for badly decomposed problems compared to GPU. This can be a big help for prototyping as well as for limited-run problems where you don't have time to invest in fully tuning your data structures for GPU requirements.
  - joe_the_user 10y ago
    If you read the op, their reference to OpenGl isn't a typo, they are linking to books and articles on OpenGl and recommending learning this before Cuda.
joe_the_user 10y ago
I'm just starting with learning gpgpu programming myself but I'm replying because your advice seems wildly off-base. Your links are full books on graphics-processing algorithms, not introductions-to-architecture which must come before using Cuda or gpgpu programming effectively. That you don't seem to know the difference between OpenGL and OpenCL hardly makes your claims more plausible. Anyway, Cuda is a general purpose framework as is OpenCL. OpenGL is a 3D graphics framework and different from both. Looking at these structure, Cuda is architected to allow straight forward general general purpose parallel computing - one has to know the broad structure of a GPU but one doesn't have to know all the principles of graphics programming. OpenCL is similar but more complex due to its efforts to take multiple processors into account. As far as I can tell, using Cuda is the simplest path to general purpose GPU computing (the op didn't do any favors by not really saying what kind of GPU computing he wanted to learn - he did say Cuda later - but your post seems confused regardless of what thing someone ultimately wants to learn).

by cpcat 10y ago

valine 10y ago

Would you recommend OpenGL? I was under the impression that OpenCL was the equivalent of Cuda and OpenGL was specifically for 2d / 3d rendering.

hubatrix 10y ago
Yes my thoughts are the same, so I decided to learn CUDA and port to OpenCL if necessary
saltcured 10y ago
I imagine it was a typo, but... I personally have found PyOpenCL and the vispy.gloo OpenGL APIs to be very convenient together (along with Numpy and Scipy of course). If it fits your goals, a useful mental model is that you are programming Numpy ndarray data, and all these tools just fit together to let you manage the data elements, apply transforms, and view them. You should be thinking about the math that solves your domain problem, using alternative mathematical formulations to optimize your algorithms, and only then worrying about using a tuned parallel implementation of that math. I prototype new ideas and visualize results and intermediate data very easily, with easy transitions between using numpy/scipy routines, custom OpenCL kernels, and OpenGL shaders. I've even found myself using OpenGL to do the visual equivalent of "printf debugging" to look at intermediate array results when developing new array operations and wondering what I've done wrong or misunderstood about the problem. It's very instructive to create little sub-problems you can run as independent scripts during dev/test/microbenchmarking cycles. You should iterate on many small experiments, not assume you can design high-performance solution in one top-down adventure. For high performance processing, you eventually need to understand architecture limitations and the impact of different problem decompositions. Non-trivial, multi-dimensional problems need to be decomposed into smaller blocks to get better cache locality for the vectorized/parallel code that will process each block. Otherwise, you won't enjoy the benefits of parallel hardware as all the compute units are stalled waiting for data fetches. I find myself doing more and more meta-programming in Python, where I reason about array shapes and sizes, compute slicing geometries, and then loop to extract and dispatch chunks of data to OpenCL jobs which in turn use a dense form of SIMD or SPMD execution on that block. Python is great for this kind of marshaling work. Also, PyOpenCL makes it trivial to switch between backend drivers. The Intel OpenCL driver is quite good on recent laptop and server CPUs. You might be surprised how much performance you can get out of recent i5/i7 or Xeon E3/E5 CPUs when you use all cores and all SIMD units effectively. Plus, the CPU backend is able to use all system RAM and has a more uniform cache behavior, which makes it more forgiving for badly decomposed problems compared to GPU. This can be a big help for prototyping as well as for limited-run problems where you don't have time to invest in fully tuning your data structures for GPU requirements.
- joe_the_user 10y ago
  If you read the op, their reference to OpenGl isn't a typo, they are linking to books and articles on OpenGl and recommending learning this before Cuda.

joe_the_user 10y ago

I'm just starting with learning gpgpu programming myself but I'm replying because your advice seems wildly off-base. Your links are full books on graphics-processing algorithms, not introductions-to-architecture which must come before using Cuda or gpgpu programming effectively. That you don't seem to know the difference between OpenGL and OpenCL hardly makes your claims more plausible. Anyway, Cuda is a general purpose framework as is OpenCL. OpenGL is a 3D graphics framework and different from both. Looking at these structure, Cuda is architected to allow straight forward general general purpose parallel computing - one has to know the broad structure of a GPU but one doesn't have to know all the principles of graphics programming. OpenCL is similar but more complex due to its efforts to take multiple processors into account. As far as I can tell, using Cuda is the simplest path to general purpose GPU computing (the op didn't do any favors by not really saying what kind of GPU computing he wanted to learn - he did say Cuda later - but your post seems confused regardless of what thing someone ultimately wants to learn).