OpenGL Shading Language

Martin Ecker writes "A few months ago, the OpenGL Shading Language -- OpenGL's own high-level shading language for programming Graphics Processing Units (GPUs) -- was ratified by the Architectural Review Board (ARB) responsible for the development and extension of the OpenGL graphics API. The first real-world implementations are just becoming available in the latest graphics drivers of the big graphics hardware vendors. Now the first book that features this new shading language is available, with the intention of becoming the standard book on the subject. Randi J. Rost's OpenGL Shading Language (published by Addison-Wesley) is a good introduction to developing shaders with the new OpenGL Shading Language, and demonstrates a number of useful applications for real-time programmable shaders." Read on for the rest of Ecker's review. OpenGL Shading Language author Randi J. Rost pages 608 publisher Addison-Wesley Publishing rating 8/10 reviewer Martin Ecker ISBN 0321197895 summary A solid introduction to developing shaders in the OpenGL Shading Language.

Because of its orange cover, the book is also called the "Orange Book," and together with its siblings, the classic "Red Book" (aka OpenGL Programming Guide) and the "Blue Book" (aka OpenGL Reference Manual (see this earlier review), it is a member of the OpenGL family of books from Addison-Wesley. Although it has a short overview of the basic features of OpenGL, it is intended for an audience that is already somewhat familiar with OpenGL and with 3D graphics programming in general. The interested reader should probably have read the "Red Book" or at least have a good understanding of how to use the OpenGL graphics API before attempting to tackle this book.

Rost, as well as the co-authors on some of the chapters, John M. Kessenich and Barthold Lichtenbelt, all employees of the graphics hardware vendor 3Dlabs, were driving forces behind the inception of the OpenGL Shading Language. They are also core contributors to the final language specification as well as the OpenGL extensions that provide the framework for this new shading language. So the information in the book actually comes from the people that created the language, which is a definite plus.

The book consists of 17 chapters and two appendices which can be roughly categorized into four major parts: An introduction to the basics of OpenGL and GPU programmability; a description of the OpenGL Shading Language and the associated OpenGL extensions; a number of chapters that show the shading language in action; and finally a reference section on the language grammar and the entry points introduced by the new OpenGL extensions. Each chapter of the book has numerous interesting references to get further information on the presented topics. I can only recommend taking a closer look at some of them.

The first two chapters of the book describe the basics of the OpenGL graphics API, followed by an overview of the new programmable processors in the graphics pipeline and an overview of the shading language used to program them. The introductory chapter on OpenGL basics is very well written and worth the read even for more experienced OpenGL programmers. However, as mentioned above, the reader should have enough expertise in using OpenGL to be able to understand the more advanced parts of the book. The introductory chapter won't be enough in my opinion.

The third chapter, written by John Kessenich - one of the main authors of the OpenGL shading language specification - presents the language definition. This chapter is where the basic data types as well as the available control structures are described in detail. For people interested in writing a compiler for the OpenGL Shading Language, Appendix A also contains the entire language grammar in BNF.

Chapter four moves on to describe the programmable graphics pipeline, which was first introduced in the second chapter, in more detail. The programmable vertex and fragment processors and their interaction with OpenGL's fixed functionality are presented. In chapter five, the description of the shading language concludes with the available built-in functions. Chapter six offers the first simple example that shows the shading language in action - a shader to procedurally create a brick texture.

Until this point, the book doesn't talk much about how to integrate shaders into the host program running on the CPU. New OpenGL extensions were created for this purpose, in particular GL_ARB_shader_objects, GL_ARB_vertex_shader, and GL_ARB_fragment_shader. Chapter seven contains detailed descriptions of the entry points provided by these new extensions. Among other things, it describes how shader objects are created, compiled, and then linked to form shader programs that can then be used to render objects. Appendix B also has a reference section on the new entry points similar in style to the "Blue Book." Chapter seven concludes the dry, technical part of the book that introduced both the shading language and the necessary infrastructure to use it from a host program running on the CPU.

The remaining chapters delve into the really interesting topic: shader development. These chapters offer multiple ideas on what can be done with shaders and how to effectively use them in graphics programming. Standard techniques, such as bump mapping, procedurally creating textures, using noise, and others, are presented. Chapter nine deserves special mention because it presents shaders that mimic the behavior of the OpenGL fixed-function pipeline. Many developers new to shader programming are faced with re-implementing certain features offered by OpenGL's fixed functionality. This chapter addresses this.

Chapter fourteen also deserves mention. Shaders that procedurally create textures usually suffer from aliasing artifacts. This chapter shows a number of anti-aliasing techniques to diminish these artifacts. In my opinion, this important topic has not received the attention it deserves -- it's good to see such a chapter in this book.

Closing this section of the book, chapters fifteen and sixteen describe some interesting non-photorealistic shaders and shaders for doing image processing. (For more ideas on what can be done with shaders I also recommend the book "GPU Gems", which I have read and reviewed some time ago.

The final chapter of the book (chapter seventeen) is a language comparison with other high-level shading languages such as the RenderMan Shading Language, SGI's Interactive Shading Language from the OpenGL Shader package, Microsoft's HLSL, and NVIDIA's Cg. Although I am quite familiar with most of these languages, I found this chapter to be an interesting read because it attempts to look at the languages objectively, listing advantages and disadvantages of the various approaches.

The book contains many diagrams and images, all in black and white, except for 16 pages containing 30 color plates in the middle of the book. Most of the images are not overly "flashy" but do give a practical idea of the types of rendered images a particular shader can produce.

There is also a website for the book where you can find an errata list and download a sample chapter (chapter six). As mentioned above, this chapter develops a simple brick shader to show the basic features of the shading language. The website also has all the shaders presented in the book available for download. Because the book does not come with a CD-ROM this is the only means of getting shaders code without having to type them. At the time of this review, the site appeared to be in a transitional state.

Rost's OpenGL Shading Language succeeds at giving a good introduction to shader programming with the OpenGL Shading Language. Not only does it provide the necessary technical instruction to allow the reader to write his/her own shaders as well as integrate them with the host program, it also demonstrates a number of practical applications for shaders and tries to encourage exploring the new dimension of real-time graphics programming opened up by the OpenGL Shading Language. Since there is no other book currently available on this topic, it is hard to say whether the "Orange Book" will stand the test of time and actually become the reference book on the OpenGL Shading Language, but I believe it will.

Ecker has been involved in real-time graphics programming for more than 9 years and works as a arcade game developer. He also works on a graphics-related open source project called XEngine. You can purchase OpenGL Shading Language from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, carefully read the book review guidelines, then visit the submission page.

Comments

The main problem with GLSL

[Samir Gupta]

I'm no Microsoft apologist, but there's one architectural decision that I foresee to be the potential cause of major problems: the fact that each IHV's driver is responsible for the high-level compilation of the shading language, rather than having a common runtime do it, as with DirectX HLSL, where it is compiled into a intermediate binary token format, after which is then passed on to the driver and turned into a vendor-specific and optimized binary format.

The core competencies of graphics IHVs are generally not in compiler writing -- writing a good optimizing compiler is still a "black art" significantly more difficult than writing a hardware driver, and it will be very annoying if compiler bugs show up on some vendors' drivers and some don't, forcing developers to work around them -- or different compilers optimize things differently.

At least with DirectX, there's guaranteed to exist one common compiler that's written by a company with years of experience in optimizing compilers.

Of course, the philosophy of OpenGL is counter to DirectX in that there's no one Big Company controlling it all, but
at the very least, there needs to be some standard token bytecode defined and standarized by the ARB, and a reference compiler design, as well as a compliance suite to verify compiler correctness and language compliance.

Re:The main problem with GLSL

[Ryu2]

He was talking about DirectX HLSL, not C#.

They are two different things from Microsoft.

Re:The main problem with GLSL

[Jon Langridge]

I believe 3dlabs has released an open compiler front end implementation. Hopefully vendors will contribute source updates, although I don't know if the license requires this.

Re:The main problem with GLSL

[PixelSlut]

Of course, the philosophy of OpenGL is counter to DirectX in that there's no one Big Company controlling it all, but at the very least, there needs to be some standard token bytecode defined and standarized by the ARB, and a reference compiler design, as well as a compliance suite to verify compiler correctness and language compliance.

I understand what you're saying, and it makes sense. But I will still respectfully disagree.

For one thing, GLSL is an incredibly easy language to compile compared to C++ or C#. That aside, 3Dlabs has written the source code to the GLSL compiler and released that source code for anyone to use, including competitors like ATI or NVIDIA.

But my main disagreement is with the idea of having an ARB-specified intermediate language. I already described my position in another post, so I won't repeat it all here.. but I think your position is short-sighted. I think allowing the IHVs to do the full compile/optimization stuff will provide them with greater flexibility and greater potential for innovation.

Re:The main problem with GLSL

[woodhouse]

Actually, C# is a language developed by nvidia. It just happens to have exactly the same syntax as HLSL.

Re:The main problem with GLSL

[MasterVidBoi]

GLSL is still a fairly simple language, compared to something like c/c++, so writing a compiler should not be extremely difficult.

The big advantage of passing the high level code straight to the driver is that it allows for easier optimizations, simply because the conversion from high level -> assembly/bytecode inevitebly loses some of the context.

For instance (I don't know HLSL, but I have used Cg, which I'm told is almost identical to HLSL), the smoothstep() function provides a nice, smooth interpolation between two values. When I compile my Cg shader down to arb_vp (the assembly language), smoothstep has to be expanded to perform all the necessary arithemtic instructions sequentially, because there is no comparible instruction.

If the high level code were passed directly on to the driver, the driver could determine if for instance, this was a new piece of hardware that didn't exist when the game was made, and this hardware has dedicated smoothstep functionality, allowing the operation to be performed much faster than sequential instructions. The same information could be recovered from the bytecode, but it would be much more difficult.

The same general principle holds in other languages. Higher level doesn't necessarily mean slower or more difficult compilers. Look at Apple's extensions to C to allow easy utilization of the PowerPC's vector processor. A little hint from the programmer can make the job of writing an optimizing compiler much easier.

Re:The main problem with GLSL

[gtada]

Are you kidding me? C# is a Microsoft invention, and Cg is the Nvidia language.

Re:The main problem with GLSL

[woodhouse]

Er, good point.

Re:The main problem with GLSL

[wuHoncho]

There is the current and likely very temporary issue of nvidia's drivers only partially supporting GLSL (and only through a registry hack with very up-to-date drivers at that), not to mention a few limitations of the language itself.

The fact is, however, that the language spec is down, it has already undergone revision, and the compiler is open source. Support for the language will undoubtably grow with time. OpenGL's core strength is its stability.

One of the main reasons, so I understand, for the language's longish delay is the somewhat more democratic process of the ARB as compared to the way MS internally decides the path of DirectX, which has often led to more than a few arguments between the different members.

It will grow strong and, with a bit of luck, could serve as the basis doing some really experimental stuff.

Re:The main problem with GLSL

[gtada]

I don't know if it's better or worse, just that the ARB chose a different method.

I agree with the other posters that the GLSL way could help with optimizations. However, given the problems I've had with ATI's drivers, I'm more than a little worried about the quality of ATI's shader compilation. :P

Just out of curiosity, does anybody think that the extra effort to do a driver with GLSL support will affect how often we'll see drivers for platforms other than Windows? I'm thinking back to when it was hard to find full OpenGL drivers (ugh miniGL).

Re:The main problem with GLSL

[spitzak]

Apparently there is an open-source compiler available. Not sure if it goes to an actual card or not. But if you have that, you can just as easily hack off the back end, change it to generate the code for your card, and release that. And if in fact that back end does not produce exactly what you need, it is not impossible to fix the front end (it would be impossible with the closed DirectX front-end).

So I think in the end this solution is superior, provided the card manufacturers use the open-source front end and contribute back any fixes to it. If they don't do that there may be problems, like you say.

Re:The main problem with GLSL

[Pseudonym]

Exactly.

I haven't worked with GLSL et al, though I have done a lot of work with RenderMan shading language compilers, including writing two of them from scratch. I definitely agree that these shading languages are much easier to compiler compared with C++ or C. (The lack of user-defined types and recursion helps a LOT --- no fancy stack frames.) Similarly, the target platforms (usually some kind of virtual machine in the case of RenderMan) are invariably quite simple.

However, the problem is that even though the target platforms are simple, they're all extremely different. Most of them are SIMD architectures, but some are not. Some use stacks and others use register transfer. One or two (most notably Pixar's PRMan) execute annotated abstract syntax trees (called "shade trees") directly. Many compile to C++, but even then, they often have very different capabilities and limitations.

Take, for example, the following piece of code, where all of the variables are "varying" (that is, they vary over the grid being shaded):

w = x + y + z;

If the target machine supports SIMD addition, then it pays to use it. So we might use a temporary, and generate code like this, scheduling the two additions separately:

varying t = x + y;
w = t + z;

If, however, you're compiling to C/C++, then you're better off scheduling the additions together:

for (all grid elements g)
{
g->w = g->x + g->y + g->z;
}

This increases the effective size of each basic block and hence gives the C/C++ compiler a better chance of performing low-level optimisations.

And this is just showing the difference between two software VMs. I can only imagine what the differences are between the capabilities between two generations of NVIDIA hardware, let alone between NVIDIA and ATI. Leaving optimisation up to the IHV was definitely the right thing to do.

Re:The main problem with GLSL

[egoots]

-- writing a good optimizing compiler is still a "black art" significantly more difficult than writing a hardware driver...

You have obviously never written a hardware driver for Windows 2K/XP, or you wouldnt say that ;-)

