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.
Given that the GL2 shading language has been approved already I don’t think any addition to any assembly languages are going to happend.
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.
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).]
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
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? 
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.
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.
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).]
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.
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. . . 
[This message has been edited by Ostsol (edited 11-13-2003).]
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
… 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
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
Originally posted by mrbill:
[b]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[/b]
Lol, no pun intended
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.
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.
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. 
Ist Deutsch für ARBfp1.1 notwendig? Für die überbuffers würde verstehe ich… 
(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).]
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?
Originally posted by vincoof:
Ist Deutsch für ARBfp1.1 notwendig? Für die überbuffers würde verstehe ich…
hm… shall i say how your test results would have been?..
but yes, humus, how was the test?