Printable View
Ector, as always if you have specific use cases or functionality that you can describe here that would make your app easier to develop (or perform better etc) please post them in the perpetual "talk about your applications" thread too.
http://www.opengl.org/discussion_boa...133#Post246133
I've already talked about my main issue - the requirement to explicitly link vertex and pixel shaders. It's just weird. Why? It's not necessary when using either ARB_*_program, Cg or HLSL. My app uses insane amounts of combinations.
I also share about 40 float4 constants between all pixel shaders, and over 200 between all vertex shaders (not all shaders use all of them, of course, but there's a lot of sharing going on). It's just too much overhead to keep uploading them once per shader. And since GLSL only supports uniform buffers on the newest hardware, using them isn't an option, while classic indexed constants works just fine.
You may ask, why this inefficient-looking design? Well, simply because my app is Dolphin, the Wii and Gamecube emulator, and I'm using shaders to emulate one of the most complex pieces of fixed function graphics hardware out there. It has MASSIVE configuration state, which is what we're using all these constants for.
OK that is one that we are well familiar with and is near the top of the priority queue. It's an issue that I know Blizzard and TransGaming have both run into as well.
The need to link shaders into a program is simply because of the varyings. GLSL doesn't let you specify which slot to take.
Try glProgramLocalParameters4fvEXT. Though, it requires you abandon GLSL: use nVidia asm for GF, and for ATi/Intel either
1) use old ARB-asm for ATi/Intel or
2) use GLSL but have your materials manually upload uniforms in a non-brute fashion or
3) use GLSL and uniform-buffers/texture-buffers/VTF if available
Imho, if you want to have speed and support SM2/SM3/SM4, there are 5 code-paths.
Quote:
Originally Posted by Ilian Dinev
Try void Uniform4fvARB(int location, sizei count, const float *value)
or void UniformMatrix4fvARB(int location, sizei count, boolean transpose, const float *value
uniform vec4 StreamVec4[ SIZE1 ];
uniform mat4 StreamMatrxi[ SIZE2 ];
instead ARB ASM ( which is obsoluted )
Тут по-русский понимает кто-нибудь ? :)
ARB asm is obsolete, but fast and supported correctly on all gpus.
NV asm is more modern than GLSL could hope to be; and loads/runs fast and without nV's shader-recompilation hiccups.
Afaik GLSL and its glUniform*() are fast on ATi, without hiccups - provided that they compile under a given card/driver combo.
glProgramLocalParameters4fvEXT's speed on E8500 @3.8GHz, SysRAM DDR3 @1.6GHz (timing 7-7-7-20), GF8600GT:
144 bytes: 108 cpu cycles
288 bytes: 224 cycles
1728 bytes: 607 cycles
So yes, gpu asm is as obsolete as C++ is to Java...
Fine. If I wrote shader on DX10 will it run on DX9 hardware ?Quote:
Originally Posted by Ilian Dinev
Why is it so non equal conditional for GL and DX ?
s/the community/you/. Please speak only for yourself and stop spreading FUD.Quote:
Originally Posted by Ido Ilan
The Khronos could have added more core features easily, such as geometry shaders, direct state access, long promised templated objects :)
However it's crawling so that Direct3D is guaranteed to stay ahead by years.
I don't have much of an opinion because the only thing I see that affects me is the uniform buffer objects feature. I never liked bindable uniforms, and ATI's first attempt to implement it didn't work for me, so I guess this is a good thing.
I'm still using OpenGL 2.1, and I am mostly satisfied since ATI's drivers have gotten a lot better. I think an instance shader would be useful, that could discard entire instances of an object before they are drawn, for trees and grass.
Really, for me the whole issue has not been Khronos but the state of ATI's drivers. And they have improved to the point where they are now usable.