Re:The main problem with GLSL

[PixelSlut]

I agree with the other posters that the GLSL way could help with optimizations. However, given the problems I've had with ATI's drivers, I'm more than a little worried about the quality of ATI's shader compilation. :P

NVIDIA's is pretty good, but also isn't perfect yet. I think it's to be expected that neither one of them has gotten everything correct. We have to keep in mind that GLSL is still pretty new.

Re:The main problem with GLSL

[Woody77]

Possibly showing my ignorance here, but wouldn't the preferred code be:

w = x;
w += y;
w += z;

??

Re:The main problem with GLSL

[addaon]

Why?

Re:The main problem with GLSL

[Pseudonym]

There is no "the" preferred code. Your code may be better on some platforms, but on others it may not be.

However, you do raise a good point. A coalescing register allocator, particularly one that was sensitive to target paths, could easily optimise the temporary version to:

w = x + y;
w = w + z;

It's one fewer temporaries, but the same number of operations.

Re:The main problem with GLSL

[Anonymous Coward]

Compiling to graphics hardware is significantly harder than compiling to CPU's. There are numerous details/restrictions in the GPU architectures that makes it much harder for an outsider to write a good optimizer.

Few examples: 1) NVIDIA and ATI do not publish detailed information on their shader units, i.e., exactly what instructions you can co-issue or dual-issue, 2) They do not publish information on the exact latency of texture fetches and which instruction takes how many cycles. All of this is important information to consider when generating the actual assembly code and scheduling the instructions for maximizing shader unit throughput. Furthermore, this stuff changes with every architecture and you wouldn't want to be constantly catching up with the IHV's and updating your optimizer every 6-12 months.

