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.
Related
In order to save power it is common in recent graphics architectures to dynamically switch between a discrete high-performance and an integrated lower-performance GPU, where the high-performance GPU is only enabled when the need for extra performance is present.
This technology is branded as nvidia Optimus and AMD Enduro for the two main GPU vendors.
However due to the non-standardized way in which these technologies work, managing them from a developer's perspective can be a nightmare. For example in this PDF from nvidia on the subject, they explain the many intricacies, limitations and pitfalls that you will have to worry about as a developer to manage nvidia Optimus on just one platform.
As an example, in the linked PDF above, the following is a tip for selecting GPU on Windows:
extern "C" {
_declspec(dllexport) DWORD NvOptimusEnablement = 0x00000001;
}
However that will only work for nvidia GPUs on Windows platform. What would be the equivalent for AMD/Intel on OSX/Linux, and on AMD hardware?
So in more detail my question is, how can I
Detect the presence of Optimus/Enduro and possibly other dynamically=switching GPU architectures programmatically?
Select which of the GPUs should be enabled programmatically?
Do so in a manner that is cross-platform over all relevant platforms?
Do so in a manner that works together with all technologies that might use GPU such as DX/OpenGL/Vulkan/OpenCL/CUDA/Qt?
I am working with C++14/Qt5.7 codebase under Ubuntu 16.04-amd64 using nVidia hardware.
I have developed a program which makes use of many of OpenGL's aspects - ranging from both rather new to deprecated functionalities, and want to ensure that it works correctly on the great majority of machines - especially on ones with outdated graphics cards.
What is the best way to maximize the (backwards)compatibility of an OpenGL application?
How can I test my program for compatibility with older hardware without actually having a test machine with older hardware?
What ways are there to find the underlying causes of the issues which may be encountered during compatibility testing?
What is the best way to maximize the (backwards)compatibility of an OpenGL application?
Define "compatibility"? If you want an application to run on as much hardware as possible, then you basically have to give up on shaders entirely and stick to about GL 1.4. The main confounding issue here are Intel driver bugs; many pieces of older Intel hardware will claim support for GL 2.0 or 2.1, but they have innumerable failings in this support.
How can I test my program for compatibility with older hardware without actually having a test machine with older hardware?
You don't. Compatibility with old hardware is about more than just sticking to a standard. It's about making sure that your program doesn't encounter driver bugs. And the only way to do that is to actually test on the hardware of interest.
What ways are there to find the underlying causes of the issues which may be encountered during compatibility testing?
Test the same code on recent hardware. If it has the same failures, then the problem is likely in your code. If it works fine on recent hardware but fails on older stuff, then the problem is almost certainly a driver bug with old hardware drivers.
Develop a workaround.
Well, the best way to maximize the backwards compatibility and to get a powerful tool on tracking down target machine's functionality (imho) is to use something like GLEW: The OpenGL Extension Wrangler Library. It will load OpenGL version-specific functions for you and you can test if they are supported by user's system (or, more correctly, by video drivers).
This library is very simple in use, it is well documented and you can google a lot of examples.
So if target machine doesn't have some new opengl functions, you load module named "opengl_old.cpp" (for example), or if it don't have some functionality which is already deprecated (like glBegin(), glEnd()), you'd better go on with "opengl_new.cpp".
Basically the most changes are done in OpenGL 3.0 (and furthermore 3.3) with shaders introduced as the only non-deprecated graphics pipeline, so you can make two opengl modules in your program: one for OpenGL 1&2 and one for OpenGL 3&4. At least I solved this problem in this way in my own code.
To test some functionality you can specify concrete version of OpenGL API to be loaded, when creating context.
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?
If i have a software implementation and if also have a graphic card which supports opengl , then which of these is used by the opengl?
This is both a simple and a complicated question. The simple answer is that OpenGL neither knows nor cares. OpenGL is not a thing; it is a document. A specification. Implementations of OpenGL are things.
Which brings up the complicated part. How you talk to an OpenGL implementation depends on what platform you live on. MesaGL can be compiled as nothing more than a library you link to.
If you want hardware acceleration, then you now have to deal with the OS, because the OS owns the GPU. Mesa as a driver is implemented through the glX system. It hooks into X-windows and X-windows' OpenGL context creation functions can give you a context that is implemented by software Mesa drivers. Or by hardware Mesa drivers. If you're using other drivers, then they too hook into X-windows. These are all tied into X-windows "displays".
On Windows, it's much simpler. There is precisely one ICD driver. If it's installed, and you use a pixel format that it supports (aka: something reasonable), then you get hardware accelerated OpenGL through it. If it isn't you get Microsoft's software implementation.
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.