PDA

View Full Version : ARB FP 1.1



titan
11-12-2003, 02:02 PM
Has this been released yet? If not when is it due out?

I've heard they change the way shadow maps work to something more logical so you don't have to manually do the comparison yourself.

Humus
11-12-2003, 08:34 PM
Given that the GL2 shading language has been approved already I don't think any addition to any assembly languages are going to happend.

cass
11-12-2003, 09:09 PM
Originally posted by Humus:
Given that the GL2 shading language has been approved already I don't think any addition to any assembly languages are going to happend.

We're working with other ARB members on this now, but I don't have an ETA or a spec.

Humus
11-13-2003, 06:51 AM
Working on a FP1.1 extension you mean? With GLSL already ratified I would consider that wasted time and unneccesarily fragmenting the API.

[This message has been edited by Humus (edited 11-13-2003).]

mrbill
11-13-2003, 07:04 AM
Originally posted by Humus:
Working on a FP1.1 extension you mean? With GLSL already ratified I would consider that wasted time and unneccesarily fragmenting the API.
Of course it's fragmenting the API, it's ARB_fragment_program afterall. (Or was that an unintentional pun?????)

IMHO it's not a waste of time. But I do apologize for taking so long. (To set expectations a bit, the exension to the extension is *not* large.)

-mr. bill

Ostsol
11-13-2003, 07:33 AM
Would it happen to be meant to match the featureset of ARB_fragment_program with ARB_fragment_shader, thus providing low-level equivalents to everything in GLslang? http://www.opengl.org/discussion_boards/ubb/smile.gif

azazello
11-13-2003, 08:19 AM
Agree with Ostsol.
Until now assmebler exist on PC, and don't have any plans to die. I will happy to have a choice to do some part of code in low level.

Zengar
11-13-2003, 10:17 AM
Sorry for going off-topic, but it would be nice if GLSlang could support fixed-point precision. I own a CineFX card and I would like to use it features completely. Like:

#ifdef CineFX define int12 fixed
#else define int12 int

Would appreciate if Nvidia's team could implement it. It shouldn't be too complicated, I guess.

azazello
11-13-2003, 10:55 AM
2Zengar

I'm not sure, that fixed12 exist on CineFX chips starting from nv35 - people from Nvidia can explain this better.

And if is no fixed type in future hardware - why you need a support for it?.


[This message has been edited by ayaromenok (edited 11-13-2003).]

Zengar
11-13-2003, 12:56 PM
Originally posted by ayaromenok:
[B]2Zengar

I'm not sure, that fixed12 exist on CineFX chips starting from nv35 - people from Nvidia can explain this better.

And if is no fixed type in future hardware - why you need a support for it?.
[B]

I understand it very good, but my problem is that I bought a FX5600 and I would like to be able writing runable shaders for it. And why are you so shure that next generation cards wouldn't have any fixedpoint precision? It could be useless with HDR, but 12-bit fixed present almost the same presision as 16-bit floats. And I heared rumours that NV40 would have support for 16-bit-fixed-numbers some time ago(take it not too serious). I would like it if fixed type would be added to the core of GLSlang. Mabe fixedpoint will become popular in some distant future, so we will have the base for longlasting optimisations.

Ostsol
11-13-2003, 02:20 PM
Ack! Please, let's stay away from these arguments! There's pretty much nother new to add to the issue. . . Also, I'm already feeling tempted to jump in and. . ! *slaps himself* That was close. . . http://www.opengl.org/discussion_boards/ubb/frown.gif

[This message has been edited by Ostsol (edited 11-13-2003).]

zeckensack
11-13-2003, 05:22 PM
Integers are a viable solution for loop counters. On CPUs they're cool for memory pointers and stuff but I don't see that happening right now in the graphics world.

Otherwise, if you have a fast floating point format, you can rely on that and don't need fixed point formats (aka consolidation).
AFAICS NVIDIA are going there, too http://www.opengl.org/discussion_boards/ubb/smile.gif