In reality, for the foreseable future, there will be no independent vendors that will provide shader compilers; the IHV's will be writing them for both OpenGL and DX (i.e., GLSL, Cg, and HLSL).

Re:The main problem with GLSL

[Anonymous Coward]

You can still layer the compiler on top of the driver, just the way Cg works. The OpenGL ARB got it wrong. The shader compiler does not belong in the drivers and in fact, the IHV's (other than NVIDIA who fought this decision) are, I think, realizing what a mistake it was. Shader compilation can take quite a bit of time and what GLSL forces you to do is to precompile your shaders at the start up of the app. With a layered solution, you can precompile your shaders and load the shaders lazily. Not to mention that sometimes you don't want to trust that the latest drivers will really work. In the graphics world, drivers break often, and you don't to increase your dependence on the drivers; you want to decrease it.

Re:The main problem with GLSL

[justin_saunders]

Thats an interesting point...however doesn't the step between the intermediary binary format and vendor specific code still require "compilation"?

If so, you still can't guarantee IBF code will compile to "the same result" on a different hardware implementations. ( Just ask the Java guys about this problem :-).

Granted there's less room for bad compiler design, but its there. What do you think?

Nice!

[Anonymous Coward]

Lest we forget, the most important thing after the widget set is the documentation on how to use it...

