I want to compile a few files to ptx, no host code needed.
I run
nvcc --ptx myfile.cu
nvcc fatal : Cannot find compiler ‘cl.exe’ in PATH
Why on earth do I need cl??? I’m only trying to to build GPU code, so this whole “cl” thing is unnecessary.
A host compiler is only needed when building host code, aka using the runtime API, neither of which I am interested in doing. Please forgive my arrogance, but I was extremely irritated to find this error. Previous versions of the CUDA toolkit worked this way without VC++. Is there a reason for the change?
I want to compile a few files to ptx, no host code needed.
I run
nvcc --ptx myfile.cu
nvcc fatal : Cannot find compiler ‘cl.exe’ in PATH
Why on earth do I need cl??? I’m only trying to to build GPU code, so this whole “cl” thing is unnecessary.
A host compiler is only needed when building host code, aka using the runtime API, neither of which I am interested in doing. Please forgive my arrogance, but I was extremely irritated to find this error. Previous versions of the CUDA toolkit worked this way without VC++. Is there a reason for the change?
I tried as you suggested. I’ve put an empty cl.exe in the same folder as nvcc. Then nvcc tells me that it can’t find vsvars32.bat to configure VC++.
I use CMake and kdevelop on an F13 box for the bulk of my work, but every now and then, I like to see if it works under M$. It doesn’t and it’s not my fault. There’s nothing I can do to make this work, and that’s what makes it frustrating.
I guess it’s time I start moving to OpenCL. CUDA is nice, but then things keep changing without notice too often.
I tried as you suggested. I’ve put an empty cl.exe in the same folder as nvcc. Then nvcc tells me that it can’t find vsvars32.bat to configure VC++.
I use CMake and kdevelop on an F13 box for the bulk of my work, but every now and then, I like to see if it works under M$. It doesn’t and it’s not my fault. There’s nothing I can do to make this work, and that’s what makes it frustrating.
I guess it’s time I start moving to OpenCL. CUDA is nice, but then things keep changing without notice too often.
But the ptx made on linux will be the same as on windows or not, so why should it not work under M$?
But I also think that running nvcc --ptx should NOT require a separate compiler to be installed. The new MATLAB parrallel computing toolbox for example has an option to call gpu kernels that are avaiable in a .ptx file, so I think that the whole system around CUDA has grown to such a state that only compiling gpu code to ptx should be supported.
But the ptx made on linux will be the same as on windows or not, so why should it not work under M$?
But I also think that running nvcc --ptx should NOT require a separate compiler to be installed. The new MATLAB parrallel computing toolbox for example has an option to call gpu kernels that are avaiable in a .ptx file, so I think that the whole system around CUDA has grown to such a state that only compiling gpu code to ptx should be supported.
Sarnath, I thank you for your suggestions, but the hacks are just too much. I was trying to understand if there is an elegant solution to this. Apparently, NVIDIA doesn’t think so. It’s their technology, and I cannot tell them how to use it. After a year and then months with CUDA, I have decided it’s downfalls outweigh its benefits. The path for me is OpenCL. In all honesty, this decision is probably also related to my discontent with how nvidia treats Linux, but this is for a different thread.
Riedijk,
There’s no problem with using linux-created .ptx or .cubin files in M$. My intent was to take advantage of CMake’s power to also allow the GPU code to compile with M$.
I partially agree with your second assertion, however, for those using the runtime API, this will mean hell. I remember the hell of switching to the driver API.
My problem with CUDA is more of a philosophical one. NVIDIA does everything to tie people to CUDA, so the next time they buy a GPU, it just has to be from Nvidia. I dislike nvidia for two reasons.
First, they take no effort in supporting free sotware drivers. My GeForce-powered PC has a very annoying issue of freezing. It does so more with the prorpietary driver than with nouveau. I actually suspect that in their attempt to duplicate the functionality of the blob, the nouveau people inadvertently copied the bug that does this.
Second, you get what you pay for, but a significant portion of the cost is the software advantage: CUDA, SLI, 3D, PhysX, you name it. All of the software advantage is proprietary, and I can’t use it (except for CUDA). Therefore, I get less than what I pay for.
To conclude, I would like to see more openness in CUDA, rather than changing minute details here or there.
(On a very off-topic side-note, my latest struggle with cuda is failures to load gpu code with cuLoadModule and segfaults in cuMemcpy2D – with code that previously worked flawlessly.)
Sarnath, I thank you for your suggestions, but the hacks are just too much. I was trying to understand if there is an elegant solution to this. Apparently, NVIDIA doesn’t think so. It’s their technology, and I cannot tell them how to use it. After a year and then months with CUDA, I have decided it’s downfalls outweigh its benefits. The path for me is OpenCL. In all honesty, this decision is probably also related to my discontent with how nvidia treats Linux, but this is for a different thread.
Riedijk,
There’s no problem with using linux-created .ptx or .cubin files in M$. My intent was to take advantage of CMake’s power to also allow the GPU code to compile with M$.
I partially agree with your second assertion, however, for those using the runtime API, this will mean hell. I remember the hell of switching to the driver API.
My problem with CUDA is more of a philosophical one. NVIDIA does everything to tie people to CUDA, so the next time they buy a GPU, it just has to be from Nvidia. I dislike nvidia for two reasons.
First, they take no effort in supporting free sotware drivers. My GeForce-powered PC has a very annoying issue of freezing. It does so more with the prorpietary driver than with nouveau. I actually suspect that in their attempt to duplicate the functionality of the blob, the nouveau people inadvertently copied the bug that does this.
Second, you get what you pay for, but a significant portion of the cost is the software advantage: CUDA, SLI, 3D, PhysX, you name it. All of the software advantage is proprietary, and I can’t use it (except for CUDA). Therefore, I get less than what I pay for.
To conclude, I would like to see more openness in CUDA, rather than changing minute details here or there.
(On a very off-topic side-note, my latest struggle with cuda is failures to load gpu code with cuLoadModule and segfaults in cuMemcpy2D – with code that previously worked flawlessly.)
Well, I am also doing just that, I mostly use CUDA from Matlab and have cmake to make it work on both windows and linux, 32 and 64 bit. But I have VS Express installed to be able to compile on windows. It’s more work than installing a linux version (especially to get VS Express to compile 64bit), but that is more a M$ problem than an NVIDIA one.
If you are going to use OpenCL on windows, you will also need a compiler to compile your host code, so you will still need something like VS Express.
Well, it was clearly stated on this forum a few times that NVIDIA will support OpenCL (hey, they were first to provide a driver), but new features will first come to CUDA, later (if possible) to OpenCL. You might call that tying in people, but it is in fact very simple, it is much easier to expand a language when you don’t have to go through a committee as with OpenCL.
AMD may be more forthcoming with help in developing open source drivers (I was very skeptical when starting with CUDA because of the closed-source drivers) but I think that an open source driver for a GPU, supporting OpenCL will not happen in the coming (let’s say 5-7) years.
Apart from that there are performance issues as I understand it. I have seen a talk by a person from Astron who has compared IBM Blue Gene/P, ATI, NVIDIA, Cell (and I think I forget a platform). He wrote assembly code for all of the platforms (ptx for NVIDIA, CTM? for ATI). When asked if he tried CUDA and OpenCL, he told that the CUDA code had 97% performance compared to the hand-written optimized code. The OpenCL code on ATI came at around 50% of the performance of the hand-written code.
For us just an extra reason to stay with CUDA as we can buy Tesla and have excellent support (we have very good experiences).
Well, I am also doing just that, I mostly use CUDA from Matlab and have cmake to make it work on both windows and linux, 32 and 64 bit. But I have VS Express installed to be able to compile on windows. It’s more work than installing a linux version (especially to get VS Express to compile 64bit), but that is more a M$ problem than an NVIDIA one.
If you are going to use OpenCL on windows, you will also need a compiler to compile your host code, so you will still need something like VS Express.
Well, it was clearly stated on this forum a few times that NVIDIA will support OpenCL (hey, they were first to provide a driver), but new features will first come to CUDA, later (if possible) to OpenCL. You might call that tying in people, but it is in fact very simple, it is much easier to expand a language when you don’t have to go through a committee as with OpenCL.
AMD may be more forthcoming with help in developing open source drivers (I was very skeptical when starting with CUDA because of the closed-source drivers) but I think that an open source driver for a GPU, supporting OpenCL will not happen in the coming (let’s say 5-7) years.
Apart from that there are performance issues as I understand it. I have seen a talk by a person from Astron who has compared IBM Blue Gene/P, ATI, NVIDIA, Cell (and I think I forget a platform). He wrote assembly code for all of the platforms (ptx for NVIDIA, CTM? for ATI). When asked if he tried CUDA and OpenCL, he told that the CUDA code had 97% performance compared to the hand-written optimized code. The OpenCL code on ATI came at around 50% of the performance of the hand-written code.
For us just an extra reason to stay with CUDA as we can buy Tesla and have excellent support (we have very good experiences).
Same holds for CUDA. However, not needing to use nvcc for GPU code greatly simplifies the issue. nvcc only works with MSVC 8 and 9. Take that out of the equation, and you factor in all other MSVC versions, cygwin, mingw32 and mingw64.
I have nothing against OpenCL moving at a slower pace - “slower” is debatable. The upside of “slower” is that it’s harder to break backwards compatibility. Of course, my root concern is that I don’t like being “tied in”. If I go tomorrow and buy an AMD card, I want my code to work on it.
OpenCL involves far more coding effort, indeed. As an idiot closed-source developer told me, “Your linux is only free if your time has no value.” I will never get over the elegance of CUDA. It is by far the best GPGPU API: all functions returning an error code, runtime-link code in the SDK, templates in GPU code, a rocket boosted profiler, etc. It’s like that Bentley that has one too few power outlets.
I am a little more optimistic than that. Still, looking ahead, I may develop today using proprietary drivers, but in the future this will not be an issue, when open source drivers will start blossoming. I honestly don’t understand NVIDIA in keeping closed-source drivers, and much less AMD, which still has closed-source drivers after making an effort to help the opensource community in this regard.
I will not argue on this. I’m curious how my code will do on OpenCL, and in all honesty, I will test it first on my NVIDIA GPUs.
I’m not attempting to start a CUDA boycott. I have my reasons for departing from it, and I don’t expect anyone to follow, but I see no harm in voicing my discontent.
Same holds for CUDA. However, not needing to use nvcc for GPU code greatly simplifies the issue. nvcc only works with MSVC 8 and 9. Take that out of the equation, and you factor in all other MSVC versions, cygwin, mingw32 and mingw64.
I have nothing against OpenCL moving at a slower pace - “slower” is debatable. The upside of “slower” is that it’s harder to break backwards compatibility. Of course, my root concern is that I don’t like being “tied in”. If I go tomorrow and buy an AMD card, I want my code to work on it.
OpenCL involves far more coding effort, indeed. As an idiot closed-source developer told me, “Your linux is only free if your time has no value.” I will never get over the elegance of CUDA. It is by far the best GPGPU API: all functions returning an error code, runtime-link code in the SDK, templates in GPU code, a rocket boosted profiler, etc. It’s like that Bentley that has one too few power outlets.
I am a little more optimistic than that. Still, looking ahead, I may develop today using proprietary drivers, but in the future this will not be an issue, when open source drivers will start blossoming. I honestly don’t understand NVIDIA in keeping closed-source drivers, and much less AMD, which still has closed-source drivers after making an effort to help the opensource community in this regard.
I will not argue on this. I’m curious how my code will do on OpenCL, and in all honesty, I will test it first on my NVIDIA GPUs.
I’m not attempting to start a CUDA boycott. I have my reasons for departing from it, and I don’t expect anyone to follow, but I see no harm in voicing my discontent.