... though I understand the problem, Zengar; maybe you should've just bought a different card.
I can't run shaders with more than three texture indirections (four according to ARB_fp terminology).
*shrugs*

cass
11-13-2003, 11:19 PM
As MrBill says, the plan for ARBfp1.1 is a very small incremental update to ARBfp1.0.

It should be useful for developers who using ARBfp1.0 today. It's not disruptive, and it shouldn't take away from GL Shading Language efforts in any way.

Thanks -
Cass

Humus
11-14-2003, 01:00 AM
Originally posted by mrbill:
Of course it's fragmenting the API, it's ARB_fragment_program afterall. (Or was that an unintentional pun?????)

IMHO it's not a waste of time. But I do apologize for taking so long. (To set expectations a bit, the exension to the extension is *not* large.)

-mr. bill

Lol, no pun intended http://www.opengl.org/discussion_boards/ubb/smile.gif

Well, if it's a minor tweak to the existing ARB fp to add a few missing instruction on current crop of hardware, then fine. But to continue expanding on the assembly side in the long term would be counterproductive IMHO. In the long term I'd only want the HLSL extended. In the near future people that code their shaders in assembly will be like the tiny backwards crowd that still do general application programming in assembly.

Humus
11-14-2003, 01:04 AM
Originally posted by Zengar:
I understand it very good, but my problem is that I bought a FX5600 and I would like to be able writing runable shaders for it. And why are you so shure that next generation cards wouldn't have any fixedpoint precision? It could be useless with HDR, but 12-bit fixed present almost the same presision as 16-bit floats. And I heared rumours that NV40 would have support for 16-bit-fixed-numbers some time ago(take it not too serious). I would like it if fixed type would be added to the core of GLSlang. Mabe fixedpoint will become popular in some distant future, so we will have the base for longlasting optimisations.


There is a distict possibility that future cards may offer fixed point support, but I don't think it will be common in future. So I don't think it should be in the standard GLSL, but of course if nVidia want fixed point support they can just add it as an extension.

nystep
11-14-2003, 02:35 AM
Would be nice to have some conditionnal branch support in ARB_VP in a future revision of the assembly langage. Isn't this supported by some GPUs already?

By the way, it's a good news that the assembly langages will be updated too. :-)

Zengar
11-15-2003, 01:15 AM
@Humus: übrigens, wie ist deine Deutschprüfung gelaufen? http://www.opengl.org/discussion_boards/ubb/smile.gif

vincoof
11-15-2003, 04:49 AM
Ist Deutsch für ARBfp1.1 notwendig? Für die überbuffers würde verstehe ich... http://www.opengl.org/discussion_boards/ubb/wink.gif

(sorry for the off-topic post)

I think that we will need low-level and high-level languages for a long time. ASM languages are not likely to vanish, and so do ARB_vp and ARB_fp in my opinion (except for a better language, but still a low-level one).

[This message has been edited by vincoof (edited 11-15-2003).]

V-man
11-15-2003, 09:28 AM
IMO, ARBfp1.1 should have been ARBfp1.0 in the first place, or 1.0 and 1.1 should have been released in parallel a long time ago.

Both vp1.0 and fp1.0 are very limited.

What's the reason for the update? GLSL will be taking a long time to arrive?

davepermen
11-15-2003, 03:18 PM
Originally posted by vincoof:
Ist Deutsch für ARBfp1.1 notwendig? Für die überbuffers würde verstehe ich... http://www.opengl.org/discussion_boards/ubb/wink.gif

hm.. shall i say how your test results would have been?..

but yes, humus, how was the test?

Humus
11-16-2003, 12:13 AM
Originally posted by Zengar:
@Humus: übrigens, wie ist deine Deutschprüfung gelaufen? http://www.opengl.org/discussion_boards/ubb/smile.gif

Ich weiss nicht. Das Resultat ist noch nicht fertig. Aber ich glaube dass es gut geläuft hat. Es fühlte ziemlich gut.

