Virtualized Passes...

OpenGL
1

I’d like to see a “virtualized-pass system” (ie d3d fx/cgfx) in GL1.x [a hlsl for gl 1.x has been discussed iirc, and this would work nicely in conjunction with that] and GL2. By that, I mean a system where setting states is abstracted from the process of rendering.

There are many reasons for making it core, but even if it just made it into an updated GLU type library I’d be happy.

While developers could write something themselves, thats a fair amount of “repeated” work and there should be a number of optimizations that could be done driver side that aren’t possible developer-side.

[This message has been edited by Dr^Nick (edited 03-26-2003).]

[This message has been edited by Dr^Nick (edited 03-26-2003).]

2

I don’t necessarily like the idea of it being “core-core”. That is, transparent multipass should not be the default case. It should be a feature activated by a specific request of a particular shader. And, an implementation should be allowed to not provide this feature.

I, for one, violently dislike multipass rendering. The only thing I can imagine that is worse than multipass is transparent multipass, which means I have no idea it’s going to happen. As such, I’d prefer OpenGL simply tell me that the shader is “too big” to work, and I should try to make it smaller somehow.

3

But to put it in a new GLU dll should work for me, even that i already have one transparent multipass shader working

4

I’m not talking about making shaders auto multipass. I’m talking about an FX style pass system, with the ability to combine state-settings and shaders.

5

I’m talking about an FX style pass system, with the ability to combine state-settings and shaders.

Does that mean that a shader gets to call GL functions? Give me an example of what this means.

6

Check out CgFX or d3d’s FX stuff for working examples.

7

The fact that CgFX does not give you any more power over the hardware than you had without it should tell you that it isn’t something that belongs in OpenGL.

OpenGL is too low-level for these “FX”-type file formats. Not only that, it’s not even that useful. Oh, for demo writers it’s kinda handy to be able to give someone an effect. But in practice, it isn’t that useful.

What would be more useful would be a mechanism to allow you to combine shaders easier. Glslang has a facility for combining two shaders together, but it doesn’t rise to the level of what I’m talking about. In either case, what I’m refering to doesn’t belong in OpenGL either. Just having the facility to combine shaders together is enough to build a framework on.

8

Your argument seems misinformed and flawed.

A HLSL doesn’t give you any more power over the hardware than the assembly style shaders we write today. Does that mean the HLSL doesn’t belong?

Allowing state-set’s and shading language code to be abstracted from the rendering process is the next logical extension.

As far as being useful, I have a use for it, as do many people I know. (No, none of us are “demo writers”.) If you don’t understand its use, you’re probably not ready to use it. That’s fine. Don’t assume it’s not useful though.

9

A truely “virtualised” pass system is what should be hidden from the programmer. This is what we should be aiming at from an API POV. But, the next best thing is like CgFX (DX effects).

CgFX is something I will definately support and use in the long term, unless the ARB specifies a standard format for such things, which they really should be doing.

Having to write all the scripting and parsing crap just to support somethign similar to this in your own code is just a pain in the ass. This should be core.

10

Korval, Note that an FX file does NOT control how the app actually uses/renders the passes.

If you need to have some effect->app message passing facility for handling render-to-texture or marking passes with semantics (e.g. “this pass clears depth”), the FX format allows this through annotations.

There’s also nothing stopping you from applying state modifications to passes/techniques at runtime.

If you really wanted to chop state setting up etc, an effect doesn’t even need to set everything… you can apply multiple effects that set part of the pipeline each.

I think the point Dr^Nick is trying to make is that these “material characteristics” often belong in the “art pipeline” along with the shaders. It may not always be the case, but if the High-level State Setting system isn’t made Core, it can’t enjoy the optimization benefits it deserves.

11

A HLSL doesn’t give you any more power over the hardware than the assembly style shaders we write today. Does that mean the HLSL doesn’t belong?

Oddly, I’m not particularly in favor of having glslang being part of the GL2.0 core either.

Allowing state-set’s and shading language code to be abstracted from the rendering process is the next logical extension.

Some people say that it is a good idea to have GL handle collision detection and any number of other concepts that have no buisness being in a low-level graphics library. Saying it doesn’t make it the “next logical extension.”

The only thing I find at all appealing about glslang being part of the GL2.0 core is that I know that it allows implementations enough flexibility to compile the shader program into something that is properly accelerated on their hardware.

As far as being useful, I have a use for it, as do many people I know.

Would that use be, “Passing a canned effect around and using it in places that it wasn’t directly designed for?”