What are people's opinion of comparisions

[saha]

"The final chapter of the book (chapter seventeen) is a language comparison with other high-level shading languages such as the RenderMan Shading Language, SGI's Interactive Shading Language from the OpenGL Shader package, Microsoft's HLSL, and NVIDIA's Cg. ." Not to forget ATI's RenderMonkey.

I spoke to a friend who is a developer for visualization applications. He feels that with Open GL 1.5 and some of the new ratified standards from the OpenGL ARB, OpenGL is back on par with Direct X 9.0.

Anyone have other insights ?

Re:What are people's opinion of comparisions

[MisterFancypants]

Finally getting a standardized shading language in there is a great start.

It will take a while for drivers supporting OpenGL's SL to be widely distributed, and existing artist-centric shader design tools to be updated for the new standard, but things seem to be moving very quickly.

There are still a few areas where I wish the OpenGL ARB would follow DirectX's lead -- a library like D3DX and a generic mesh format similar to DirectX X files would be really nice (there are various Open Source projects that fit this bill, but AFAIK, none of them are official or have any sort of critical mass).

Of course, a developer can easily create his/her own code that does similar things to D3DX using OpenGL, but having such a functional officially-supported utility library really helps when you're prototyping and just want to get things up and running quickly and also helps if you're just beginning with 3D programming, so you aren't completely overwhemled by everything.

Re:What are people's opinion of comparisions

[PixelSlut]

In a way, I'd say it's more advanced thatn DirectX 9.0. At least in terms of shaders. GLSL allows you to design things to be more modular. You can write multiple shaders (multiple vertex shaders, multiple fragment shaders) and then link them together into a single program object. This is a very good step in the right direction, I think. Also, HLSL specifically compiles its code into a DirectX-specified shading assembly. Microsoft is controlling those, of course, so there's less room for innovation of compiler optimizations on the part of the hardware vendors. I think the OpenGL approach (define the language, not the underlying assemblies) is a better approach. Sadly, I think the hardware vendors will be locked into doing things the Microsoft way and this will also affect how the GLSL compilers work internally.

Re:What are people's opinion of comparisions

[fitten]

He feels that with Open GL 1.5 and some of the new ratified standards from the OpenGL ARB, OpenGL is back on par with Direct X 9.0.

Except in the area of the existance of real implementations.

Re:What are people's opinion of comparisions

[MisterFancypants]

In a way, I'd say it's more advanced thatn DirectX 9.0. At least in terms of shaders. GLSL allows you to design things to be more modular. You can write multiple shaders (multiple vertex shaders, multiple fragment shaders) and then link them together into a single program object.

You can do that with DX9 too, using HLSL and the 'FX' effects file system.

This is a very good step in the right direction, I think. Also, HLSL specifically compiles its code into a DirectX-specified shading assembly. Microsoft is controlling those, of course, so there's less room for innovation of compiler optimizations on the part of the hardware vendors.

There is no reason why the vendors can't take the DX shader assembly code and reorder/optimize it for their card's strengths at the driver level. (NVidia and ATI both already do this).

Re:What are people's opinion of comparisions

[MisterFancypants]

Except in the area of the existance of real implementations.

True enough, and the forthcoming DX9 Summer Update 2004 nudges DX9 a bit further yet. While there are certainly some benefits to having a committee like the OpenGL ARB, there are some drawbacks (like slower forward movement) too.

Re:What are people's opinion of comparisions

[scratchor]

"Not to forget ATI's RenderMonkey."

RenderMonkey is not a language, but an IDE for several shading languages, such as HLSL, Cg and GLSL.

Re:What are people's opinion of comparisions

[PitaBred]

I'd be all for using a generic format if it didn't tie me into one company's technology. Which is why most of /. inherently mistrusts MS, including D3D, DX, etc.

Re:What are people's opinion of comparisions

[schapman]

except for a change.. directX is very well made. Its probably one of the few mSOFT products I truly enjoy. I think the main reason directX has been ahead of openGL for so long is that is it ONE company that makes the choices.. having panels/discussions for everything has just bogged down openGL.

Re:What are people's opinion of comparisions

[lcracker]

The point is that the DX shader assembly code has *lost meaning* in the translation from whatever high level language it came from. There are many possible optimizations that could have been made with a cheap analysis of the high level language that would be very difficult to make from looking at the low level language.

Re:What are people's opinion of comparisions

[PixelSlut]

There is no reason why the vendors can't take the DX shader assembly code and reorder/optimize it for their card's strengths at the driver level. (NVidia and ATI both already do this).

But there is no longer a good reason to have this intermediate assembly. It only makes it more difficult for the IHVs to optimize their drivers.

Consider a hypothetical high-level shader function foo() that compiles into, say, six instructions in SM2.0 four instructions in SM3.0. For the driver to try to do some crazy-cool optimizations, it doesn't need to merely compile foo() but it needs to parse through the six instructions and sort of reverse-compile it to realize that it's something that can be optimized into a single low-level instruction.

