GLslang: 'promises'

[zeckensack]

I think it may be useful for shaders to contain addtional usage information in form of application 'promises'.

I'll give a brief snippet with first draft syntax

//constants and stuff goes here
 
promise      //typeless? perhaps, as it should be a keyword
{            //usual block notation to compound multiple things
  alpha_test(greater,0.0);
  //relational expressions of type bool, promised to be true
  0 == (tex_coord0.p);
  1 == (tex_coord0.q , tex_coord1.q);
}
 
void
main()
{
  <...>
}

This would then signal to the compile step that this shader will only be used with an active alpha test. It would also signal that tex coordinate set 0 will always be of the form (s,t,0,1). To extend upon the idea, I've added a constraint on texture coord set 1 also, concatenated by comma.
This one could be extended to full relational expressions, all of which should by virtue of 'promise' evaluate to true. I'm not quite sure how to make a nice syntax for that. These should be applicable to uniforms as well.

If one specifies conflicting promises, or links shader code with conflicting promises, this would have to be detected and reported as an error I think.

The promise concept could be extended ad infinitum, once it's in place

Now, what's the use?
Promising the alpha test condition as above would allow hardware that doesn't natively support 'discard', but does support conditional moves to compile and execute corresponding fragment shaders. 'discard' could then be implemented as a conditional move to the output's alpha channel.
If the application's promise is broken, results would be undefined, of course.

Likewise, hardware that doesn't have hardwired zero/one constants and no other way to generate them on the fly could make utility of the 'promised' input conditions. Or, to make it a little harder, hardwired 0.5 constants ...

All of this would have no other purpose than allowing compilation of more complex shaders to a broader range of targets, by providing compile-time usage hints that can't be elegantly expressed otherwise. I believe maximum target support would be a good thing for a high level language to tackle.

Thoughts?


[This message has been edited by zeckensack (edited 06-20-2003).]

[zeckensack]

Nothing? Well, actually I take it as a good sign, usually threads in this forum are dismissed within a couple of days (and I'm more often that not dismissing ideas myself ...).

I'll rephrase, while I'm at it:
'promises' provide a means to supply the compile step with usage hints, which may be used to simplify/improve resource usage beyond the information that could've been extracted from the shader code itself. This is achieved by reducing the possible state/input combinations (currently: everything) that a shader must work with to a subset.

glHint() is not well suited to this task, as there's no way to prevent changes to hint state after compiling. If the usage hints are to be used for compiling better shaders, that would incur a recompile, which is probably bad (I take a stance for aggressive optimizing compilers, expensive to restart them all the time).

'promises' would apply to one shader, because they shall be used for compiling this one shader. Not much point in making them context global state.

Also, the hint mechanism is much too simplistic, text has much better expressive power. The compiler already includes a tokenizer/parser ... so the right place to add it is the shader code.

A shader with promises can also trivially reduced to a shader without promises. An application may even wish to maintain otherwise identical shaders (if there is a possible benefit).

'promises' can easily be implemented as doing nothing at first, so IMO it wouldn't increase compiler complexity beyond reason. You just ignore all promises, and if you later on feel a need to extract a bit more goodness, look at the promises. It would still be nice to have the syntax in place, so people can get used to it (even without immediate benefit).

The only required immediate implementation burden would be checking for conflicting promises, which may be either very hard or trivial, depending on the allowed complexity of relational expression promises.

[*Aaron*]

I like the idea, but I don't like the syntax. I would rather see something like:

ASSUME tex_coord0.p = 0;
ASSUME tex_coord0.q = 1;
// or...
ASSUME tex_coord0.pq = {0, 1};

This is almost like declaring a constant in C/C++. Also, I like the word assume better than the word promise, because you're telling the compiler to assume that a certain input or state variable has a certain value.

[zeckensack]

Originally posted by *Aaron*:
I like the idea, but I don't like the syntax. I would rather see something like:

ASSUME tex_coord0.p = 0;
ASSUME tex_coord0.q = 1;
// or...
ASSUME tex_coord0.pq = {0, 1};

This is almost like declaring a constant in C/C++. Also, I like the word assume better than the word promise, because you're telling the compiler to assume that a certain input or state variable has a certain value.

Fair enough.
I like 'promise' because it strongly implies a responsibility ... and that something bad may happen if the promise is broken

[Korval]

All of this would have no other purpose than allowing compilation of more complex shaders to a broader range of targets, by providing compile-time usage hints that can't be elegantly expressed otherwise.

Consider that only Radeon 9500+ and GeForceFX hardware (from the big 2) could even consider implementing glslang. The glslang spec requires looping in the vertex shader, which earlier hardware does not have.

Anyone who comes along later with hardware will understand what the basic level of functionality needs to be in terms of shader processing, so there won't be a problem with someone building new technology that doesn't implement something that glslang needs.

[zeckensack]

You're proposing that high level shading languages should never be available on anything below this year's hardware?

Why?

If harware resources run out, I'm fine with failed compilation. OTOH I have lots of very simple shaders I'd like to funnel through a unified interface ... I currently funnel a lot through my brain to generate NV_rc/ATI_fs/ARB_tec code.
Ask what happens if a shader definition gets changed (say, if you work with artists ...).

Imagine what would've happened if the implementors of the GLQuake days had said "No, we don't have transform hardware, we can't do that".
An API of broad scope on limited hardware. Same argument, basically.

I know I'm not the only one who wants this, assembly interfaces just suck (from a longetivity of code point of view).

[Korval]

You're proposing that high level shading languages should never be available on anything below this year's hardware?
Why?

First of all, I'm not proposing anything. I'm not even assigning a value judgement to either side. I'm simply explicitly stating what is currently a fact.

Glslang cannot, given its current spec, run on a GeForce3/4, or even a Radeon 8500. This is simply how it is. The requirements for glslang are too steep. As such, if you want a glslang that can run on older hardware, you will have to make lots of changes to the glslang spec; your "Promise" method is barely a beginning.

I know I'm not the only one who wants this, assembly interfaces just suck (from a longetivity of code point of view).

If you go back far enough in computing days, there were systems that were just not capable of running C. They just didn't have the fundamental features that a C program requires.

Granted, C was invented late enough in the computer realm that it could be implemented on the avaliable hardware. However, given that C is a guide to virtually all high level shader languages, you're seeing the evolution of C in shader languages much sooner than it appeared in previous times. The idea of trying to run glslang on a GeForce3/4 is like trying to get C to run on ENIAC; it just can't do it.

And, this is probably for the best. While it is unfortunate that slightly older hardware can't run modern shader languages, it is probably better that modern shader languages aren't weighed down by the baggage that GeForce3/4 hardware brings to the table. Look at NV20-based Cg shaders; you don't want to have that kind of baggage wandering around.

[zeckensack]

Originally posted by Korval:
First of all, I'm not proposing anything. I'm not even assigning a value judgement to either side. I'm simply explicitly stating what is currently a fact.

Yes, it is a fact. It's not a fact I particularly appreciate, that's why I started thinking in this direction. If time permits I'll try and demonstrate that this is unnecessary (ie I'm deep into the design stage of a GLslang compiler for all kinds of low capability targets).