zen
11-16-2003, 06:41 AM
Aber ARB_fp/ARB_vp sind ja nicht...

ehh,... sorry, so I was saying:
But ARB_fp/vp are not assembly languages, just assembly-like. I mean if all GPUs had a standard instruction set(not sure if this would be necessarily a good thing) then I would agree, that exposing the GPUs native instruction set and writing high-level language compilers to compile high-level code to machine code should be the way to go, no doubt about it. But since ARB_fp/vp is just an-assemply like virtual machine-like layer on top of the GPU's native instruction set, building the compiler into the driver and bypassing assembly-like layers actually makes more sense(I mean it's closer to how the CPU works). With ARB_fp/vp you have:
HLSL -> VM asm code -> native asm code
while by eliminationg the assembly like layer you would get:
HLSL -> native asm code
What's the use of the intermediate code layer? You just don't have access to the machine code layer and that's, in essence, what I'm trying to say: beeing able to write machine code via some assembler should be quite useful but since instruction sets differ it must be handled by the driver (for now). Keeping an ASM-like VM layer in-between isn't the same thing. Of course I'm assuming that this VM layer(fp/vp) exposes no more functionality than the high-level language which I'm not sure of as I don't know much about the GLSL yet.
And of course there are other problems with the HLSL-compiler-in-the-driver approach but I just wanted to say that fp/vp and HLSL isn't the same as C and assembly and so keeping (and wasting effort to maintain) ARB_fp/vp wouldn't make that much sense.
But then again I may be completely wrong...

MZ
11-16-2003, 09:16 AM
I've heard they change the way shadow maps work to something more logical so you don't have to manually do the comparison yourself.

How about adding ps2.0-like per-instruction partial precission hint?

Zengar
11-16-2003, 09:20 AM
As I already mentioned somewhere, I would prefer if hardware would expose it's native assembly, so that third-party users could write there own HLSL. I need to see GLslang in action to make up my mind, thought.

harsman
11-16-2003, 12:54 PM
Yay! Please fix the shadowmap mess so things work like in glslang, the way it should've been from the beginning.

jwatte
11-17-2003, 07:04 PM
I'd like branching in VP, and predication in FP; if I get those two things, the rest of the feature requests aren't all that important. Although filtered shadow maps would be nice, especially if there's sufficient ability to tell whether this costs me instructions or not.

mw
11-22-2003, 02:48 AM
I like the idea of having a high level API and a low level API - even if the low level API is a "virtual machine" in itself.

If ARB_VP and ARB_FP would support conditional branching and jumps (as some vendor specific extensions already do), they were no less powerful then GLSL - and maybe it would be easier for videocard vendors to use an assembler like language as testbed for new capabilities, than having to implement everything in a more complex C-like language (which could be done later on, when everything works).

If one doesn't want to use a C-Style HLSL it would seem more naturally to me, to write a compiler which generates "assembler like" output, than having to create a Pascal to C crosscompiler for example.