OK, so you have a nice, canned shader that takes a mesh and draws it with a wood-look to it. What happens when you want to create “wood-man” that requires a skinned shader instead of a regular model-to-view-to-projection shader to produce vertex output? Or, maybe I want to take an effect that renders regular bump maps via tangent-space bump mapping, and add specular characteristics?

In all these cases, you not just downloading an effect from the internet and using it. You’re trying to integrate some new effect into your already existing shaders. This is the area where problems arise far more than having some shader format that allows the storage and access of multiple shaders and some required/requested state changing.

Lastly, in the future, “FX” stuff will be less important for getting things done. You’re not going to have the issues of needing multiple shaders for “fallback” hardware. And if the shading language defines transparent multipass (which is the correct way to get the functionality you want), the only thing the FX stuff provides is a slightly convienient place to put your state changes. You won’t even see a performance increase out of it.

Also, let’s not forget that putting state changes in a shader will cause any number of debugging problems. If you can’t find the code that says, “glDisable(*)”, you may just assume it was never disabled. Of course, since a shader can do it, you now have to make sure to search shaders for the occurance of *.

Having to write all the scripting and parsing crap just to support somethign similar to this in your own code is just a pain in the ass. This should be core.

Having to write all that model and texture parsing crap is a pain in the ass too. Maybe those should be part of the core as well. Maybe OpenGL should ship with the Doom 3 engine built in, too.

You have to draw a line. And just because it might be nice or convienient to have a feature be implemented by somebody else isn’t sufficient to make it part of the GL core. You’ve already got a library (Cg) that implements it; why is there the need to make it core GL?

I think the point Dr^Nick is trying to make is that these “material characteristics” often belong in the “art pipeline” along with the shaders.

First, I don’t see turning on/off depth writes as being a “material characteristic” that I would ever want my artists touching.

Secondly, any material characteristics that a shader uses are either per-vertex/fragment constants already hard-coded into a shader, or are bound implicitly to programmer-defined state. The latter requires programmer intervention to connect the two, and the former doesn’t need the FX stuff.

It may not always be the case, but if the High-level State Setting system isn’t made Core, it can’t enjoy the optimization benefits it deserves.

Which is the only argument that makes this concept even close to reasonable. I still don’t like the idea, as it is too high-level for something like OpenGL. And I’m not entirely convinced that the performance gains will be significant enough to warrent the violation of a low-level interface.

12

Well I don’t think we’ll come any further than accepting that our views differ.

I wouldn’t let my artists touch shaders either, they’re for a middle breed of artist-friendly coders.

But as for the depthwrite on/off issue, that’s pure policy… if you don’t want shader writers to touch it, you tell them not to, and let your engine set it at runtime instead.

Now, obviously one of the main issues with a framework like this is to not make it impossible (or overly hard) to drive more creative rendering schemes, but as the hardware develops, more and more of these multipass setups can be rolled into single passes.

The special-purpose multipass techniques that remain will likely have quite definable reasons for existing, and therefore easier to express/control via an Effect style scheme.

You might not like shader code reuse for some reason, but there’s a lot of effort in that direction already.

13

Originally posted by Korval:
Oddly, I’m not particularly in favor of having glslang being part of the GL2.0 core either.

If you don’t want to use glslang, that is your business. Just like if you don’t want to use the stencil buffers is your business (It wasn’t supported in hardware until much later than GL1.0). But if it is included in the core, it stabilizes the API for the next 10 years. That is sorely needed.

Originally posted by Korval:
Some people say that it is a good idea to have GL handle collision detection and any number of other concepts that have no buisness being in a low-level graphics library.

Mostly only n00bs ask for stuff that is not in your typical computer graphics pipeline (as defined by classic texts such as Foley et al. or Real Time Rendering)

Originally posted by Korval:
The only thing I find at all appealing about glslang being part of the GL2.0 core is that I know that it allows implementations enough flexibility to compile the shader program into something that is properly accelerated on their hardware.

I don’t care if a feature is accelerated. I care if it is fast.

Using a shading language to abstract away multipass algorithms is the wave of the future. Deal with it. There are examples of it now (Renderman, Stanford, and Cg kinda). In a couple years, coding GPUs will be similiar to coding CPUs. It will get more and more higher level. From asm to C to C++ to (shudder) C#/Java. I have trouble dealing with withdrawals on the CPU end, but it will happen. Maybe F-Buffers will be the way that all algorithms are implemented in the future. And we will all look funny for using the framebuffer for blending the way we do now. Others such as Tim Sweeney

