I have successfully shared a GPU-based OpenGL context with OpenCL (using CL_CONTEXT_PROPERTY_USE_CGL_SHAREGROUP_APPLE when creating the OpenCL context).
However if the OpenGL context is software-based (created with kCGLPFARendererID, kCGLRendererGenericFloatID), then OpenCL context creation failed with error CL_INVALID_DEVICE (-33).
Is it possible to group-share a CPU-based OpenCL context with a CPU based OpenGL context?
If so, how?
I think this is a SDK/ Driver specific problem. So you should try to ask this question in a developer forum of the hardware you are trying to use.
For example you can register without problems at this page for amd related stuff:
http://devgurus.amd.com/welcome
There you get answers also from AMD interal developers like driver developer. I think they could tell you if it is possible or not.
For the Intel side of live you should try this place:
http://software.intel.com/de-de/forums/intel-opencl-sdk
But there i can't tell you how likely the internal developers try to answer.
Related
I'm developing an operating system targetting the ARM architecture, more specifically, a RaspberryPi 4B. For that I've already managed to use the "Mailbox Property Interface" to draw some shapes on the screen. Out of curiosity I would like to know if it was possible to use OpenGL (or OpenGL ES, preferably) to render future more complex graphics. If possible, how do I do it?
You want to find out which driver the usual Raspberry Pi software uses, then adapt that driver to work on your OS. This is the code that interprets your OpenGL commands and translates them to the GPU's native language. Note there is both a kernel part and a user-space part.
It's probably not worth trying to write your own. Graphics is a whole field of study, it's like writing another OS just for the graphics card.
So, we've got a little graphical doohickey that needs to run in a server environment without a real video card. All it really needs is framebuffer objects and maybe some vector/font anti-aliasing. It will be slow, I know. It just needs to output single frames.
I see this post about how to force software rendering mode, but it seems to apply to machines that already have OpenGL enabled cards (like NVidia).
So, for fear of trying to install OpenGL on a machine three time zones away with a bunch of live production sites on it-- has anybody tried this and/or know how to "emulate" an OpenGL environment? Unfortunately our dev server HAS a video card, so I can't really show "what I've tried".
The relevant code is all in Cinder, but I think our actual OpenGL utilization is lightweight for this purpose.
This would run on windows server 2008 Standard
I see MS has a software implementation for OGL 1.1, but can't seem to find one for 2.0
Build/find some Mesa DLLs.
It will be slow.
I consider using OpenCL in a consumer product which is currently under development.
Doing a small research I found that generally there is good support under Mac OSX. Linux support is also relatively good, but my target audience does not use Linux. It remains to check how well it is supported in Windows.
Regarding Windows I found OpenCL distribution which raises some concerns.
Do any of you have any experience with using OpenCL in consumer-oriented products under Windows? I am more interested in the GPU side of OpenCL, specifically driver support.
Just like CUDA or Stream, OpenCL needs to be supported by the driver. Most CUDA-capable GPUs support OpenCL with a somewhat up-to-date driver (CUDA 1.0 upwards).
In fact, if you compile with, say, CUDA SDK 4.1 your end users will need newer drivers than if you had used OpenCL.
Also, OpenCL is not bound to any GPU architecture. While this might be problematic for specifically designed algorithms, it shouldn't have a very high impact on normal end user programs.
At least with CUDA, you can only compile code optimized for the current known major version. Compiling OpenCL kernels on the end user machine might allow optimizations for newer binary specifications in the future.
The crashes the author in that questions reported for Nvidia OpenCL generally seem to happen a lot if resources are not freed properly. I've been seeing similar crashes until I fixed a leak that didn't release created kernels.
I'm not saying it's the only reason why it might crash, but apart from programmer errors it appears fairly stable to me.
AMD and NVidia both support OpenCL on most (all?) of their GPUs
Unfortunately Intel only supports it on the CPU which is a bit pointless and if you have to insist that the user has a separate GPU for your app you can also insist that they have an NVidia one and use CUDA. This has limited the uptake of OpenCL.
I am trying to figure out the relationship between CGL and OpenGL on Mac platform.
More specifically about the context. Do they share context? If yes, how? Please give me a link to some related examples.
If no, then are there two contexts working in Core Animation applications which make use of OpenGL?
I am very confused by the use of OpenGL by Mac. Can somebody clarify?
CGL sets up device specific contexts suitable for OpenGL to render to. Compare to wgl and xgl on Windows and X respectively. CGL understands how to query the graphics hardware for its pixel format, and then how to set up and configure a context (e.g. double-buffered or single-buffered, what resolution depth, stencil, accumulation buffer, etc). But it doesn't provide functions to draw in that context. Once you have created the context with CGL, you make it current, and then you can call OpenGL to render in that context.
In Core Graphics (do not confuse it with CGL), both context initialization and drawing into the context are handled by the same framework. But because OpenGL is an open standard and designed to be cross-platform, the rendering functionality and the device context functionality have been abstracted into separate frameworks.
CGL is the low-level interface to OpenGL on a Mac. You probably don't want to be using it if you are writing an OpenGL Mac app. I am currently in the process of creating a intuitive OpenGL Mac application template for XCode 4, but in the mean time you can look at https://github.com/mk12/Pong-Ultimate, a pong clone I made using OpenGL. It uses NSOpenGL, a higher-level Cocoa interface to OpenGL.
You may also find the Apple docs helpful: http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_intro/opengl_intro.html.
I thought this should be easy, but... geesh! A vendor gave me a fairly simple demo program meant to showcase some trivial icon animations. The target platform is an embedded system (MX51) with accelerated OpenGL ES 2.0/OpenVG and EGL support.
Unfortunately, the demo also has an annoying dependency on a few Qt utility classes (e.g., QImage). If not for this dependency, I would compile/run the thing on the target. But I don't relish the thought of cross-compiling Qt just to run this little demo---even if there were enough room for it on the embedded board.
I hoped I might be able to run the app on a standard(ish) Ubuntu 10.04 VM, and started following these directions to make it happen. And I actually managed---like, 10 hours later---to compile everything and get a runnable binary of the demo program. However, when I run it, I see the following error:
eglCreateWindowSurface: egl error "EGL_BAD_CONFIG" (0x3005)
Sigh. Not what I wanted to see after all that effort. This seems way more difficult than it should be.
Is the embedded GL landscape really such a ghetto that I have to run even trivial programs on the target using some vendor-supplied BSP? Judging from the lack of responses to this guy's question, I'm thinking the answer might be yes. But I don't even care about acceleration (yet). I just want to run the stupidest of OpenGL ES 2/OpenVG programs on a desktop PC and get an idea of how it looks. (It doesn't matter to me whether the PC is running Linux or Windows.) How do people do this sort of thing?
There are several OpenGL ES 2.0 emulators, such as:
For ARM Mali GPUs
For PowerVR GPUs
Also very recently, AMD has posted drivers that expose OpenGL ES 2.0 on desktop.
More recently, OpenGL 4.1 exposes the GL_ARB_ES2_compatibility extension, which makes OpenGL 4.1 drivers GL ES 2.0 compatible.
For OpenVG, you can use AmanithVG GLE.
Qualcomm's OpenGL ES emulator includes OpenVG support. You can download it from http://developer.qualcomm.com