So in my opinion ARB_FP and ARB_VP are a viable solution for the future und should be maintained parallel to GLSL, maybe even integrated in the core specification, since they should be easier to maintain than GLSL - (having that said, a kind of inline assembler with native hardware support in GLSL would be cream on the cake (code generation for different video cards and a fallback option to standard GLSL could be steered with #ifdefs) ).

Humus
11-22-2003, 06:40 AM
The problem with LLSLs is that they can never be optimal for all hardware, while a HLSL can, since they driver decides how to best map it onto the actual hardware.

Pop N Fresh
11-22-2003, 11:31 AM
C was originally designed as a sort of "portable assembler". When you try to abstract out the hardware it's pretty much what you end up with.

This is why all the various shading languages are C-like instead of Lisp-like or Java-like or whathaveyou. The idea of something lower-level yet still portable doesn't really work unless you want to underexpose the hardware. This is why there many different languages at different levels "above" C. From stuff like C++ to Java to Lisp to scripting languages like Perl and Python. But no common language in-between C and assembler. If you want to get low-level but portable its a C-like model or the highway (excepting perhaps Forth)

[This message has been edited by Pop N Fresh (edited 11-22-2003).]

zen
11-22-2003, 05:12 PM
Having two language APIs which are completely seperate (i.e. they both compile to native GPU machine code) is fine by me, although it would take more effort to maintain them. I just wanted to point out that layering a HLSL over an assembly SL is not the obvious way to go (as I initially believed) because in essence you just layer the HL language over a lower level VM which doesn't make much sense (since you can compile to native machine code right away), introduces added complexity and probably makes target-specific code optimization impossible. That's as far as the 'why not have access to the assembly code' (because you don't have it anyway) and the 'it's done this way with CPUs for decades' (bacause it's not) arguments are concerned. Of course in real life other non-technical factors matter like the effort to write and maintain and debug drivers (and an HLSL in there certainly adds complexity) etc., etc. but this is a whole different story.

davepermen
11-23-2003, 04:35 AM
well, ARBfp is actually a rather highlevel language. it is in asm-style, but it is, compared to NVfp, too, i think, a rather high level language.

why?

because you don't have to mess with registers. you have variables.

the only thing a c-style language has over it, is a stack. and the possibility to group instructions into so called "functions" http://www.opengl.org/discussion_boards/ubb/biggrin.gif

but the fact that we don't have to mess with registers makes ARBfp quite a step higher level actually.

Humus
11-23-2003, 06:53 AM
ARBfp isn't particularly HL. It's asm with some candy. It's more HL than DX's ps2.0, but much closer to ps2.0 than to HLSL.

mw
11-24-2003, 02:22 AM
ahem - if you write an assembler program on standard CPUs, you have a stack too, since everything any high level language can do, is provided from the machine the language runs on.

ARB_VP/FP are a high level language (and can of course be optimized, since a driver is not restricted in generating any native code).
They are no native assembler on any existing CPU - however, compared to a "real" CPU, the model provided by ARB_VP/FP has a very limited instruction set (no stack, jumps, etc. which could be changed in the next version), and so ARB_VP/FP are limited compared to a "real" assembler (I'm referring to PC compatibles) - but GLSL is very limited compared to "real" C either (and in some ways (inverse matrices) even limited to ARB_VP/FP), so that's not an argument.

What I _tried_ to say, is that it may be easier for video card vendors to maintain a "simple" assembler like language, than having to support a more complex high level language - therefore both, a low level language and a high level language make sense to me - even more since in some time most shaders won't be coded manually anymore, but created interactively by some advanced tools (and maybe optimized manually afterwards) - so it's not as important, that OpenGL provides a very advanced high level language, but that the language used is standardized and compatible between video cards and drivers.

The asm-like code however, is neither easier nor more difficult to post-optimize from a driver than C-like code, since most optimizers won't foresay what you "try" to achieve anyway (at least not correctly :^) ) but work as peephole optimizers to exchange some pieces of code with some other pieces with the same functionality but fewer or faster instructions.
The asm-like code _could_ (I may be wrong) however be easier to get working in a video card driver.

(Besides I like the simple and straight ahead interface to ARB_VP/FP, however, if my video card driver will support GLSL someday, I may like that too...)

davepermen
11-24-2003, 03:40 AM
Originally posted by Humus:
ARBfp isn't particularly HL. It's asm with some candy. It's more HL than DX's ps2.0, but much closer to ps2.0 than to HLSL.

well.. syntax is asm like and not c-like. but that doesn't make a language high or lowlevel. ARBfp has variables, as HLSL does. it doesn't have functions, as HLSL does. ps2.0 doesn't have variables. so ARBfp is-between of both.

and i prefer the asm syntax then, and compile from a higher level language down to it. i don't believe in all that realtime-highlevel-compile stuff.. install time possibly, yes.. but definitely not "everytime i change a shader" time..

yes we have 3gig pc's today. but no i don't want to waste my cycles all the time to have all sort of recompilations running. .NET platform, opengl/dx HLSL compilations, all the fuzz..

you can solve every problem with another layer, except the problem of too many layers.

we have much too many today.

M/\dm/\n
11-24-2003, 04:05 AM
Yeap, layers are prety bad because of that (.NET http://www.opengl.org/discussion_boards/ubb/mad.gif ). But they alow you to create more crossplatform progs. I don't know which way is better. It's a lengthy job to write driver that will compile GLSL to native instructions + fp to native instructions + all the proprietary vp's/fp's to same instr'ns http://www.opengl.org/discussion_boards/ubb/biggrin.gif . But it's hard to do something without layers nowadays.

Humus
11-24-2003, 08:03 AM
Originally posted by mw:
The asm-like code however, is neither easier nor more difficult to post-optimize from a driver than C-like code, since most optimizers won't foresay what you "try" to achieve anyway (at least not correctly :^) ) but work as peephole optimizers to exchange some pieces of code with some other pieces with the same functionality but fewer or faster instructions.
The asm-like code _could_ (I may be wrong) however be easier to get working in a video card driver.

I have very good reasons to think you're wrong on both points. I don't want to write lengthy posts about it, but will rather refer to this 20 page thread on beyond3d: http://www.beyond3d.com/forum/viewtopic.php?t=8589


Originally posted by mw:
(Besides I like the simple and straight ahead interface to ARB_VP/FP, however, if my video card driver will support GLSL someday, I may like that too...)

Trust me, once you've tried an HLSL you're not going back.

Humus
11-24-2003, 08:08 AM
Originally posted by davepermen:
well.. syntax is asm like and not c-like. but that doesn't make a language high or lowlevel. ARBfp has variables, as HLSL does. it doesn't have functions, as HLSL does. ps2.0 doesn't have variables. so ARBfp is-between of both.

and i prefer the asm syntax then, and compile from a higher level language down to it. i don't believe in all that realtime-highlevel-compile stuff.. install time possibly, yes.. but definitely not "everytime i change a shader" time..

yes we have 3gig pc's today. but no i don't want to waste my cycles all the time to have all sort of recompilations running. .NET platform, opengl/dx HLSL compilations, all the fuzz..

you can solve every problem with another layer, except the problem of too many layers.

we have much too many today.

Calling your variables "lightVec" and "viewVec" instead of r0 and r1 doesn't make it high level. It's a convenience, but it's still low level.

Compilation takes place on load time, just like with asm shaders (which also needs to be compiled). Not when you switch shaders.

davepermen
11-24-2003, 09:36 AM
humus: not having to manage your registers yourself but getting that done by the compiler DOES making it higher level.

in ps2.0 you can #define around to get the namings.

but ARBfp has VARIABLES. you don't need to bother about wich register you now have in use where and how. this CAN be done for ARBfp by the compiler. it can NOT if you code yourself with the registers directly.

register allocation got abstracted away.

that DOES make it higher level.

davepermen
11-24-2003, 09:37 AM
i know when shaders get compiled, humus. i know very well what i'm talking about. you don't need to bother about my issues. i do http://www.opengl.org/discussion_boards/ubb/biggrin.gif

mw
11-24-2003, 09:50 AM
Well Humus, I stepped through your 20p+ monster - and while it wasn't entirely ontopic (ahem), it was (sometimes) interesting nevertheless.

One thing I didn't think of was, that the ARB Shader Assembler would map a subset of current hardware capabilities, wheras I thought it was an entirely virtual machine.
If it IS virtual, it's no difference to GLSL to optimize it (high level structures are not needed to optimize - in the end every kind of code structure is a set of conditional jumps, which may be optimized as well if they are in an Assembler like language).
The current specification has to be changed however (at least conditional jumps) - and maybe you're right, that this is the time to step to a higher level language, where it's easier to define scalars and vectors, letting the driver doing the work how to implement them best in hardware (you sound quite convincing in this point, as I have to admit (and not being too happy about it)).