Originally posted by Zengar:
Doom3 uses a special complex specular function, hence the lookup texture. Replacing it with common specular function(which was the idea of Humus- yes, if someone doesnât know it, Humus works for ATI
) is not correct way - as stated by Carmack himself.
Actually, my first implementation was incorrect as it wasnât a pow() function as I initially thought. Later revisions were fully equivalent though (and a good deal faster). He used saturate(4 * x - 3)^2, which could be implemented on Radeon/GF2 level hardware as well.
Originally posted by martinho_:
Itâs just a matter of time that assembly languages dissapear. Compilers can create portable and faster code than humans, optimized for present and future hardware. If they donât do so right now, they will in a near future (near enough for projects that start today).
Out of curiosity, when you say that itâs just a matter of time before assembly languages disappear, do you mean from OpenGL or from the CPU world as well?
Originally posted by valoh:
btw: Does any driver already support invariant uniform calculation optimizations? This would be an important optimization, but last time I checked it wasnât supported by ATI/nvidia.
Are you asking for something like the preshader in DX?
Originally posted by cass:
Out of curiosity, when you say that itâs just a matter of time before assembly languages disappear, do you mean from OpenGL or from the CPU world as well?
Itâs not gone already?
Even on the CPU, youâre probably better off using C++ code most of the time. Exceptions are 3DNow/SSE and the like. But even then, using intrinsics will probably work better and be quicker to write and debug and allows the compiler to optimize better across function calls and blocks etc.
Kronos, you just use the Cg syntax in GLSL.
GL_EXT_Cg_shader spec, if it exists, should mention this.
Originally posted by simongreen:
From a stability and robustness perspective, low-level languages are easier to get implemented quickly and correctly
Isnât most of the problems related to optimization?
The original expression is too complex, so you try to reorder it to make it fit the GPUâs resources and you end up ****ing up everything?
Originally posted by Humus:
Are you asking for something like the preshader in DX?
exactly.
Havenât used directx but I think this behaviour is called preshaders and handled by the fx framework. For glsl this should have been specified with a compiler flag to check if it is supported and a flag to enable/disable. Imo itâs a very important feature to allow a high level application/shader interface.
btw: as you are working with ATI/glsl every day. When can we do expect stable glsl/pbuffer support? this two bugs still hasnât been fixedâŚ
Originally posted by Humus:
[quote]Originally posted by cass:
Out of curiosity, when you say that itâs just a matter of time before assembly languages disappear, do you mean from OpenGL or from the CPU world as well?
Itâs not gone already?
Even on the CPU, youâre probably better off using C++ code most of the time. Exceptions are 3DNow/SSE and the like. But even then, using intrinsics will probably work better and be quicker to write and debug and allows the compiler to optimize better across function calls and blocks etc.[/QUOTE]I assume use that no significant amount of programmers uses CPU assembly anymoreâŚ
Again, itâs not a question of what you should write your code in, itâs a question of whether an assembly-level is useful.
Tools like compilers generate assembly. Having a common ISA target allows for different languages to link together into a single executable. It allows programs to generate fast machine code on-the-fly.
Could we really get by just expressing everything in high-level languages? I donât see how. As shaders get more complex (and begin to look more like CPU ISAs) it seems natural that the tool chain will want to go the way that it has on
the CPU side.
Will the GPGPU folks want to have their shader code look like GLSL, or will they want to tailor
it more toward their computational goals?
Will we have two separate HLSLs?
In a lot of ways âless is moreâ. With low-level access, you can provide an abstraction suitable
to your goals. Software developers are free to extend the language constructs however they choose.
Of course HLSLs are the future of shading. Whether theyâre based on an underlying assumption of an ISA is the question. ISA as a foundation for compiler tools and programmability is definitely the âtried and trueâ path.
I donât see what these bugs have to do with optimal code. GCC refuses to compile some valid C++ files occasionally. Doesnât mean itâs not producing fast code.
I guess ISVâs are funny about that kind of thing. Theyâve got this crazy notion that, before you start optimizing something, it should probably work first. I guess IHVâs like ATi have different notions about whether something is useful.
I, for one, donât agree that making something fast and broken is good.
Tools like compilers generate assembly. Having a common ISA target allows for different languages to link together into a single executable. It allows programs to generate fast machine code on-the-fly.
Admittedly, true, but then again, youâre not 3D Labs with their wierd vertex and fragment architecture.
We donât share ISAâs across PowerPCs and x86 chips. We donât ask a DEC Alpha to natively run x86 code. But shader hardware can be just as varied; as such, trying to create an ISA that provides for easy optimizations (which none of our current ones do) is not easy. Just look at the compiled code that comes out of your Cg compiler. Itâs fine for an nVidia card, but it does things that an ATi fragment program doesnât need to. High level constructs that a (theoretically functional) ATi compiler could have used to generate more optimal code has been lost. As such, passing the results of a compilation around is of no great value.
Thatâs not to say that I donât ultimately agree with you. The problem is that even ARB_vp/fp are simply too low level to create good optimizations from. Perhaps thereâs a happy medium between ARB_vp/fp and glslang, but nobodyâs currently working on it, so it wonât get developed.
Will the GPGPU folks want to have their shader code look like GLSL, or will they want to tailor
it more toward their computational goals?
On a personal note, OpenGL and the ARB should spend absolutely no time finding solutions for the GPGPU people. If they want to hack their graphics cards into CPUâs, fine, but they shouldnât expect a graphics library to help them at all.
Originally posted by Korval:
On a personal note, OpenGL and the ARB should spend absolutely no time finding solutions for the GPGPU people. If they want to hack their graphics cards into CPUâs, fine, but they shouldnât expect a graphics library to help them at all.
:mad: Thanks a lotPersonally I donât see a need for anything special for GPGPU. Itâs slowly coming together anyway. GLSL is fine for it - I donât use GPU asm personally. FBO will be fine when it arrives. Higher floating-point precision would be nice, but I wonât hold my breath for that - maybe 5-10yrs Iâd expect it. The main thing thatâll allow GPGPU to really come into itâs own is scattering. Will that arrive with DX10/OpenGL x.x? Dunno, but I wouldnât be surprised either way. If scattering is seen to be useful for graphics, then maybe. Itâd certainly be a much appreciated OpenGL extension (hint, hint Cass and Simon
). Other useful things - tools for OpenGL. Maybe a free shader debugger like Visual Studioâs HLSL debugger (but better - itâs a bit cumbersome for my liking).
ffish: How would a shader debugger work? would you run in some software mode(mesa?) with a custom extension to access variables as a shader is running?
The closest I can come with GLIntercept is to allow you to edit and re-compile the shaders back into the program at runtime. (ie. so you can move a variable into the output color to âseeâ the value)
Yeah, I guess. The D3D version you run with the Microsoft reference (software) rasterizer. Iâve only used it with C# and there are a number of pitfalls, but it still works mostly. Maybe the unmanaged C++ shader debugger works better. Unfortunately I canât see how anyone would want to create a tool like the HLSL version for free, but itâd be nice if they would.
Since Iâm doing GPGPU stuff, itâs kind of hard to see what changing values does at runtime. My textures are just a bunch of numbers and sometimes itâs hard to see whatâs happening. So your GLIntercept solution wouldnât work for me.
Correct me if Iâm wrong, but I think what Cass is talking about is a Java-like bytecode representation. That is, an almost 1-to-1 mapping of GLSL to âbytecodesâ, with no optimizations whatsoever (like D3D does) and probably higher level than ARB_vp/fp. The result could then be (greatly optimized and) executed on any architecture. Additionally, more languages (non-GLSL) could be created, as long as they could be compiled to these âbytecodesâ.
Hi spasi,
Yes, thatâs more or less what I mean. From a tool chain perspective, thereâs a target for compiling and linking. Then the driver performs a JIT phase of mapping the generic ISA onto the native architecture.
The generic ISA provides a reasonable hardware abstraction (but does not dictate actual underlying microarchitecture), and software developers can develop any sort of language tools they like on top of it.
This seems to be the way MS has gone, so any IHV hoping to sell D3D parts will already have to support this generic ISA.
Thanks -
Cass
I fully agree with mr. Everitt at this point.
We need low-level shading interface to have a possibility of providing different HL shading languages and toolkits.
But I still believe that a assembly-like language is not sufficient for such a goal as you still need too many compilation steps to compile the code to an native repserentaion. As a matter of fact, I am working on a virtual machine(just for fun), something like java or .NET but with abstract intermediate language. This language merely describes the state transformation chains. I found it to be much more effective with respect to further optimisation then usual assembly representation. Another advantage of such a system is ability to extend easily. Somethin glike this could be used for shading too.
Just my 2 cents 
I release that no company will suddenly develop a new method because I said so 
Cass,
I can see the advantages of such an architecture, but have a few questions:
-
Has this been discussed with other ARB members? Not in a âletâs extend the low-level languageâ manner, but given the mentioned advantages.
-
Are ARB_vp/fp (and whatever D3D uses) sufficiently abstract, or would something new be necessary? Also, I would expect this to work completely internally, something developers have no access to (no temptation to write low-level code, like a Java/.NET developer never writes bytecode).
-
Is NVIDIA willing or has plan to go after such an architecture for OpenGL? Not necessarily independently implement it, at least try to prove its usefulness.
Originally posted by sqrt[-1]:
ffish: How would a shader debugger work? would you run in some software mode(mesa?) with a custom extension to access variables as a shader is running?
Yes, you have to run it in software and no you donât need a custom extensions. D3D does it with itâs reference rasterizer.
Unfortunatly, this is only good to debug your shader.
Dumping the assembly to a file with the hw driver would be useful.
With ATI (3DLabs too), itâs a black box.
NV simply has the right solution.
Originally posted by spasi:
Cass,
I can see the advantages of such an architecture, but have a few questions:
- Has this been discussed with other ARB members? Not in a âletâs extend the low-level languageâ manner, but given the mentioned advantages.
There have been discussions, they just donât seem to go anywhere. I donât think enough ARB members are interested to have critical mass (yet).
- Are ARB_vp/fp (and whatever D3D uses) sufficiently abstract, or would something new be necessary? Also, I would expect this to work completely internally, something developers have no access to (no temptation to write low-level code, like a Java/.NET developer never writes bytecode).
No. Had we gone down the path of exending the
ASM it would have eventually been general enough,
I think. NVIDIA will continue to generalize this path with vendor extensions. For external tools to take root, there needs to be multi-vendor support for these general paths though. Thereâs no knowing when (or even if) that will happen.
- Is NVIDIA willing or has plan to go after such an architecture for OpenGL? Not necessarily independently implement it, at least try to prove its usefulness.
If other IHVs and ISVs were interested, Iâm sure NVIDIA would be involved. But thereâs no groundswell of interest/support for this direction today.
The opinions I have expressed on this thread are about the way I think things are likely to go. Iâm not trying to advocate action. After all, I could be wrong.
Thanks -
Cass
Originally posted by valoh:
[b]exactly.
Havenât used directx but I think this behaviour is called preshaders and handled by the fx framework. For glsl this should have been specified with a compiler flag to check if it is supported and a flag to enable/disable. Imo itâs a very important feature to allow a high level application/shader interface.[/b]
Yeah, itâs probably a useful thing going forward. I think what we need is not an assembly language (they break down occasionally as well), but rather more control for the application in terms of optimization flags, enable/disable preshaders and so on. Simply disabling optimizations should hopefully let many broken shaders run (although slow) until the bug is fixed.
If weâre talking about an intermediate language I might be in iff it doesnât destroy the semantics of the original shader. But then again, then weâre not really saving a whole lot more than the parsing.
Originally posted by valoh:
btw: as you are working with ATI/glsl every day. When can we do expect stable glsl/pbuffer support? this two bugs still hasnât been fixedâŚ
Iâm working with but not on (Iâm no driver writer) ATI GLSL, so donât know of when certain bugs will get fixed. But the bug you mention was just recently fixed. Donât know when it goes into a public driver though.
Originally posted by Korval:
I guess ISVâs are funny about that kind of thing. Theyâve got this crazy notion that, before you start optimizing something, it should probably work first. I guess IHVâs like ATi have different notions about whether something is useful.
On the other hand, the ISV people donât risk losing millions in sales because their bar was a few pixels shorter than the competition on a chart on Toms Hardware Guide.