First, I do not subscribe to the notion that what Carmack says is the divine word of God, or even more significant than what any other graphics programming professional would say. Plus, logic is with me; the source of an argument or position is irrelevant to the veracity of that argument or position.
I agree. Don’t flame me. I didn’t say that. When I quoted Carmack it was just to add one more opinion that I thought It was relevant to this thread.
Equally importantly, Carmack just wants someone else to write the dull, boring, boilerplate code for him. He wants driver developers to write code that takes a shader and breaks it down into multiple passes for inferior hardware so that he doesn’t have to do it. He’s looking ahead to his next engine knowing full well that he’s going to have to write some boring code into that engine to be able to run on R300 hardware just as much as R600 with the same shaders.
Wasn’t that the purpose of drivers? To make boring hardware abstraction layers once, instead of forcing application programmers to do it in every app they code?. Will this situation, where you have to code a shader for each generation of GPUs, last forever?
Do CPU programmers detect if their CPU is K6/K7/K8/P3/P4 and code a different program? NO, the compiler takes care of this, the only difference the user sees is that it runs different speeds.
personally ive never even written a arb_vp or arb_fp, why not, well after spending time learning gl1.0 then/multitexture/combine/register_combiners etc. and realising they became outdated quickly, i didnt want to make the same mistake again, spending all that effort to learn something that is practically useless today.
I totally agree. It’s just a matter of “when” assembly shadign languages will become useless, and when this happens all the effort spent learning them would have been a waste of time.
If you start coding your engine today, I bet that when you finish it GLSL will have a decent support.
Personally, I disagree. Stability comes first in my opinion. If it doesn’t run, it really doesn’t matter how fast it could have run.
I just wanted to add that.
Concerning ARB_fp/vp being extended:
Though I never use it, I could see why some people obsess over that extra 2.643% performance gain - that’s why it’s nice to have that tool available (Same with ASM for CPUs).
To me, such a gain is nonsense and is easily overshadowed by the cut in development time from a high level language.
Naturally there are driver bugs, and I don’t disagree that GPUs aren’t CPUs.
But the topic was the future of shaders and shader hardware - GPUs should be like CPUs. I’m talking about how things should be here.
Do CPU programmers detect if their CPU is K6/K7/K8/P3/P4 and code a different program? NO, the compiler takes care of this, the only difference the user sees is that it runs different speeds.
exactly my point: this sort of thing would suck.
All I’m arguing is that the development phase shouldn’t be all mirked up with hacks for workarounds to bugs.
To make boring hardware abstraction layers once, instead of forcing application programmers to do it in every app they code?
Yes, but multipassing in drivers is far from a “hardware abstraction layer”. It looks much more like a “scene graph” or “engine”, and thus has no place in OpenGL.
Originally posted by Aeluned:
[b][QUOTE]
Personally, I disagree. Stability comes first in my opinion. If it doesn’t run, it really doesn’t matter how fast it could have run.
I just wanted to add that.
Concerning ARB_fp/vp being extended:
Though I never use it, I could see why some people obsess over that extra 2.643% performance gain - that’s why it’s nice to have that tool available (Same with ASM for CPUs).
To me, such a gain is nonsense and is easily overshadowed by the cut in development time from a high level language.
[/b]
There are two ways to interpret the conversation.
I think it wasn’t “Which is of prime importance : performance or stability”.
GLSL shaders are buggier and have worst performance “on certain cards”.
What’s the point of using GLSL if it can cut >35% your performance.
Both performance and stability is needed, otherwise I might as well write my 100 line shader in assembly or use a third party high level language that targets ARB_vp/fp.
Originally posted by Aeluned: [QUOTE]
Naturally there are driver bugs, and I don’t disagree that GPUs aren’t CPUs.
But the topic was the future of shaders and shader hardware - GPUs should be like CPUs. I’m talking about how things should be here.
I really don’t know what this is suppose to mean.
Shaders CAN be a bottleneck.
What attribute of CPU’s do you want ported to GPU’s? What would make GPU run shaders faster/better?
Originally posted by Korval: [quote]To make boring hardware abstraction layers once, instead of forcing application programmers to do it in every app they code?
Yes, but multipassing in drivers is far from a “hardware abstraction layer”. It looks much more like a “scene graph” or “engine”, and thus has no place in OpenGL.[/QUOTE]Eh? What has multipassing a triangle got in common with scenegraphs or ‘engines’?
The driver is in the best position to decide how to split a job across its resources…we don’t have to tell the driver how to best use it’s 16 vertex pipes or whatever, so why, if we have a suitable high level shader language to describe a job, should we have to tell it how to use its pixel pipes in order to accomplish the shader?
It’s the next logical step, but of course this asm/c hybrid step is needed too, but I wouldn’t dismiss multipassing in the driver as never being appropriate because it’s a ‘scene management’ issue!
Originally posted by knackered: [quote]Originally posted by Korval: [quote]To make boring hardware abstraction layers once, instead of forcing application programmers to do it in every app they code?
Yes, but multipassing in drivers is far from a “hardware abstraction layer”. It looks much more like a “scene graph” or “engine”, and thus has no place in OpenGL.[/QUOTE]Eh? What has multipassing a triangle got in common with scenegraphs or ‘engines’?
The driver is in the best position to decide how to split a job across its resources…we don’t have to tell the driver how to best use it’s 16 vertex pipes or whatever, so why, if we have a suitable high level shader language to describe a job, should we have to tell it how to use its pixel pipes in order to accomplish the shader?
It’s the next logical step, but of course this asm/c hybrid step is needed too, but I wouldn’t dismiss multipassing in the driver as never being appropriate because it’s a ‘scene management’ issue![/QUOTE]There might be several issues, like for example :
the driver must not compromise the gl states in case the program also uses the fixed path.
the program might just run far too slow if we keep doing multipass/multitexturing
some shader stuff will not be possible using the fixed path unless we do some demoscene-like tricks that might compromise the program behavior. Maybe the program don’t want us to mess the alpha buffer , or whatever.