(I don't really write compilers or drivers or anything, so I'm not sure if I'm describing this well or not. I hope it makes some sense.)

Re:What are people's opinion of comparisions

[MisterFancypants]

The point is that the DX shader assembly code has *lost meaning* in the translation from whatever high level language it came from. There are many possible optimizations that could have been made with a cheap analysis of the high level language that would be very difficult to make from looking at the low level language.

Actually, no meaning is lost. Have you ever actually done shader programming? Even with PS3.0, which adds support for looping and branching logic, the higher level language is really just syntax sugar on top of the assembly code. I can't think of one single instance where meaning would be lost going from GLSL or HLSL to shader assembly... care to share one?

Re:What are people's opinion of comparisions

[shplorb]

OpenGL is purely an API for drawing graphics, DirectX is a suite of API's for everything to do with games.

There are loads of libraries out there that you can use for those things. It's also not too hard to roll your own - you'll also learn a hell of a lot more in the process.

The beauty of OpenGL is that it sticks to doing one thing and doing it well. The choice of not having an intermediate bytecode for GLSlang is a good one too... it allows compilers to directly optimise the shader program for the architecture as it knows what the high-level context of the code is. If you think about this a bit more, it's like GCC - front-ends compile to a common intermediate format then back-ends take that and translate to machine code - witness the sloppy performance it delivers on certain architectures because it is forced into a generalised format.

Re:What are people's opinion of comparisions

[bradkittenbrink]

(there are various Open Source projects that fit this bill, but AFAIK, none of them are official or have any sort of critical mass).

I'll take this opportunity to promote my favorite open source 3d project: OGRE. It's really a very complete rendering system with a great set of plugins for Maya and 3dStudioMax to work with it's mesh format. The tutorials and documentation are also very well written. It, of course, does not do everything, but it does a lot of what I need it to do. It was written around D3D and D3DX functionality, but it also has an OpenGL backend which implements the same functionality. I don't know what 'critical mass' is, but regardless, I definitely think OGRE can probably do what you want it to.

Re:What are people's opinion of comparisions

[Illuminatus_Primus]

...and also helps if you're just beginning with 3D programming, so you aren't completely overwhemled by everything. To be honest Ive been with the 3D-Gaming Industry the Day Wolfenstein3D was released but I'm still overwhemled by the 3D-coding skills required to write such an engine as doom3 uses. I'm not completly stupid am I think I would enjoy coding 3D stuph. Any good link or advices for beginners? I don't even know where to begin looking...

Graphics?

[Anonymous Coward]

The most important design issue... is the fact that Linux is supposed to be fun... -- Linus Torvalds at the First Dutch International Symposium on Linux

Re:Graphics?

[Ari_Haviv]

and what can be more fun than adding obscure patches and recompiling your entire system every month?

FINALLY!

[GodHead]

No one will be able to say this isn't "News for Nerds".

Re:FINALLY!

[NanoGator]

"No one will be able to say this isn't "News for Nerds"."

Yeah but nobody'll call it 'News for Studs'.

Re:FINALLY!

[nuclear305]

Yes, but what about the stuff that matters?

Re:FINALLY!

[johannesg]

Of course, by complaining about that you have ruined the topic anyway...

Useful book

[PixelSlut]

I found the Orange Book to be a very good introduction to GLSL, and I think it'll make for a good reference as I develop stuff. It does a good job of explaining how GLSL fits into the entire GL pipeline, which is cool because I don't know of any other books on OpenGL shader development that do this (It was hard to write a book on GL shaders before, and while GLSL is still ARB extensions, it's pretty clear that it's really targeted towards the core, while ARBvp1/ARBfp1 really seemed to just be placeholders until something really robust--GLSL--could come along).

Somewhat familiar? I hope so!

[Goyuix]

Although it has a short overview of the basic features of OpenGL, it is intended for an audience that is already somewhat familiar with OpenGL and with 3D graphics programming in general

Boy, I hope someone looking to learn OpenGL at least knows enough about 3D graphics to realize this isn't likely the right book to start learning OpenGL with. That said, the Red and Blue books are indispensable. I certainly hope this "Orange" book lives up to the family reputation.

Anyone know if Doom 3 uses these newly ratified extension? I would imagine it does - but I of course have no facts to back this up.

Re:Somewhat familiar? I hope so!

[l0ungeb0y]

"Anyone know if Doom 3 uses these newly ratified extension? I would imagine it does - but I of course have no facts to back this up"

I had to read that TWICE and I'm still in shock.
A /. reader making conjecture and admitting to having no basis in fact to substantiate said conjecture???

A sign of the apocolypse if I ever saw one.
Congrats Goyuix, you may now add "Harbinger of the Apocolypse" to your sig.

Re:Somewhat familiar? I hope so!

[PixelSlut]

Anyone know if Doom 3 uses these newly ratified extension? I would imagine it does - but I of course have no facts to back this up.

I would not bet on it out of the box. I would probably bet against it. :)

That said, I do remember JohnC saying at some point that he is committed to doing a codepath for this, so it's extremely likely that it will appear in a future patch. I am very excited to see how it performs.

Re:Somewhat familiar? I hope so!

[Anonymous Coward]

Anyone know if Doom 3 uses these newly ratified extension? I would imagine it does - but I of course have no facts to back this up.

Sort of. Since the rendered was started years ago, it probably doesn't call the GL_ARB extensions, but the beauty of OpenGL is that similar extensions existed in cards before that depending on the manufacturer. NVidia and ATI add them as experimental extensions until ARB approves of them and they become official. That's one of the reasons that Doom3 uses a few different render paths.

Re:Somewhat familiar? I hope so!

[metlin]

Ah, completely offtopic, but that just reminded me of this quote that I'd once come across --

-- --- ---

