http://http.developer.nvidia.com/Cg/TessellationControlShader.html
I have some questions regarding CG.
What OpenGL version does CG support? On their site they state
Opengl Functionality Requirements
OpenGL 1.0
Which seems a little bit odd to me. For me this means that I need to have at least OpenGL 1.0 to use all OpenGL features in CG. So litteraly all new OpenGL features are missing?
Also the compute shader seems to be missing
GeometryShader, PixelShader, TessellationEvaluationShader,
VertexShader, FragmentProgram, GeometryProgram,
TessellationControlProgram, TessellationEvaluationProgram,
VertexProgram
Is CG now a viable alternative to replace GLSL 4.x? Can I write all shaders in CG that I could write in GLSL 4.3?
Is CG now a viable alternative to replace GLSL 4.x? Can I write all shaders in CG that I could write in GLSL 4.3?
No. While some OpenGL 4.x features, such as tessellation, are exposed as of Cg 3.1, others are not.
Notable missing features in Cg 3.1 (and their OpenGL names) include:
compute shaders
atomic counters
shader-writeable storage blocks (shader storage blocks)
shader-writable textures (image load / store)
runtime shader function selection (shader subroutines)
In general, Cg tends to lag two or three years behind the latest OpenGL release.
Cg has been end-of-lifed by NVidia so it will not be developed going forward:
The Cg Toolkit is a legacy NVIDIA toolkit no longer under active development or support. Cg 3.1 is our last release and while we continue to make it available to developers, we do not recommend using it in new development projects because future hardware features may not be supported.
So I think the best answer would be No.
I'm pretty sure that OpenGL-1.0 is a typo. DirectX-11 is about the function level you get with OpenGL-4.0. Now look what key is right below the 4 on the numpad.
In fact no single NVidia GPU ever did support only a OpenGL profile as low as OpenGL-1.0. OpenGL-1.0 dates back 20 years.
Is CG now a viable alternative to replace GLSL 4.x?
Well, I personally don't see a reason why to use Cg, except if you want to support both OpenGL and DirectX with a common set of shaders. But why would you want cross API compatibility? If you aim for portability then OpenGL wins clearly over DirectX.
IMHO the main reason to keep using Cg is, if you have to maintain a legacy product that uses Cg already. Remember that Cg was introduced long before OpenGL had a high level shading language.
Can I write all shaders in CG that I could write in GLSL 4.3?
Yes.
Related
What version of GLSL is equivalent to OpenGL ES 3.2 SL and do they have full parity or are there missing features? Is it safe to rely on an older version of The Orange book when learning to do ES shaders (primarily interested in Compute shaders)?
There is no version of desktop GLSL that is exactly equivalent to ESSL 3.20. There are some features of GLSL that never made it into ES at all (shader subroutines, good riddance). And there are some features that, while technically part of both, only really matter in ESSL land (precision qualifiers, for example).
If you're not using ESSL-specific learning material, the best you can do is to reference the ESSL 3.20 specification when a new concept is introduced to make sure that it's available in ESSL.
Compute Shaders are provided since OpenGL 4.3, respectively GpenGL Shading Language 4.30.
They are also available by the extension ARB_compute_shader.
"What version of GLSL is equivalent to OpenGL ES 3.2 SL"
https://github.com/9ballsyndrome/WebGL_Compute_shader
"do they have full parity or are there missing features"
read the spec, likely the second.
"safe to rely on an older version of The Orange book"
you need that specific explorer personality, turning failure into successful experience and a lot of time. Whatever tutorials comes on the first three pages as websearch results, - i would call "safe".
If I am currently developing a game for windows using SDL and GLEW (for OpenGL 3.0+) and I later want to port my game to Android, will I have to rewrite the majority of my code to convert from OpenGL 3.0 to OpenGL ES 2.0? Are there any programs that do this for me? Is it a big deal switching from OpenGL to OpenGL ES?
Not at all, it is very easy to convert.
Only differences are shader variables and constants, and suffixes like GL_RGBA8 to GL_RGBA8_OES. However, there are limits in OpenGL ES. For instance, you can use only GL_UNSIGNED_BYTE or GL_UNSIGNED_SHORT as indices data type GL_UNSIGNED_INT. Which means, you can not draw more than 65,535 indices at one go. It is not a big deal although you should refer to the official OpenGL ES manual, https://www.khronos.org/opengles/sdk/docs/man/
Refer to the link OpenGL ES 2.0 vs OpenGL 3 - Similarities and Differences by coffeeandcode
It really depends on your code
OpenGL ES 2.0 (and 3.0) is mostly a subset of Desktop OpenGL.
The biggest difference is there is no legacy fixed function pipeline in ES. What's the fixed function pipeline? Anything having to do with glVertex, glColor, glNormal, glLight, glPushMatrix, glPopMatrix, glMatrixMode, etc... in GLSL using any of the variables that access the fixed function data like gl_Vertex, gl_Normal, gl_Color, gl_MultiTexCoord, gl_FogCoord etc...
If you use any of those features you'll have some work cut out for you. OpenGL ES 2.0 and 3.0 are just plain shaders. No "3d" is provided for you. You're required to write all projection, lighting, texture references, etc yourself.
If you're already doing that (which most modern games probably do ) you might not have too much work. If on the other hand you've been using those old deprecated OpenGL features which from my experience is still very very common (most tutorials still use that stuff). Then you've got a bit of work cut out for you as you try to reproduce those features on your own.
There is an open source library, regal, which I think was started by NVidia. It's supposed to reproduce that stuff. Be aware that whole fixed function system was fairly inefficient which is one of the reasons it was deprecated but it might be a way to get things working quickly.
I am developing a project using modern OpenGL through OpenTK. I want to use Gwen dot net GUI library in my project. Unfortunately, Gwen dot net uses old OpenGL for its widget rendering. I have tried merging both modern OpenGL and Gwen dot net and so far, have been unsuccessfull. Before I waste my time debugging my code, I would like to know, is it possible to merge both old OpenGL and modern OpenGL?
If you create a compatibility profile context, it should support all all legacy functionality. From OpenGL 4.3 compatibility spec, 1.2.4:
Older generations of graphics hardware were not programmable using shaders,
although they were configurable by setting state controlling specific details of their
operation. The compatibility profile of OpenGL continues to support the legacy
OpenGL commands developed for such fixed-function hardware, although they
are typically implemented by writing shaders which reproduce the operation of
such hardware. Fixed-function OpenGL commands and operations are described
as alternative interfaces following descriptions of the corresponding shader stages.
These days mixing old style and new style OpenGL is best avoided. On MS Windows and Linux you can, but weird stuff tends to happen.
For MacOS, Apple have declared that they're not going to support compatibility contexts at all, so you can't mix.
Since you're stuck with the GUI toolkit, I would try to isolate all your new style OpenGL code in a separate context and render to an offscreen target, then blit that to the main display.
OpenTK render for GWEN is a separate class. Just rewrite it modern way. There's no problem with that.
Two questions really...
Is GLSL ES 2 a totally separate language, or a special version of GLSL?
What are the differences between them, in terms of "standard library" functions, syntax and capabilities?
I am writing shaders for an application targeted at Windows, Mac and iPad and I would prefer not to have to add more versions of each shader - well simpler shaders anyway.
Is GLSL ES 2 a totally separate language, or a special version of GLSL?
Every version of GLSL is ultimately a "totally separate language;" some aren't even backwards compatible with previous versions. However, the ES variation of GLSL is even moreso.
Think of it as a fork of desktop GLSL. A fork of GLSL from six versions ago, mind you.
What are the differences between them, in terms of "standard library" functions, syntax and capabilities?
Between which versions?
The only possible reason you could have to try to share shaders between these platforms is if you're trying to share OpenGL code between them. So you'd have to be limiting yourself to desktop OpenGL 2.1 functionality.
That means you'd be using desktop GLSL version 1.20. This is similar to GLSL ES version 1.00 (the version of GLSL is not given the same number as the matching GL version. Well, until desktop GL 3.3/4.0 and GLSL 3.30/4.00), but still different. In ES, you have a lot of precision qualifiers that desktop GLSL 1.20 doesn't handle.
The best way to handle that is to use a "preamble" shader string. See, glShaderSource takes multiple shader strings, which it slaps together and compiles as one. You can take your main shader string (main and its various code, attribute definitions, uniforms, etc) and stick a "preamble" shader string in front of that. The preamble would be different depending on what you're compiling for.
Your ES GLSL 1.00 preamble would look like this:
#version 100 //Must start with a version specifier.
Your desktop GLSL 1.20 preamble would look like this:
#version 120
#define lowp
#define mediump
#define highp
And maybe a few other judicious #defines. This way, your shader can have those precision qualifiers set, and they'll just be #defined away when using desktop GLSL.
This is a lot like platform-neutral coding in C/C++, where you often have some platform-specific header that changes the definition and/or has #defines that you can condition code based on.
In Simpler terms Opengl ES ie opengl Embedded system was made to run on embedded devices like mobile phones the mobile phone system face the same problem as 90s pc that is computation issues and difference in gpu arcitecture.
ImgTech PowerVR SGX - TBDR (TileBasedDeferred)
ImgTech PowerVR MBX - TBDR (Fixed Function)
ARM Mali - Tiled (small tiles)
Qualcomm Adreno - Tiled (large tiles)
Adreno3xx - can switch to Traditional
glHint(GL_BINNING_CONTROL_HINT_QCOM, GL_RENDER_DIRECT_TO_FRAMEBUFFER_QCOM)
NVIDIA Tegra - Traditional
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
What are the differences between OpenGL ES and OpenGL ?
Two of the more significant differences between OpenGL ES and OpenGL are the removal of the glBegin ... glEnd calling semantics for primitive rendering (in favor of vertex arrays) and the introduction of fixed-point data types for vertex coordinates and attributes to better support the computational abilities of embedded processors, which often lack an FPU
Have a look here: OpenGL_ES
OpenGL ES is the opengl api for embedded systems. It is simpler than the normal opengl in terms of the number of the api functions, but may be harder to use, since you will have to use vertex buffers and write more shaders.
When you use a normal opengl, you can use glBegin and glEnd to enclose the geometry primitives you need to draw, but when using Opengl ES, you will have to use vertex buffers.
I guess this is for performance concerns.
Currently, there are two Opengl ES versions, the 1.1 version can only support the fixed rendering pipeline, while the 2.0 version supports glsl shader. However it has no fixed rendering pipeline. In other word, you will have to write your own shader for everything.
Opengl ES is mainly used on cell phones and web (webgl). According to the spec, your desktop opengl driver can support all opengl es apis.
Just like to add that OpenGL 3.3 and OpenGL ES 2.0 are mostly interoperable, by using a subset of the features of OpenGL 3.3. My custom C++ engine uses the same API calls, with a few defines, for Android/IOS/Windows/OSX/Linux.
Among the key differences are:
lack of geometry shader support
no min/max blending (there may be an extension for this)
no Quad List primitive
more restricted texture formats (especially regarding floating point)
glGetTexImage is not available
there is no Transform Feedback, same for several other advanced features
There are also many other differences, but that covers several of the important ones.
OpenGL ES means Open Graphics Library for Embedded Systems (OpenGL ES or GLES) is a subset of the OpenGL computer graphics rendering application programming interface (API) for rendering 2D and 3D computer graphics such as those used by video games, typically hardware-accelerated using a graphics processing unit (GPU). It is designed for embedded systems like smartphones, computer tablets, video game consoles and PDAs.
The OpenGL|ES Official Website: http://www.opengl.org/
you also can get more information from wiki : http://en.wikipedia.org/wiki/OpenGL_ES
Review the OpenGL ES overview here: http://www.khronos.org/opengles/
In short, ES is a subset of Open GL for "embedded systems". Specific differences will depend on the versions and feature sets you're comparing.
The OpenGL ES registry contains detailed API differences between OpenGL ES and the corresponding version of OpenGL:
OpenGL ES 2.0 / OpenGL 2.0
OpenGL ES 1.1 / OpenGL 1.5
However, there isn't a document containing the differences for OpenGL ES 3.0.
I think you'll get a better answer if you ask "what are the differences between OpenGL and OpenGL ES ".
There are profound differences between OpenGL ES 1.1 and ES 2.0, OpenGL 1.5 and 2.0, and OpenGL 3.0 and 4.0.
As others have described ES was written for embedded systems. It also represents the first "house cleaning" of the GL specification since its inception. OpenGL had a) many ways to do the same thing (e.g. you could draw a quad/rect two different ways and blit a pixel image two different ways, etc). ES is simpler than OpenGL with fewer features as a general statement because it's designed for less sophisticated hardware.
I urge you not to look at OpenGL ES 1.1 as it is the past and does not represent the way OpenGL or OpenGL ES is moving architecturally in the future.
The main difference between the two is that OpenGL ES is made for embedded systems like smartphones, while OpenGL is the one on desktops. On the coding level, OpenGL ES does not support fixed-function functions like glBegin/glEnd etc... OpenGL can support fixed-function pipeline (using a compatibility profile).
The modern answer, for ES 3.0 compared to OpenGL 4.6, is way different than the accepted answer. Now, all of the fixed-pipeline stuff is gone.
ES, for EMBEDDED SYSTEMS, is far less robust.
The terminology and versions are quite confusing (especially for newbies). For a more holistic view on OpenGL and OpenGL-ES (GLES), see OpenGL - Then and Now.
OpenGL ES is simply the OpenGL API for embedded systems (OpenGL ES refers to OpenGL Embedded Systems). so its a subset of OpenGL and widely used in cell phones and some VR systems, it's designed for less sophisticated hardware. OpenGL ES has less terms and functions than OpenGL, think of it as you are taking just what you need for that system, because if we dont need a function in whole our work or the hardware can't deal with it, then no mean to add that function but this also makes the use of this API more hard because of the need to write more Shaders and complicated codes to make something simple because OpenGL ES does not provide Shaders in the graphics pipeline as OpenGL. the last version of OpenGL ES is 3.2 it can now provide support for Tessellation for additional geometry details and new geometry shaders. so I advise you to start learning or using OpenGL ES 3.0+ (in case its your target API) because now and the next generation will not use the old versions especially with more powerful hardware and graphics cards we have today; and if your target is OpenGL start with v3.3+ or 4.0+. and when you have more time no problem to make a quick view on the old versions for more understanding how the things were and get developed and why.
you can check this link for more details : https://en.wikipedia.org/wiki/OpenGL_ES
OpenGL is 2D and 3D graphics API bringing thousands of applications to a wide variety of computer platform.
OpenGL ES is well-defined subsets of desktop OpenGL.
OpenGL® ES is a royalty-free, cross-platform API for full-function 2D and 3D graphics on embedded systems - including consoles, phones, appliances and vehicles. It consists of well-defined subsets of desktop OpenGL, ...
See this link.
P.S.
WebGL shares specification with OpenGL ES, i.e. if you have learned desktop OpenGL, it is simple to learn the others(OpenGL ES, WebGL).
simply telling, opengl is desktop version and opengl es is for embedded systems like cellphones where there are memory and performance constraints more than that of computers. opengl es would be harder to use.