Originally posted by Korval:
Glslang cannot, given its current spec, run on a GeForce3/4, or even a Radeon 8500. This is simply how it is. The requirements for glslang are too steep. As such, if you want a glslang that can run on older hardware, you will have to make lots of changes to the glslang spec; your "Promise" method is barely a beginning.

Nope, I don't think so. I take issue with these "requirements", they actually don't exist.

Just for the sake of prose: GLslang is a human readable description language for setting up pipeline resources. It's aware of advanced functionality, ie it has sufficiant expressive power for that, but you don't need to use it. The beauty is that you can detect cases where you oversubscribe resources, this can automatically apply to non-present features (eg dependant reads). 3DLabs wisely made provisions for that.

Now, what if that happens? Just like today, if the shader doesn't want to run, you trim down until you find something that does (or you drop through your minimum reqs and give up). If you do this with GLslang (purely academical atm), you use one interface, for all vendors, for all tech levels.
Seen this guy ? He could have been saved ...

To reverse the argument, I can auto-generate GLslang code from all texture env/reg combiner/fragment shading extensions known to mankind. I hope this is obvious enough so that I need not prove it.
So far that's useless because I can't compile them back. But these 'shaders' are guaranteed to fit the resource restrictions. And they are valid GLslang code.

Originally posted by Korval:
If you go back far enough in computing days, there were systems that were just not capable of running C. They just didn't have the fundamental features that a C program requires.

Granted, C was invented late enough in the computer realm that it could be implemented on the avaliable hardware. However, given that C is a guide to virtually all high level shader languages, you're seeing the evolution of C in shader languages much sooner than it appeared in previous times. The idea of trying to run glslang on a GeForce3/4 is like trying to get C to run on ENIAC; it just can't do it.

This comparison isn't particularly relevant because you're mixing up runtime compilation with inherent fallback provisions and (typically) offline compilation from a single code base (because all C targets can be reasonably assumed to support the same language features; graphics chips are vastly different).

