I search some information about how GPU works. From different sources i found out that T&L (Transform and Lighting) technology used for hardware acceleration. For example, it calculates polygon lighting. But as I know, today the developers are using programmable graphic pipeline, and create lighting by shaders.
So, what is T&L today used for?
The classic 'Transform & Lighting' fixed-function hardware along with the "Texture blend cascade" fixed-function hardware is generally considered obsolete. Instead, the "T&L" phase has been replaced with Vertex Shaders, and the "Texture blend cascade" has been replace with Pixel Shaders.
For older legacy APIs that have a 'fixed-function' mode (Direct3D 9, OpenGL 1.x), most modern cards actually emulate the original behavior with programmable shaders.
There's an example for Direct3D 11 that emulates most (but not all) of the classic Direct3D 9 fixed-function modes if want to take a look at it on GitHub.
Generally speaking, you are better off using a set of shaders that implements the features you actually use rather than a bunch of stuff you don't.
Related
When i look to the 4th Edition of the Book "OpenGL SuperBible" it starts with Points / Lines drawing Polygons and later on Shaders are discussed. In the 6th Edition of the book, it starts directly with Shaders as the very first example. I didn't use OpenGL for a long time, but is it the way to start with Shaders?
Why is there the shift, is this because of going from fixed pipeline to Shaders?
To a limited extent it depends on exactly which branch of OpenGL you're talking about. OpenGL ES 2.0 has no path to the screen other than shaders — there's no matrix stack, no option to draw without shaders and none of the fixed-pipeline bonded built-in variables. WebGL is based on OpenGL ES 2.0 so it inherits all of that behaviour.
As per derhass' comment, all of the fixed stuff is deprecated in modern desktop GL and you can expect it to vanish over time. The quickest thing to check is probably the OpenGL 4.4 quick reference card. If the functionality you want isn't on there, it's not in the latest OpenGL.
As per your comment, Kronos defines OpenGL to be:
the only cross-platform graphics API that enables developers of
software for PC, workstation, and supercomputing hardware to create
high- performance, visually-compelling graphics software applications,
in markets such as CAD, content creation, energy, entertainment, game
development, manufacturing, medical, and virtual reality.
It more or less just exposes the hardware. The hardware can't do anything without shaders. Nobody in the industry wants to be maintaining shaders that emulate the old fixed functionality forever.
"About the only rendering you can do with OpenGL without shaders is clearing a window, which should give you a feel for how important they are when using OpenGL." - From OpenGL official guide
After OpenGL 3.1, the fixed-function pipeline was removed and shaders became mandatory.
So the SuperBible or the OpenGL Redbook begin by describing the new Programmable Pipeline early in discussions. Then they tell how to write and use a vertex and fragment shading program.
For your shader objects you now have to:
Create the shader (glCreateShader, glShaderSource)
Compile the shader source into an object (glCompileShader)
Verify the shader (glGetShaderInfoLog)
Then you link the shader object into your shader program:
Create shader program (glCreateProgram)
Attach the shader objects (glAttachShader)
Link the shader program (glLinkProgram)
Verify (glGetProgramInfoLog)
Use the shader (glUseProgram)
There is more to do now before you can render than in the previous fixed function pipeline. No doubt the programmable pipeline is more powerful, but it does make it more difficult just to begin rendering. And the shaders are now a core concept to learn.
Is there equivalent functionality to Directx's texturing blending? http://msdn.microsoft.com/en-us/library/windows/desktop/bb206241(v=vs.85).aspx
It basically blends several textures together before applying it onto the mesh.
From scanning through that page, I believe you can do all of that in a fragment shader. You can bind multiple textures, sample them all in your shader, and combine the results at your hearts desire.
It looks similar to functionality that OpenGL used to have in the fixed function pipeline. My old version of the red book (OpenGL Programming Guide) has chapters on "Multitexturing" and "Texture Combiner Functions". This is still available if you use the compatibility profile. But IMHO, this is a great example of where squeezing certain kinds of functionality into the fixed pipeline looked very cumbersome, while doing the same thing in shaders is much easier and more flexible.
I recently started programming with openGL. I've done code creating basic primitives and have used shaders in webGL. I've googled the subject extensively but it's still not that clear to me. Basically, here's what I want to know. Is there anything that can be done in GLSL that can't be done in plain openGL, or does GLSL just do things more efficiently?
The short version is: OpenGL is an API for rendering graphics, while GLSL (which stands for GL shading language) is a language that gives programmers the ability to modify pipeline shaders. To put it another way, GLSL is a (small) part of the overall OpenGL framework.
To understand where GLSL fits into the big picture, consider a very simplified graphics pipeline.
Vertexes specified ---(vertex shader)---> transformed vertexes ---(primitive assembly)---> primitives ---(rasterization)---> fragments ---(fragment shader)---> output pixels
The shaders (here, just the vertex and fragment shaders) are programmable. You can do all sorts of things with them. You could just swap the red and green channels, or you could implement a bump mapping to make your surfaces appear much more detailed. Writing these shaders is an important part of graphics programming. Here's a link with some nice examples that should help you see what you can accomplish with custom shaders: http://docs.unity3d.com/Documentation/Components/SL-SurfaceShaderExamples.html.
In the not-too-distant past, the only way to program them was to use GPU assembler. In OpenGL's case, the language is known as ARB assembler. Because of the difficulty of this, the OpenGL folks gave us GLSL. GLSL is a higher-level language that can be compiled and run on graphics hardware. So to sum it all up, programmable shaders are an integral part of the OpenGL framework (or any modern graphics API), and GLSL makes it vastly easier to program them.
As also covered by Mattsills answer GL Shader Language or GLSL is a part of OpenGL that enables the creation of algorithms called shaders in/for OpenGL. Shaders run on the GPU.
Shaders make decisions about factors such as the color of parts of surfaces, and the way surfaces share information such as reflected light. Vertex Shaders, Geometry Shaders, Tesselation Shaders and Pixel Shaders are types of shader that can be written in GLSL.
Q1:
Is there anything that can be done in GLSL that can't be done in plain OpenGL?
A:
You may be able to use just OpenGL without the GLSL parts, but if you want your own surface properties you'll probably want a shader make this reasonably simple and performant, created in something like GLSL. Here are some examples:
Q2:
Or does GLSL just do things more efficiently?
A:
Pixel shaders specifically are very parallel, calculating values independently for every cell of a 2D grid, while also containing significant caveats, like not being unable to handle "if" statement like conditions very performantly, so it's a case of using different kinds of shaders to there strengths, on surfaces described and dealt with in the rest of OpenGL.
Q3:
I suspect you want to know if just using GLSL is an option, and I can only answer this with my knowledge of one kind of shader, Pixel Shaders. The rest of this answer covers "just" using GLSL as a possible option:
A:
While GLSL is a part of OpenGL, you can use the rest of OpenGL to set up the enviroment and write your program almost entirly as a pixel shader, where each element of the pixel shader colours a pixel of the whole screen.
For example:
(Note that WebGL has a tendency to hog CPU to the point of stalling the whole system, and Windows 8.1 lets it do so, Chrome seems better at viewing these links than Firefox.)
No, this is not a video clip of real water:
https://www.shadertoy.com/view/Ms2SD1
The only external resources fed to this snail some easily generatable textures:
https://www.shadertoy.com/view/ld3Gz2
Rendering using a noisy fractal clouds of points:
https://www.shadertoy.com/view/Xtc3RS
https://www.shadertoy.com/view/MsdGzl
A perfect sphere: 1 polygon, 1 surface, no edges or vertices:
https://www.shadertoy.com/view/ldS3DW
A particle system like simulation with cars on a racetrack, using a 2nd narrow but long pixel shader as table of data about car positions:
https://www.shadertoy.com/view/Md3Szj
Random values are fairly straightforward:
fract(sin(p)*10000.)
I've found the language in some respects to be hard to work with and it may or may not be particularly practical to use GLSL in this way for a large project such as a game or simulation, however as these demos show, a computer game does not have to look like a computer game and this sort of approach should be an option, perhaps used with generated content and/or external data.
As I understand it to perform reasonably Pixel Shaders in OpenGL:
Have to be loaded into a small peice of memory.
Do not support:
"if" statement like conditions.
recursion or while loop like flow control.
Are restricted to a small pool of valid instructions and data types.
Including "sin", mod, vector multiplication, floats and half precision floats.
Lack high level features like objects or lambdas.
And effectively calculate values all at once in parallel.
A consequence of all this is that code looks more like lines of closed form equations and lacks algorythms or higher level structures, using modular arithmetic for something akin to conditions.
NURBS chapter in RedBook is denoted deprecated, including utility library: "Even though
some of this functionality is part of the GLU library, it relies on
functionality that has been removed from the core OpenGL library."
Does it mean OpenGL 4.2 actually lacks C++ toolkit for manipulating NURBS curves and surfaces? There are some commercial 3rd party toolkits, but they're not crossplatform ( windows, mainly )
...?
In OpenGL-3 and later you've got geometry, and vertex shaders at your disposal, OpenGL-4 even provides tesselation shaders. They offer everything to implement GPU accelerated NURBS and Bezier splines and surfaces. The evaluators of OpenGL-1.1 never were GPU accelerated on most hardware. So actually you're better off without them.
Just implement NURBS or Bezier evaluators in the shaders and send in vertices as surface sampling points.
With respect to your question regarding the Red Book, the GLU library wasn't officially deprecated by the OpenGL ARB, rather just ignored. However, GLU used features that were deprecated in OpenGL 3.0, and removed in OpenGL 3.1: immediate-mode rendering, display lists, matrix stacks, to name a few. Specific to NURBS, they used several of those features (assuming the GLU library associated with your OpenGL implementation was based on the SGI version of GLU, which most were), and so features just won't work in a core context. It's not the lack of the C++-based GLU library, as much as GLU used features removed from modern OpenGL.
#datenwolf - not quite. The GLU NURBS library supported trimming curves, which are challenging to implement in all cases using the OpenGL vertex shader pipeline (i.e., vertex, tessellation, and geometry shading only). Specifically, support for winding rules and correct trimming while respecting trim-curve crossings is pretty darned tough (it may be possible with a combination of compute shaders and fancy work in a fragment shader). You could hack trimming using an alpha texture, but you'd suffer aliasing results, but it's a quick fix.
There are several shading languages available today like GLSL, HLSL, CG, which one to pick to keep up with the trend?
HLSL is specific to DirectX and GLSL is specific to OpenGL. There's no way to compile a GLSL shader in DirectX or a HLSL shader in OpenGL. If you were to pick one of these two you would be picking it because you chose DirectX or OpenGL.
Cg is an intermediate language created mainly by nVidia that can be compiled as both GLSL and HLSL. From what I have seen, Cg isn't quite as popular as GLSL or HLSL, but I haven't looked into it much.
All 3 have extensive guides and tutorials, pick Cg if you are planning on writing a system that can support both OpenGL and DirectX as the underlying API or pick one based on the API you choose. None of them are going to fall out of fashion any time soon.