http://www.beyond3d.com/reviews/ati/r350/index.php?p=fb

However, I would say that the problem of being able to execute pixel shaders of arbitrary complexity (in terms of instruction counts, inputs, and temporaries) is THE number one outstanding problem in graphics hardware for this next generation. To vastly oversimplify the problem: PC CPU’s only have 8 registers but C++ programmers aren’t limited to only using 8 variables. Why? Because the compiler is able to “spill” variables out to memory when they don’t fit into registers. But DirectX9 shaders are effectively constrained to their temporary and instruction counts because of hardware limitations.

and John Carmack agree

(http://www.webdog.org/cgi-bin/finger.plm?id=1&time=20020627230700)

I do need to get up on a soapbox for a long discourse about why the upcoming
high level languages MUST NOT have fixed, queried resource limits if they are
going to reach their full potential. I will go into a lot of detail when I
get a chance, but drivers must have the right and responsibility to multipass
arbitrarily complex inputs to hardware with smaller limits. Get over it.

[This message has been edited by PK (edited 03-29-2003).]

14

If you don’t want to use glslang, that is your business. Just like if you don’t want to use the stencil buffers is your business (It wasn’t supported in hardware until much later than GL1.0). But if it is included in the core, it stabilizes the API for the next 10 years. That is sorely needed.

In terms of GL 2.0, not using glslang is equivalent to not wanting to use progammable hardware. They, technically, aren’t the same thing, but GL 2.0 makes them the same by not providing an alternative. It’s like refusing to use ARB_fragment_program and then complaining about the large number of per-fragment operation extensions avaliable.

I don’t care if a feature is accelerated. I care if it is fast.

Which has nothing to do with the point I was making that a C-like language allows implementations enough flexibility in the compiler to really use the hardware.

Using a shading language to abstract away multipass algorithms is the wave of the future. Deal with it. There are examples of it now (Renderman, Stanford, and Cg kinda). In a couple years, coding GPUs will be similiar to coding CPUs. It will get more and more higher level. From asm to C to C++ to (shudder) C#/Java. I have trouble dealing with withdrawals on the CPU end, but it will happen. Maybe F-Buffers will be the way that all algorithms are implemented in the future. And we will all look funny for using the framebuffer for blending the way we do now.

I’m not adverse to it being part of the language as long as:

  1. I know when multipass is happening or
  2. I can turn off transparent multipass.

You can say that it is “the wave of the future,” but that doesn’t make it true. Renderman and Stanford (Cg doesn’t abstract away passes) do abstract away multipass, but they had to. Renderman was written for a software rasterizer, so it doesn’t matter. Standford was designed to abstract away passes.

I’m not saying that this abstraction is unwanted by some or many. I’m saying that I should be able to be aware that it is happening (so I can use a different shader that doesn’t cause it). I don’t even need to know why (though it would be very nice); I’ll live with just knowing if a shader is going to cause multipass.

I will continue to want this until the hardware being used by the average computer user has programmability to the point where virtually no shader will need to multipass. Note that transparent multipass (and my aversion to using it) is just temporary; once we have future hardware that can handle any reasonable shader, it won’t be needed. At that point, the section of the spec refering to requiring transparent multipass will be moot.

BTW, this refers to an explicit re-T&L/rasterization of triangles for multipass. F-Buffers are all done per-fragment, so that doesn’t matter.

Others such as Tim Sweeney

Quite frankly, Sweeney’s statement that “THE number one outstanding problem in graphics hardware,” is insane. I can think of a number of other outstanding problems (problems that the fixes for won’t murder performance) that need to be addressed. The effective capabilities in fragment programs will work itself out given time; give me programmability over the Command Processor (so I can walk vertex arrays and create triangles).

Besides, he isn’t arguing for fragment programs having transparent multipass. He’s arguing for something we all want (and will have soon enough): more power per-fragment. Transparent multipass doesn’t get you more power; it just hides the fact that you’re burining performance.

and John Carmack agree

My feelings on Carmack have been entered into the record before, so I’ll gloss over who is saying it and focus on what is being said.

Once again, saying it doesn’t make it true. And the person saying it has no meaning in an argument about facts.

All that we know from this statement is that he wants to have this. Carmack wants it because he doesn’t want to keep writing low-end versions of his shaders that do multipass. That’s his choice; he doesn’t have to do that. He could do the reasonable thing and actually drop features for low-end shaders. But he doesn’t want to. He’s made his choice.

That doesn’t mean that we all ought to make that choice.

[This message has been edited by Korval (edited 03-30-2003).]