An ENIAC is probably not capable to run any compiler itself, so this argument is kind of moot. If the ENIAC is the most powerful machine at your disposal, well ... you don't even have a compiler. If you have another machine that can run a C compiler, why would you still need the ENIAC?

With graphics chips you always have a host processor nearby that can tackle such tasks.

I'd also like to point you towards the fact that C development for general purpose machines shares the resource oversubscription issue, although on a different scale. If you try to compile huge programs for an 8086, you'll eventually run out of code segment space, even though the code may have been perfectly valid. So you must try again with less code, or you give up.

Originally posted by Korval:
And, this is probably for the best. While it is unfortunate that slightly older hardware can't run modern shader languages, it is probably better that modern shader languages aren't weighed down by the baggage that GeForce3/4 hardware brings to the table. Look at NV20-based Cg shaders; you don't want to have that kind of baggage wandering around.

I hate this. In essence it's just whining and laziness. If GLslang becomes the standard shading language, vendors will have to write (or license, buy, whatever) the compilers anyway for their 'bigger' products. So they presumably have the parser/tokenizer/code generation covered. Plop in a different back end, and you're good to go.

In my mind, it can't really harm to start building the required expertise with simpler architectures. You know, learn to walk before you run. It's really shameful to see all these cheap excuses for not doing it. It will have to be done anyway, why not start now?

I think I should elaborate on why I so hardly want broad high level shading language support, but maybe it's better to do that somewhere else. I'll just quote two bullet points from the 3DLabs GDC pres, that IMO sum it up nicely.

Key benefits:
Shader source is highly portable
No need to change app when compiler improvements occur

[Korval]

GLslang is a human readable description language for setting up pipeline resources.

That's one way of looking at it. Another way of looking at it is as a language that is compiled into GPU opcodes to be run on various programmable processors on a graphics chip. Obviously, if the hardware has no programmable processors, glslang is hardly appropriate for it.

The beauty is that you can detect cases where you oversubscribe resources, this can automatically apply to non-present features (eg dependant reads).

Looping isn't a resource. Conditional branches aren't resources. They are fundamental parts of a language without which, you're just programming in a glorified assembly. Loops, branches, and functions are what separates C from assembly. So, what good does it do to use C on a system that fails to compile if you use loops, branches, functions, etc? You may as well be using assembly, or even NV_register_combiner/texture_shader*.

Just like today, if the shader doesn't want to run, you trim down until you find something that does (or you drop through your minimum reqs and give up).

There's a difference between restructuring your code to use fewer temoraries and not using loops/etc. Clearly, if your algorithm called for a loop, you really needed to loop over some quantity. Simultaneously, if your algorithm called for a conditional branch, you really did need to branch based on that.

This is the equivalent of saying, "Well, we have these language features, but they may or may not always work." If you can't tell beforehand whether or not the feature was going to work, what's the point of having the feature to begin with? Indeed, what's the point of the higher-level language?

That's like saying that texture objects are a suggested feature of OpenGL 1.1, that an implementation is OK to not apply them. No, it's not OK for a 1.1 implementation to not have texture objects; the spec says those functions are there, so any 1.1 implementation will have these functions.

The glslang spec says that glslang can have loops; therefore, it will have loops. Compilers that fail because of loops are not glslang-compilers; they are compilers for some other, proto-glslang, shader language.

The purpose of this is so that there is absolutely no incentive to programming using a subset of the full language. If you can use the language at all, you can use the full power of that language. Having sub-languages, where using the full language is forbidden or discouraged for whatever reason, is a bad idea.

I hate this. In essence it's just whining and laziness.

That's one way to look at it. Another way might be that this is a rational idea, founded in the understanding that, in order to progress, we must leave the old ideas behind us. Do you want glslang to look like NV20-based Cg shaders?

In my mind, it can't really harm to start building the required expertise with simpler architectures. You know, learn to walk before you run. It's really shameful to see all these cheap excuses for not doing it. It will have to be done anyway, why not start now?

Why will it have to be done? In 2 years, nobody will be using GeForce 3/4 hardware. It'll be obselete, and all the work done to make them use glslang will be for naught.

I'll just quote two bullet points from the 3DLabs GDC pres, that IMO sum it up nicely.

I'd like to point out that the glslang 3DLabs proposed was more flexible, and had even less of a chance of being used in low-end machines. Indeed, a GeForceFX or Radeon9500+ couldn't hope to run the full language.

[zeckensack]

Korval,

That's one way of looking at it. Another way of looking at it is as a language that is compiled into GPU opcodes to be run on various programmable processors on a graphics chip. Obviously, if the hardware has no programmable processors, glslang is hardly appropriate for it.