You know the world is going crazy when the best rapper is a white guy, the best golfer is a black guy, the tallest guy in the NBA is Chinese, the Swiss hold the America's Cup, France is accusing the U.S. of arrogance, Germany doesn't want to go to war, and the three most powerful men in America are named 'Bush', 'Dick', and 'Colon'. Need I say more?"
-Chris Rock

--- --- ---

Somewhere in there, the Slashdotter admitting to not having facts could fit in ;-)

Re:Somewhat familiar? I hope so!

[Screaming Lunatic]

Anyone know if Doom 3 uses these newly ratified extension? I would imagine it does - but I of course have no facts to back this up.

Yes

I am now committed to supporting an OpenGL 2.0 renderer for Doom through all the spec evolutions.

Re:Somewhat familiar? I hope so!

[Anonymous Coward]

Yes, another case of cynic meets plain truth. Let's roll around in shock.

Re:Somewhat familiar? I hope so!

[Anonymous Coward]

I highly doubt that Doom3 uses these new extensions. ARB vertex/pixel is NOT the hight-level SL extension which is surely too new to be used in a game due in 2 weeks.

Apple seminar on GLSL at WWDC

[thejam]

I saw on the listing of seminars/tutorials at WWDC a few weeks ago that Apple was presenting a session on OpenGL Shading Language, yet I didn't even know it was supported on OS X. Is it currently supported in Panther? Will it be supported in Tiger? Will there be an IDE for writing shaders, etc?

Re:Apple seminar on GLSL at WWDC

[PixelSlut]

Will it be supported in Tiger?

Yes. But I'm guessing they won't be rolling out drivers for previous versions of MacOSX.

Re:Apple seminar on GLSL at WWDC

[Anonymous Coward]

Yes - if you have one of the newer cards that support it. Apple has been a very big supporter of OpenGL the last couple of years; they were even a little ahead of the standards committee on this one.

Apple has a great tool called OpenGL Shader Builder that comes with the developer tools on Panther. I don't remember how long Shader Builder has been around but I know it has been at least a couple of years. It even existed before the standard shader language existed, for writing to NVidia and ATI's individual vendor-specific shader languages before there was a standard. Apple made Shader Builder extensible so they could just add the standard language as an additional shader language to the tool.

Shader Builder is cool - you can edit your shader program directly as shader code mneumonics or whatever, run it and debug it interactively, and if I remember right it even generates the C code with the appropriate OpenGL calls to create and load the shader program for you. You just copy and paste right into your C file.

I don't know of anything else like it on any other platform; there may be an equivalent tool on windows but I have never seen it.

Re:Apple seminar on GLSL at WWDC

[highbrow]

I would assume in that case that GLSL is the basis for Apple's new CoreImage technology that's in Tiger.

One interesting aspect of it is that it appears to be designed not only for processing images for output to screen (ie realtime visual effects), but also for use elsewhere (ie application of video / photo filters, output to RAM / disk). Nice to see someone thinking of all that mostly unused GPU grunt, and putting it to use.

Judging by the list of cards that support it (on a PC they'd be called "DX9 capable"), it is very much a pixel-and-vertex-shader reliant API. It's been glossed over in reports of Tiger, did anyone learn anything interesting about it @ WWDC?

Re:Apple seminar on GLSL at WWDC

[lcracker]

Yes, but everyone who knows anything is under NDA so we can't tell you :)

Re:Apple seminar on GLSL at WWDC

[mcasaday]

Will it be supported in Tiger?

I'm betting the answer is yes.

Re:Apple seminar on GLSL at WWDC

[timts]

so this is the key? where apple is behind this?
we are going to get yet another shader language where gaming companies are still not really into all current shader platforms available.
is this the plot to let consoles dominate gaming market longer? by making PC developement into such chaos?

Re:Apple seminar on GLSL at WWDC

[TomorrowPlusX]

As a relatively new opengl programmer ( writing visualization for robotics simulation ) I have to confess I've seen and fiddled with this program but not had enough information to even understand what's going on.

I should mention that I never wrote a line of opengl before last august, and all that I know came from the Red Book, which doesn't cover shading languages.

So, I'm curious, what shading language is Shader Builder using? Is it a custom language? Is it HLSL? What kind of standards does it follow?

And, what capacity at run time is there to determine what is supported at on a given card?

I know, I should just post to the mac-opengl list at apple, but the people there are friendly only to opengl experts -- unfortunately my focus is AI and as such -- visualization is merely a cool necessity. The few questions I've asked have been replied to, if at all, rather brusquely. They seem only to have discussions with other experts.

I'm stuck in the dead zone, halfway between n00b and guru.

Of course, this is all irrelevant since my little powerbook only has a GF4MX. But someday I expect to buy a new powerbook, and I'd like to experiment with cleaning up my code to use shaders for various stuff like outlining and solid wireframing, which I do extensively right now via multiple passes.

Re:Apple seminar on GLSL at WWDC

[ceoyoyo]

Shader builder lets you write vertex and fragment programs and see the result on a quad, sphere or teapot. In Panther you can write in either the ATI vertex/fragment assembly or the ARB standard. In Tiger I believe you will be able to use the OpenGL Shader Language as well. It's handy for testing shaders and it can generate the OpenGL code for you as a XCode project.

Re:Apple seminar on GLSL at WWDC

[ceoyoyo]

Well, we can tell you Core Image is really cool. :)

PDF available at OGL website

[sjf]

http://www.opengl.org/documentation/oglsl.html

Save youselves a bob or two.

-S

Re:PDF available at OGL website

[grumbel]

Correct me if am wrong, but that looks like just the language spec, not the whole Orange Book (page count in pdf 106, page count in Orange Book 608).

