Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 9 months ago.
The community reviewed whether to reopen this question 2 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
What is the best way to do programming for GPU?
I know:
CUDA is very good, much developer support and very nice zo debug, but only on NVidia Hardware
OpenCL is very flexible, run on NVidia, AMD and Intel Hardware, run on Accellerators, GPU and CPU but as far as I know not supported anymore by NVidia.
Coriander (https://github.com/hughperkins/coriander) which converts CUDA to OpenCL
HIP https://github.com/ROCm-Developer-Tools/HIP is made by AMD to have a possibility to write in a way to convert to AMD and NVidia CUDA. It also can convert CUDA to HIP.
OpenCL would my prefered way, I want to be very flexible in hardware support. But if not longer supported by NVidia, it is a knockout.
HIP sounds then best to me with different released files. But how will be the support of Intels soon coming hardware?
Are there any other options?
Important is for me many supported hardeware, long term support, so that can be compiled in some years also and manufacture independant.
Additional: Should be able to use more than obe compiler, on Linux and Windows supported.
Nvidia won't cancel OpenCL support anytime soon.
A newly emerging approach for portable code on GPU is SYCL. It enables higher level programming from a single source file that is then compiled twice, once for the CPU and once for GPU. The GPU part then runs on GPU via either OpenCL, CUDA or some other backend.
As of right now however, the best supported GPU framework across plattforms is OpenCL 1.2, which is very well established at this point. With that your code runs on 10 year old GPUs, on the latest and fastest data-center GPUs, on gaming and workstation GPUs and even on CPUs if you need more memory. On Nvidia GPUs there is no performance/efficiency tradeoff at all compared to CUDA; it runs just as fast.
The porting tools like HIP are great if you already have a large code base, but performance could possibly suffer. My advice is to go for either one framework and stay fully committed to it, rather than using some tool to then generate a possibly poorly optimized port.
If you choose to start with OpenCL, have a look at this OpenCL-Wrapper. The native OpenCL C++ bindings are a bit cumbersome to use, and this lightweight wrapper simplifies learning a lot, while keeping functionality and full performance.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I installed a new Intel Xeon Phi in a work station which already has 3 Nvidia GPUs installed. To make the Phi card work, I have to load the Intel's MIC kernel module into my Linux kernel. And by doing so the Phi card works fine. However, every time when we reboot the system, we just couldn't use the GPU. The error message is that the system couldn't find the CUDA driver.
However, the only thing I need to do to fix this is to use "SUDO" to run one CUDA binaries or some Nvidia's command just like "sudo nvida-smi". Then everything just works fine, both CUDA and Intel's Xeon phi.
Anybody knows why? Without my sudo command, other people just can not use the GPUs. This is kind of annoying. How can I fix this?
CUDA requires that certain resource files be established for GPU usage, and this is covered in the Linux getting started guide (step 6 under runfile installation -- note the recommended startup script).
You may also be interested in this article, which focuses on the same subject -- how to automatically establish the resource files at startup.
Once these files are established correctly, an ordinary user (non-root) will be able to use the GPUs without any other intervention.
I have no idea why Xeon Phi installation might have affected this in your particular setup.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
Can I use nVidia CUDA on QNX(x86_64 or other) and what driver do I need for this?
I found nothing about this by link, and in #46 answer sound like "I don't know"
http://www.qnx.com/news/web_seminars/faq_multicore.html
But, QNX thinks to Include Support for NVIDIA Tegra Processor Family:
http://www.qnx.com/news/pr_5306_1.html
And nVidia thinks to add support CUDA and OpenCL to the nVidia Tegra5(Logan) ARM+GK1xx in next year:
http://en.wikipedia.org/wiki/Tegra#Logan
http://www.ubergizmo.com/2013/07/nvidia-tegra-5-release-date-specs-news/
And then can we use CUDA on nVidia Tegra5(ARM+GK1xx) on QNX(ARM), and what about QNX(x86)?
At this time, there's no support for CUDA on QNX.
The supported operating systems for CUDA are listed on the cuda download page as well as in section 1.4 of the release notes
Regarding Tegra, at this time there are no Tegra devices that support CUDA. The list of CUDA-enabled GPUs is here. Whether using an x86/x86_64 CPU or an ARM CPU, one of these CUDA GPUs is required for CUDA support.
Update: There are now tegra devices that support CUDA, including the widely available Tegra TK1 and recently announced TX1.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 6 years ago.
Improve this question
what is "SASS" short for ?
I know it is an asembly level native code ISA targeting specific hardware,
exits in between PTX code and binary code.
but anyone could kindly tell me what does each character stands for ?
all that i can find about Fermi hardware native instruction is in cuobjdump.pdf, but it only gives their names, where can I find more information such as their throughput or latency or IPC or CPI, undertaking units corresponding to each intruction, like SFU, FPU ?
Streaming ASSembler.... I should know since I invented the term, lead the core team G80 streaming process architecture team and developed first SASS assembler ;-)
Since there seems to be no information on this anywhere, I can only guess: Shader ASSembly language
SASS (as Ashwin points out probably "Shader ASSembly") is the binary code that runs on the metal of Fermi architecture devices. What cudaobjdump (and older third party tools like decuda and nv50dis) show is a direct disassembly of the cubin payload emitted by the ptxas assembler.
To the best of my knowledge there is no open instruction set documentation for any NVIDIA GPUs.
At some point during the CUDA 5 release cycle, NVIDIA began to provide a summary document which annotates the basic instruction set of suported GPUs (Fermi, Kepler, and Maxwell as of CUDA 7).
Streaming ASSembly? Since NVIDIA calls their cores, "Streaming Multiprocessors".
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I know CUDA is for only Nvidia GPUs. If the specifications for a Nvidia graphics card states that CUDA is supported, can we conclude that it also supports OpenCL? Can there be support/compatibility problems with different OpenCL versions? i.e. OpenCL 1.0 or 1.1?
Given that in version 4.1 of the OpenCL Programming Guide (PDF) Nvidia explicitly speaks about CUDA-Enabled GPUs (Especially in Appendix A), I think we can safely assume that those cards supporting CUDA also support OpenCL. Even more so since OpenCL on Nvidia hardware still makes use of the CUDA architecture.
Appendix C of the same document lists the support of various extensions given a specific compute capability.
According to Nvidia's OpenCL page (http://developer.nvidia.com/opencl), all CUDA devices support OpenCL. As far as OpenCL versioning, that page indicates that you just need to make sure you have the right driver version.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I first got into GPGPU with my (now aging) NVIDIA 9800GT 512MB via CUDA. It seems these days my GPU just doesn't cut it.
I'm specifically interested in OpenCL, as opposed to CUDA or StreamSDK, though some info on whether either of these are still worth pursuing would be nice.
My budget is around 150 GBP plus/minus 50 GBP. I'm a little out of the loop on which GPUs are best for scientific computing (specifically fluid simulation and 3D medical image processing).
A comparison of ATI vs. NVIDIA may also be helpful, if they are really so disparate.
[I'd also be interested to hear any suggestions on games that make use of GPGPU capabilities, but that's a minor issue next to the potential for scientific computing.]
I'm also a little lost when it comes to evaluating the pros/cons of memory speed vs. clock speed vs. memory capacity, etc, so any info with regard to these more technical aspects would be most appreciated.
Cheers.
If you were going purely off OpenCL being the requirement, I would say you go with ATI because they have a released version of OpenCL 1.1 drivers where as nVidia had beta drivers almost instantly when the spec was published, but has not updated them since and they have a couple bugs from what I've read in the nVidia open OpenCL forums.
Personally I chose nVidia because it gives me all the options. You really ought to check out CUDA. It's a far more productive approach to leveraging the GPU and CPU using a common language. Down the road Microsoft's AMP language extensions for C++ are going to provide the same sort of approach as CUDA in a more platform agnostic way though and I'm sure that will be more widely adopted by the community at that point than CUDA.
Another reason to choose nVidia is because that's what the HPC system builders have been building systems with since nVidia made a huge push for GPGPU computing where as it's less backed by AMD/ATI. There really is no answer to the Tesla lineup from that camp. Even Amazon EC2 offers a GPU compute cluster based on Tesla. So, if you're looking for reach and scale beyond the desktop, I think nVidia is a better bet.