I wanna know what do you prefer to choose for an OpenGL integration. Some time ago, I read that OpenCL had an optimal integration with OpenGL, because of they belong to the same company, but I also read that CUDA has got a very good performance with using NVIDIA's graphics cards. So, If I have got a NVIDIA card, and I want to develop with graphics, what should I choose? OpenCL or CUDA?
Can you give the benefits of the using of OpenCL + OpenGL, and disadvantages of CUDA + OpenGL or vice versa?
Remember, we're working with NVIDIA's platform.
opencl and opengl technically are standards maintained by khronos groups, khronos group is made from several companies representative .
i don't know if nvidia is optimizing its cuda implementation more than its own opencl implementation but Nvidia has opencl for its cards and of course and you can use either opencl or cuda for your device.
if you are learning CUDA / OPENCL from the beginning i would go for opencl ( because it follows a standard implemented by multiple company and NVIDIA implements it as well ).
but if you already know CUDA, just go ahead and implement your code and get your project going and later on worry about cross platforms issues.
and this posts has everything
OpenCL or CUDA Which way to go?
Related
I have a relatively small section of code that deals with huge datasets which I've already parallelized using openmp and am keen to increase performance further using the GPU. The program is C++, developed under VS2015, runs exclusively on Windows and will need to support 64 bit versions from 7 upwards on as wide a variety of GPUs as is feasible. Technologies I've been looking at so far include AMP, OpenCL, HLSL, and CUDA. Questions already asked, such as this with an informative answer by Ade Miller, make me question whether AMP is the way to go although it looks like the easiest option. I'm dismissing CUDA as it limits me in terms of hardware supported, and am tending towards OpenCL while currently working my way through the following book. As such, I've the following questions;
Is OpenCL a good approach here, as other posts suggest it may also be on the way out?
If I go for OpenCL while wanting to support the widest range of GPUs, am I better off with a 1.x version of OpenCL? Reason I ask this is that the OpenCL.DLL downloaded with the latest version of the CUDA SDK is 1.9. I had to download the Intel SDK for OpenCL to get a 2.x version.
If I go with OpenCL, what do I have to distribute with my application (assuming OpenCL.DLL as a minimum) and are there any licensing issues? Are default drivers for most cards going to support OpenCL and if so which versions?
With respect to the above, am I actually better of with AMP, as it works with anything that has DirectX 11 or better?
(Apologies if the above is slightly off topic, if anyone believes that it is perhaps they could point me to a better forum to ask these questions)
Is OpenCL a good approach here, as other posts suggest it may also be on the way out?
OpenCL seems to be most widely supported GPU computing platform. Supported by nVidia, AMD and Intel. Works on most mobile platforms as well. It is also large set of libraries available: ViennaCL, clBLast, clBlast, Boost-Compute and so on.
If I go for OpenCL while wanting to support the widest range of GPUs, am I better off with a 1.x version of OpenCL?
Yes, currently the safest is to stick with 1.2 - and actually it is more then enough.
All major desktop GPU vendors (Intel, AMD, nVidia) support at least OpenCL 1.2.
Actually only nVidia didn't released official 2.0 support - it is still in beta stage.
Also note that some older GPUs will support OpenCL 1.2 only as well.
I'm started looking for docs for OpenGL ES learning, I came across lot of links. one of them has explained like "OpenGL need to be supported by the vendors of Graphics Cards (like NVidia) and be implemented by the OS's vendors (like Apple in his MacOS and iOS) and finally, the OpenGL give to us, developers, a unified API to work with".
what does it mean by?
OpenGL need to be supported by the vendors of Graphics Cards (like NVidia)
Is it something different to normal code libraries execution?
be implemented by the OS's vendors (like Apple in his MacOS and iOS)...
Is this OS's vendor specific?
If all implementation was done by vendors, what does actually OpenGL ES will do?
I was thinking OpenGLES is a library, which needs to install in required OS and using the specific EGL API's, we need to call them? isn't it?
finally the OpenGL give to us, developers, a unified API to work with
If Os itself developing everything, why to go for OpenGL ES?
Please explain, possibly with an example.
Unlike his name suggests, OpenGL is not a library. Or better, it is cause some symbols for the functions you use need to be linked to the executable.
But OpenGL is a standard de facto library, and a great part of the OSes have a good part of the implementation in their kernel. OSX and iOS provide the OpenGL.framework and GLKit.framework to interface with OpenGL
Architecture Review Board ARB just gives specification of OpenGL. This means It tells what should be name of function which parameters it should accept and what is desired behavior. All the Graphics card vendors take this specification and implement this api. Here function interface and high level working is defined by ARB but internal implementation of API is done depending upon the hardware of vendor. Now this OpenGL API goes into driver. Drivers are generally implemented as Operating system interface part and hardware interface part. So Operating system also need some support for this driver.
I understand that AMD created an alternative implementation of OpenCL that runs on x86 CPUs. This is very useful from the standpoint of simplified debugging. Unfortunately, OpenCL isn't an option for me.
Are there any Open GL x86 implementations in existence? This would greatly ease my development process, at the cost of some CPU time, of course. I would then run the same code on a GPU, later, with no changes necessary.
Mesa might be an option for you.
From their website:
Mesa is the OpenGL implementation for several types of hardware made by Intel, AMD and NVIDIA, plus the VMware virtual GPU. There's also several software-based renderers: swrast (the legacy Mesa rasterizer), softpipe (a gallium reference driver) and llvmpipe (LLVM/JIT-based high-speed rasterizer).
When using Mesa you can set the LIBGL_ALWAYS_SOFTWARE environment variable, which will cause Mesa to "always use software rendering".
OpenGL is not an instruction set, neither is it a library. It's a drawing API for interfacing with GPUs (yes there are software based rasterizers like Mesa softpipe). Most computers you can find these days support OpenGL.
When you use the OpenGL API it's not like your OpenGL calls get "translated" into a special instruction set for the GPU that's then part of your program. OpenGL operations will just create calls that eventually end up in a device driver, just like reading or writing to a file.
I read that Microsoft is closely working with Nvidia to improve AMP performances.
But my question is: is AMP a CUDA-replace by Microsoft? Or does AMP use CUDA drivers when a NVIDIA CUDA video card is available? Is AMP an openCL substitute?
I'm still pretty confused..
C++ AMP is a library (and as part of it a key language extension was also introduced). Since C++ AMP is an open specification, it can be implemented on any other low level languages. Microsoft’s implementation builds on DirectCompute (and hence on HLSL), but that is completely hidden from you when you are using C++ AMP (which is why C++ AMP can be an open specification; it does not expose DirectX in the API surface). For more on C++ AMP, please follow the resources on the right of our blog (we’ll keep adding to that):
http://blogs.msdn.com/b/nativeconcurrency/
You made a statement about Microsoft working with NVIDIA to improve C++ AMP performance – that is not true. Microsoft has worked with NVIDA and AMD and other partners to create the C++ AMP open specification. Microsoft also work with hardware vendors to make sure that the hardware vendors have stable video card drivers, which are required for any GPU compute technology to work correctly.
You also expressed confusion and threw some terms out. OpenCL is an approach to GPU computing (by Khronos), as is DirectCompute (by Microsoft), as is CUDA (by NVIDIA). These are all separate technologies, each with its own path to the GPU (always via a driver of some sort), each with its own merits, strengths, and disadvantages. One does not replace the other, and one is not universally better than the other. You now also have C++ AMP in that mix, as one more choice, and the same statements apply to that. The choice is yours as to which you decide to use.
C++ AMP is a set of language extentions and APIs to support parallel programming technology including CUDA.
Since Microsoft also has a direct competitor to CUDA ( Direct Compute) and generally has preferred it's own proprietary graphics standards we will have to see what actually ever happens with it.
For Microsoft's view on it see these lectures
I've been thinking of making an additional wrapper for my project to use OpenGL rather then Allegro. I was not sure which OpenGL version to go for since I know that some computers cannot run recent versions such as v4.4. Also, I need a version which compiles no problem in Linux, Windows, Mac.
You'll want to look at what kinds of graphics cards will be available on your target systems and bear some details in mind:
OpenGL up to 1.5 can be completely emulated in software in real time on most systems. You don't necessarily need hardware support for good performance.
OpenGL 1.4 has universal support. Virtually all hardware supports it.
Mac OS X only supports up to OpenGL 2.0 and OpenGL 2.1, depending on OS version and hardware. Systems using GMA950 have only OGL1.4 support. Mac OS X Lion 10.7 supports OpenGL 3.2 Core profile on supported hardware.
On Linux, it's not unusual for users to specifically prefer open source drivers over the alternative "binary blobs," so bear in mind that the version of Mesa that most people have supports only up to about OpenGL 2.1 compatibility. Upcoming versions have support for OpenGL 3.x. Closed-source "binary blobs" will generally support the highest OpenGL version for the hardware, including up to OpenGL 4.2 Core.
When considering what hardware is available to your users, the Steam hardware Survey may help. Note that most users have DirectX 9-compatible hardware, which is roughly feature-equivalent to OpenGL 2.0. Wikipedia's OpenGL article also specifies what hardware came with initial support for which versions.
If you use a library like GLEW or GLEE or any toolkit that depends on them or offers similar functionality (like SFML, or even Allegro since 4.3), then you'll not need to concern yourself with whether your code will compile. These toolkits will take care of the details of enabling extensions and providing all of the symbols you need.
Given all of this, I'd suggest targeting OpenGL 2.1 to get the widest audience possible with the best feature support.
Your safe bet is OpenGL 2.1, it needs to be supported by the driver on your target system though. OpenGL ES, used on several mobile platforms, is basically a simplified OpenGL 2, so even porting to those would be fairly easy. I highly recommend using libGlew as VJo said.
It's less about operating systems, and more about video card drivers.
I think 1.4 is the highest version which enjoys support by all consumer graphics systems: ATI (AMD), nVidia, and Intel IGP. Intel is definitely the limiting factor here, even when ATI or nVidia doesn't have hardware support, they release OpenGL 4.1 drivers which use software to emulate the missing features. Not so with Intel.
OpenGL is not a library you usually compile and ship yourself (unless you're a Linux distributor and are packaging X.Org/Mesa). Your program just dynamically links against libGL.so (Linux/BSD), opengl32.dll (Windows, on 64 Bit systems, it's also calles opengl32.dll, but it's in fact a 64 Bit DLL) or the OpenGL Framework (MacOS X). This gives your program access to the system's OpenGL installation. The version/profile you want to use has no influence on the library you link!
Then after your program has been initialized you can test, which OpenGL version is available. If you want to use OpenGL-3 or 4 you'll have to jump a few additional hoops in Windows to make full use of it, but normally some kind of wrapper helps you with context creation anyway, boiling it down to only a few lines.
Then in the program you can implement multiple code paths for the various versions. Usually lower OpenGL verion codepaths share a large subset with higher version codepaths. I recommend writing new code in the highest version available, then adding additional code paths (oftenly just substitutions which can be done by C preprocessor macros or similar) for lower versions until you reach the lowest common denominator of features you really need.
Then you need to use OpenGL 1.1, and use needed (and supported) functions through the use of wglGetProcAddress (on windows) or glXGetProcAddress (on linux).
Instead of using those two functions, you can use GLEW library, which does that for you and is cross platform.