My knowledge of OpenGL is very little. I was researching on some RTOS for my project. Some sort of light wt. UI is also required. I came across the OpenGL support for some UI package. My doubt is that whether a separate GPU is required for OpenGL or not?
No separate GPU is required, all you need are openGL drivers. There are even openGL software drivers (Mesa) that will render OpenGL onto anything.
Assuming it's a relatively recent RTOS it may support OpenGL-ES which is a reduced subset to support low power/low memory devices.
Related
AGG (Anti-Grain Geometry) is a High Quality Rendering Engine for C++.
OpenGL ES is a royalty-free, cross-platform API for full-function 2D and 3D graphics on embedded systems.
But AGG seems more efficient than OpenGL ES in map rendeing, like Mapnik is using AGG.
Q1: Mapbox-GL why not use AGG but use OpenGL?
Q2: What's the difference between AGG and OpenGL ES?
Thanks! :)
OpenGL is an API for managing buffers on a GPU and specifying functions to map data between them; having originally been for the rendering of 3d geometry it's still primarily oriented around that goal. It's an open standard with 25 years of history that is implemented by all of the major vendors on all of the major operating systems and a subset of which is now even incorporated into standards-compliant web browsers.
Anti-Grain Geometry is a CPU-based 2d rasterisation library from a single vendor that appears to have started somewhere around 2001 and hasn't seen any web page updates since 2007. The most recent post to its mailing list is about its fractured state due to various independent downstream patches.
A developer might prefer AGG to OpenGL because the latter is very low level and not especially developer friendly. It provides very little unless you put the effort in and debugging tools are often poor. The former appears to be a high-level library which, since it operates on the CPU, will be amenable to your normal debugger.
However, AGG isn't accelerated, has no clear ownership or future, has no forum for governorship and isn't widely available.
Re Q1 and Q2:
OpenGL/-ES is usually GPU accelerated (in fact on most platforms with OpenGL-ES support, OpenGL-ES is available only if a GPU is present). AGG is a software rasterizer.
Thus if a GPU is present it's usually more efficient/performant to use OpenGL/-ES if the intention to generate output for an interactive (realtime) display.
In other word, is there any GPU that does not support OpenGL, and instead support other graphic rendering libraries like DirectX, OpenCl.
"GPU support of OpenGL" is not uniquely defined. It takes much more than hardware to make OpenGL work. Notably, OS driver infrastructure, and driver itself.
Therefore, it is possible to have a GPU that is capable of all OpenGL features, but have no OpenGL software implementation (either not exists, not installed etc.). Ex.: because of marketing reasons Microsoft does not support OpenGL on XBox. Same thing with Windows: often there is only basic OpenGL available with default Windows graphics drivers. It could be easily fixed by installing vendor driver, but most users don't bother.
And other way around, there are GPUs that are not capable of running some or all of the OpenGL features in hardware. Those features could be implemented in software. Ex.: First Android OS versions had software implementations of OpenGL ES in case phone didn't have dedicated GPU or if GPU was not fully capable of OpenGL ES.
Also, there are platforms that do not support OpenGL or DirectX and use their own APIs. Ex.: Sony use custom API for their Playstations.
At this day and age, no, you'll not find a GPU that won't support some version of OpenGL, with the possible exception of some super-specialised chips - but those won't support DirectX either.
WebGl is based on OpelGL ES 2.0.
Is it correct to say that Stage3d is also based OpenGL? I mean does it call OpenGL functions? Or ot calles Direct3D when runs on Windows?
If no, could you explain me, what API does Stage3d use for hardware acceleration?
The accepted answer is incorrect unfortunately. Stage 3D uses:
DirectX on Windows systems
OpenGL on OSX systems
OpenGL ES on mobile
Software Renderer when no hardware acceleration is available. (Due to
older hardware or no hardware at all.)
Please see: http://www.slideshare.net/danielfreeman779/adobe-air-stage3d-and-agal
Good day, Stage3D isn't based on anything, it may share similar methodology/terminology. It is another rendering pipeline, this is why Adobe is soo pumped about it.
Have a look at this: http://www.adobe.com/devnet/flashplayer/articles/how-stage3d-works.html
You can skip down to this heading "Comparing the advantages and restrictions of working with Stage3D" to get right down to it.
Also, take a peak at this: http://www.adobe.com/devnet/flashplayer/stage3d.html, excerpt:
The Stage3D APIs in Flash Player and Adobe AIR offer a fully
hardware-accelerated architecture that brings stunning visuals across
desktop browsers and iOS and Android apps enabling advanced 2D and 3D
capabilities. This set of low-level GPU-accelerated APIs provide
developers with the flexibility to leverage GPU hardware acceleration
for significant performance gains in video game development, whether
you’re using cutting-edge 3D game engines or the intuitive, lightning
fast Starling 2D framework that powers Angry Birds.
Ok, I know that online there are millions of answers to what OpenGL is, but I'm trying to figure out what it is in terms of a file on my computer. I've researched and found that OpenGL acts as a multi-platform translator for different computer graphics cards. So, then, is it a dll?
I was wondering, if it's a dll, then couldn't I download any version of the dll (preferably the latest), and then use it, knowing what it has?
EDIT: Ok, so if it's a windows dll, and I make an OpenGL game that uses a late version, what if it's not supported on someone else's computer with an earlier version? Am I allowed to carry the dll with my game so that it's supported on other windows computers? Or is the dll set up to communicate with the graphics card strictly on specific computers?
OpenGL is constantly being updated (whatever it is). How can this be done if all it's doing is communicating with a graphics card on a bunch of different computers that have graphics cards that are never going to be updated since they're built in?
There are two "parts" to OpenGL - the specification that's updated by the Khronos Group once every few months, and the driver that's written by your graphics card manufacturer specifically for your graphics card model.
The OpenGL specification essentially details how everything about the OpenGL API should work - what the expected behavior should be, when something is considered unexpected behavior, when to throw which errors, etc. The specification lets the driver writers know exactly what they need to do and lets application writers know what to expect from a driver. This is what OpenGL really "is" - the glue that holds applications and drivers together. You can read all the specifications for each version here.
Then there's drivers that implement the OpenGL API and are considered compliant to the specification. The driver does exactly what you'd expect it to do - copy data to and from the graphics card's memory, write data to graphics card registers, keep track of state, process vertices, compile shaders, instruct hundreds of stream processors to simultaneously transform vertices and fill pixels, etc. Without OpenGL, each graphics card model would have a separate, slightly faster API that would only work for that one graphics card because of the way it was structured. With OpenGL, the drivers are all written against the same API and an application's code will run on all graphics cards.
Compliance to the OpenGL specification doesn't change with driver updates. Most driver updates will either fix minor bugs or do some internal optimizing.
I know at one point there was a small bug with ATI driver where you had to call glEnable(GL_TEXTURE_2D); before you could generate mipmaps the OpenGL 3 way (glGenerateMipMaps()) despite GL_TEXTURE_2D being deprecated as a possible value for glEnable(). I'm not sure if it's fixed now, but it's certainly the type of edge case that can easily be overlooked by driver writers.
As for optimizations, there's a lot to optimize. Maybe there's another way to optimize shaders when they're being compiled, maybe there's a more efficient way to distribute work between the stream processors, I don't know.
OpenGL is a cross-platform API for graphics programming. In terms of compiled code, it will be available as an OS-specific library - e.g. a DLL (opengl32.dll) in Windows, or an SO in Linux.
You can get the SDK and binary redistributables from OpenGL.org
Depending on which language you're using, there may be OpenGL wrappers available. These are classes or API libraries designed to specifically work with your language. For example, there are .NET OpenGL wrappers available for C# / VB.NET developers. A quick Google search on the subject should give you some results.
The OpenGL API occasionally has new versions released, but these updates are backwards-compatible in nature. Moreover, new features are generally added as extensions, and it's possible to detect which extensions are present and only use those which are locally available and supported... so you can build your software to take advantage of new features when they're available but still be able to run when they aren't.
The API has nothing to do with individual drivers -- drivers can be updated without changing the API, and so the fact that drivers are constantly updated does not matter for purposes of compatibility with your software. On that account, you can choose an API version to develop against, and as long as your target operating systems ships with a version of the OpenGL library compatible with that API, you don't need to worry about driver updates breaking your software's ability to be dynamically linked against the locally available libraries.
I have a onboard graphics card which supports opengl 2.2. Can I run a opengl (let's say 3.3 version) application on it by using some software etc?
OpenGL major versions somewhat refer to available hardware capabilities:
OpenGL-1: fixed function pipeline (DirectX 7 class HW)
OpenGL-2: programmable vertex and fragment shader support.(DirectX 9 class HW)
OpenGL-3: programmable geometry shader support (DirectX 10 class HW)
OpenGL-4: programmable tesselation shader support and a few other nice things (DirectX 11 class HW).
If your GPU supports OpenGL-2 only, then there is no way you could run a OpenGL-3 program, making use of all whistles and bells on it. Your best bet is a software rasterizing implementation.
A few years ago, when shders were something new, NVidia shipped their developer drivers with some higher functionality emulation software rasterizer, to kickstart shader development, so that there were actual applications to run on those new programmable GPUs.
Sure you can, you just have to disable those features. Whether this will work well depends greatly on the app.
The simplest method is to intercept all OpenGL calls, using some manner of DLL hooking, and filter them as necessary. When OGL3 features are used, return a "correct" answer (but don't do anything) or provide null for calls that aren't required.
If done properly, and the app isn't relying on the OGL3 features, this will run without those on your hardware.
If the app does require OGL3 stuff, results will be unreliable at best, and it may be unusable. It really depends on what exactly the app does and what it needs. Providing a null implementation of OGL3 will allow you to run it, but results are up in the air.
No. Well, not really. NVIDIA has some software emulation that might work, but other than that, no.
Your hardware simply can't do what GL 3.0+ asks of it.
also:
I have a onboard graphics card which supports opengl 2.2
There is no OpenGL 2.2. Perhaps you meant 2.1.