The difference between 'programmable' and 'configurable' is purely artificial. Look at Geforce 3, where programmability was claimed by marketing, while in reality it's just a configurable machine. The only definition of 'true programmability' I would accept is the ability to fetch and execute opcode streams from memory. This mainly serves the purpose of allowing arbitrary program length. A Geforce 3 obviously doesn't offer this.

Looping isn't a resource. Conditional branches aren't resources. They are fundamental parts of a language without which, you're just programming in a glorified assembly.

Loop control is a hardware resource, because the availability of any opcodes fit for looping is a hardware trait. Look at the limitations given in the NV30 launch information, and you'll see that loops can also be oversubscribed. Duh. In fact, there's sufficient evidence towards a lack of conditional jump instructions on NV30 ('kil' doesn't save cycles), that kind of rules out loops and branches, no?

Conditional branches can also be expressed without explicit hardware support. Keyword: predication. Ever heard of Itanium? Oh, btw, Itanium has limited resources for predication, you should try not to oversubscribe them. Better hope your compiler sorts that out for you.

Predication can even be simulated on simpler SIMD machines. And it can certainly be implemented on a Geforce 3 (within the limits of program length of course). Beg your pardon, but I know what's possible and what's not possible, I've been there.

There's a difference between restructuring your code to use fewer temoraries and not using loops/etc. Clearly, if your algorithm called for a loop, you really needed to loop over some quantity. Simultaneously, if your algorithm called for a conditional branch, you really did need to branch based on that.

There is no difference. Fixed count loops can be unrolled, branches can be inlined, conditional branches can be predicated. This fits the term 'restructuring' quite well, I'd say.

This is the equivalent of saying, "Well, we have these language features, but they may or may not always work." If you can't tell beforehand whether or not the feature was going to work, what's the point of having the feature to begin with? Indeed, what's the point of the higher-level language?

It doesn't work this way. Try another.
Counterquestion: What's the point of implementing an NV30 path, if that may not run on the user's machine (because he doesn't have an NV30)? What's the point in supporting register combiners, or ATI_fragment_shader?

It's an optional path, if you detect that you can't use it, you fall back. Doing this on top of a common interface would be better, not worse than anything OpenGL programmers currently need to go through.

The glslang spec says that glslang can have loops; therefore, it will have loops. Compilers that fail because of loops are not glslang-compilers; they are compilers for some other, proto-glslang, shader language.

We're talking about runtime compilation. You cannot even tell beforehand whether anything will fail. You can write shaders today that won't compile anywhere but that might compile and run fine on hardware in two years, without touching the code. Even on the 'proper' GLslang targets that aren't yet on the market (your view, not mine), compilation is bound to fail with too much shader code. Does this really defeat GLslang?

You somehow pretend that GLslang - because it resembles C - means 'unlimited resources', which is clearly not the intent. Every machine is limited, and it's clearly the compiler's job to hide these limitations from you. I repeat myself, there are mechanisms to detect compilation (!=compiler) failure, and they are surely there for a purpose.

I wish to do this with 'proto' GLslang because it's reasonable to concentrate research efforts on one interface, one that will eventually become very important, rather than scattering time and energy over different syntactically incompatible things (nvparse, Cg, PS1.1, whatever). I'd like to see the most versatily and well designed choice go forward as fast as possible, that also requires creating incentive to use the interface. That's all.

That's one way to look at it. Another way might be that this is a rational idea, founded in the understanding that, in order to progress, we must leave the old ideas behind us. Do you want glslang to look like NV20-based Cg shaders?

GLslang can express all NV20 shaders. Why would I want to detract development efforts toward Cg, when I know it's destined to eventually die? ( my take on some of NV's official Cg statements )

Why will it have to be done? In 2 years, nobody will be using GeForce 3/4 hardware. It'll be obselete, and all the work done to make them use glslang will be for naught.

Two part rebuttal:
1)You're dreaming. Nobody uses a Geforce2MX anymore, right? Half Life 2 is slated for release this year. The official statement is that RivaTNT class hardware will be fully supported.
2)You again miss the point of runtime high level compilers. Even if the hardware around then will be much more capable, you don't need to patch old applications to fully utilitze it. Frankly, you shouldn't bother, it's not your responsibility to patch your old stuff for higher efficiency on new hardware. The only ones interested in that sort of thing are the hardware vendors, so they should carry this burden. Not much of a burden anyway, if we could manage to consolidate on a single codepath that can be optimized to hell and back with all the saved manpower that isn't required anymore for maintaining the old clutter.