Re:PDF available at OGL website

[Bingo Foo]

Forget the PDF, I want an OpenGL texture of the whole document.

Re:Boring called

[Anonymous Coward]

Hahah... good one.

I disagree

[woodhouse]

I'm guessing whoever modded this down doesn't know what they're talking about.

But for what it's worth, the parent raises some interesting points, although I disagree that a bytecode/pseudo asm route is a better method.

In reality, the ASM-like bytecode used probably bears little resemblance to the machine code instruction sets actually used by the various cards. Forcing vendors to use such a low level instruction set allows very little room for optimisation, whereas allowing vendors to write their own compilers gives much better scope to improve the code at the machine code according to their hardware's instruction sets and limitations.

There may be a few teething problems at first (witness the arguments about nvidia's GLSL compliance on OpenGL.org), but I'm convinced its a better method overall.

You take the Red Book...

[ajlitt]

We used the red book for a graphics class in college. After browsing the book for a couple of evenings I was able to write a simple OpenGL app to draw, texturemap, light, and animate a heightfield made of triangle strips. In fact, I spent less time writing the OGL code than figuring out how to get GTK to throw up a drawing window.

Yes, it's that good.

Thank Carmack...

[Fornander]

...because I think OpenGL would have been relegated to academia and top-end engineering applications at most if he hadn't used OpenGL for his Quake engines.

Why do I care about this? Because M$ only produces/copies acceptable technologies when heavy pressure is applied to them or if they are playing catch-up. Look at IE for example. I speculate that DirectX would have dominated as the graphics API but would have followed a similar fate to IE if it hadn't been for OpenGL racing along with decent drivers all because of this thing called Quake.

Thinking short-term as a developer, I would have loved if the world had one standard, even for shaders, but I take off my hat to Darwin and accept a little hardship implementing for two or more APIs to let them evolve each other.

Re:Thank Carmack...

[Anonymous Coward]

Sometimes I wish it was (I'm in top-end engineering applications...) - OpenGL has pandered to the Gamerz-must-be-purty crowd for ages now. We want MORE POLYGONS. WE DON'T WANT SHADERS. GIVE US THE ABSURD HIGH POLY COUNT. OBEY ZIM!

Re:Thank Carmack...

[Fujisawa Sensei]

MS still would have invented DirectX because it's something they can controll. They controll the most prevelant development environment for the PC, Visual Studio, and they can use that control to influence developers to use their stuff rather than an open standard or other SDK.

Overview of Shading

[IrresponsibleUseOfFr]

Here is brief overview of shading, in case you don't know.

Shading is the process by which a renderer assigns color values to pixels on the screen. There are currently three popular rendering methods: Rasterization, REYES, and Ray-tracing. Rasterization simply projects planar polygons onto a 2D plane and discreetizes them to pixels. REYES is slightly more complicated in that it takes mathmatically defined patches, slices and dices them into micro-polygons which are then rasterized. Ray-tracing point-samples the scene by tracing rays through it.

Rasterization is the method of rendering that is implemented on your commodity graphics accelerator. It is commonly considered the most adept at handling real-time graphics. In the past, the type of shading that you could perform in real-time was rather limited. What people did was take a dial and switch approach to shading. Users would tell their graphics API (like OpenGL) what features they wanted to use and pass in parameters. That was basically it. Unfortunately, the more bells and whistles you add to the rendering pipeline, the more unweildly your graphics API becomes. This is because, users deal with the most shading algorithm possible, no matter how simple the task.

Hence, the programmable pipeline is born. Instead, of adjusting dials and switches, you just write little procedures telling the renderer exactly what you want it to do at a certain stage of rendering pipeline. There is some history behind this approach coming from REYES renderer. Renderman is the shading language that tells Pixar's REYES renderer what to do. It is popular, and it is pretty standard in the graphics industry. People have even implemented Ray-tracers capable of using the same shaders that were used for the REYES renderer. But, in all this is pretty inefficent. Shaders are intimately tied to the rendering method that you are using. Therefore, a new shading language needed to be developed.

In all, the shading languages will look like Renderman, which in turn looks like C. Real-time shading languages differ in their specifics. But, in rasterization there are two procedures you can write. A vertex shader which allows the procedure to manipulate points of your planar polygon in some fashion, and a fragment shader which is invoked after the discreetization to actually color the pixels. Cg and HLSL are actually the same shading language. OpenGL Shading language (glslang) is an alternative. Probably the biggest difference at this point is HLSL/Cg dictates a particular instruction set architecture on the hardware. GLslang doesn't, but it requires that your graphics driver has a compiler that compiles the shading language to something the graphics card can use.

In all, I think the money is on HLSL/Cg to win. It has been out considerably longer, and I think it has already picked up developer mind-share. I also think that it makes things considerably easier for graphic driver writers although it might be more limiting. However, we probably won't feel the pains of it being limiting in the next 5 years, and by then the battle will be over.

As for those that mention rendermonkey. Rendermonkey isn't a shading language, it is a suite of tools that help you produce shaders. It uses HLSL/Cg or a general graphics assembly language underneath. It is pretty independent of the whole shading language war.

That said, this book might be good to pick up independent of the actual language that it discusses just because it goes over important issues that you face when writing these shaders.

Re:Overview of Shading

[levork]

Renderman is the shading language that tells Pixar's REYES renderer what to do. It is popular, and it is pretty standard in the graphics industry. People have even implemented Ray-tracers capable of using the same shaders that were used for the REYES renderer. But, in all this is pretty inefficent. Shaders are intimately tied to the rendering method that you are using. Therefore, a new shading language needed to be developed.

I disagree. The RenderMan shading language is not at all tied to the rendering method. The original specification allowed for global illumination methods such as radiosity and raytracing. As evidenced by the RenderMan compatible renderers over the years, it didn't care whether the algorithm used was chiefly scanline, REYES, or raycasting/raytracing.

Why do you think this is inefficient?

Re:Overview of Shading

[kingjosh]

How could HLSL/Cg win?!?! Can one really group these together? Micro$oft and Nvidia collaborated on Cg, then M$ they went their seperate way. They aren't the same language, HLSL is platform dependent, only working on Windows systems, while Cg and GLSL can be used on Linux, Apple, etc.

Re:Overview of Shading

[Have Blue]

Minor nit- REYES is not a "shading method" on the same level as rasterization/scanline or ray tracing. I believe it's a specific 3D graphics program. What you describe here is adaptive subdivision surfaces, which are a common high-end technique but not fundamentally different from simple polygon rasterization.

Re:Overview of Shading

[IrresponsibleUseOfFr]

Inefficencies: surface shader, you have to break it down to a vertex shader and pixel shader to make it map well on to modern hardware. Displacement shaders: you can't do it the same way using rasterization as you do with REYES. In fact, you can do displacement mapping using the surface shader if you are doing REYES. You need to separate it out if you are doing ray-tracing. This is just one way that the rendering system leaks into shading. Light shaders, there is no equivalent mapping to current hardware in the programmable pipeline. Atmosphere shaders: that part of the pipeline isn't open to programablility yet.

Renderman is great if you are doing PhotoRealistic imagery. But, we need a slightly different language to do real-time graphics. RendermanSL just doesn't map well, making the underlying implementation too slow for real-time which was my point. I probably should have worded it differently.

Cheers!

I see that as its main strength

[EnglishTim]

I think the compilation by the IHVs is a very good idea. It means that the driver can optimise in the best way for the card.

If you remember figures starting coming out about very poor performance with nVidia hardware and Half-Life 2 a while back. If HL2 had been OpenGL, nVidia could have tweaked their driver to workaround the suboptimal way Valve was driving their hardware, presumably to the benefit of the frame rate. ATI could have done the same thing.

Orange Book

[gtada]

It's free... but the Orange Book covers much more. I just bought the Orange Book because of that promotion on the front page (35% off). $60 is a little rich. :D

Re:My Money is on GLSL

[B47h0ry'5 CuR53]

Cg/HLSL are definitely older and hence have picked up developer mind share, but being the first few high-level realtime shading languages, they have design flaws. GLSL is based on an excellent design and if your API of preference is OpenGL, then GLSL is what you will want to use.

Probably the most eagerly awaited feature for OpenGL developers, everything in the OpenGL state is directly accessible using built-in variables in the shader and need not passed explicitly from the program before executing the shaders.

'varying' variables are another cool design feature, where you can pass data from the vertex shader to the fragment shader directly.

GLSL is based on excellent design and it is only a matter of time before OpenGL developers switch to it. I, for one, have switched to GLSL. nVidia's latest SDK (7.0) already has many GLSL demos and their 0.60 drivers for FX and 6800 already support GLSL.

--

REYES is a method, PRMan is a program

[Anonymous Coward]

PRMan implements the REYES algorithm, based in buckets, micropolygons and other things you can learn by reading any of the book about it. Pixie also implements a REYES like method. BTW, REYES can be expanded as Renders Everything You Ever Saw.

Re:REYES is a method, PRMan is a program

[neocrono]

Aqsis [tagline - REYES for everyone!] is an open source REYES renderer, RenderMan-compliant. Its web site is a decent source of information on the subject, the links contained within are better.

glacial OpenGL ARB vs (liquid?) Direct3D Microsoft

[Anonymous Coward]

There is nothing worse than an API designed by such a glacial commitee.

Funny you should mention ARB being "glacial," because if Microsoft were broken up or bankrupted then DirectX would not survive. Given that OpenGL is a platform-independent freedom standard, it would survive in the societies and communities if ANY of its first hosting organelles of persons were to disband. (*puts on Dummy::Bush hat*) If OpenGL is for freedom, that makes any person a Terrorist if they speak or write any negatory or against OpenGL. (happily removes Dummy::Bush hat*)

I'm an Alpha computer user, and look at that crazy x86 computer architecture; do you think everyone would drop dead if Intel pulled its lower lip over its face and swallowed itself up in bankrupty? Hello^H, No!

OpenGL is not glacial as you in contrast to your declaration, its moreso a Pykrete whilst Microsoft and its DirectX even Direct3D is the liquid sewer muck that evolves countless genera of virus exploits to this day.

Sincerily,
The Alpha Troll

Write this up in wikipedia

[Anonymous Coward]

You should actually write this up in wikipedia. It's quite a good write up on the subject.

Thanks!

issue: shader copyrights

[hitchhacker]

Since the app sends the shader source code to the driver, it would be easy to see all the shaders an app is using. I remember Randi saying that this is one of the issues they are having to deal with. Microsoft doesn't have this problem because the shaders are compiled before shipping.

while not an issue for me, it will be for many companies planning on competitively deploying shaders in their apps.

-metric

Re:issue: shader copyrights

[jovlinger]

1) perhaps the shader can be obfuscated (unsure whether it is "rich" enough for this to be worthwhile).

2) it should be easy to spot rip-offs, then.

The basic idea can still be stolen, so yours was a very insightful observation.