Speed FP/VP vs. GLSL
Author
I am going to assume their is no speed delta between the two shader paths. I am as of now converting over to GLSL from FP/VP and have been able to reduce some texture needs so in a sense GLSL is faster but only due to less texture units needed... Anyone else seen this ability to reduce texture units that are needed when using GLSL?
I don't see how glsl would inherently reduce the amount of texture units needed without, of course, changing your actual algorithm. Maybe you can explain exactly what you did?
If anything GLSL would be slightly slower than will written ASM code, but only because it has to rely on the drivers compiler, which may or may not give you optimal performance. (Most of the time it's not going to make a bit of difference though.) Even so, there is no way that it could change the amount of texture use unless you changed the algorithm, as stated before. For example, if you go from using a normalization cube map to mathmatic normalization.
There is no way to tell if Assembler or GLSL is faster it depends on the card and how it works. On a newer card designed with GLSL they can compile into the card's native microcodes ( or whatever it is) and it could actually be faster than assembler. Those assembler opcodes are not necessarily how the card works, if you read the ARB documents you see they explain what those instructions should do at the bare minimum to be compatible with the spec. I really doubt the cards have an actual assembler instruction set like that, every card manufacturer has a very different architecture internally. They just have to support the programmable features in a way that are compliant to the specs.
Quote:Original post by Toji
If anything GLSL would be slightly slower than will written ASM code, but only because it has to rely on the drivers compiler, which may or may not give you optimal performance. (Most of the time it's not going to make a bit of difference though.) Even so, there is no way that it could change the amount of texture use unless you changed the algorithm, as stated before. For example, if you go from using a normalization cube map to mathmatic normalization.
Newsflash: compilers produce faster code than gamedevers copypasting tutorials together.
Most likely the compiler is a better optimizer than you. This has been common knowledge around, since 1997? There isn't much point trying to beat the compiler, especially since the GLSL compilers are fairly simple and modern.
This is merely my opinion, but GLSL yields to much more readable and accessible code than the card ASM and also gives the developer patterns such as recursion and conditionals, which combined probably give a lot better results since you can do your own states in the shader. Furthermore you aren't forced to switch shaders in the midst of rendering which is quite expensive operation altogether.
Anyway, I don't know about you guys but I take readable code any day over faster one.
Quote:Original post by el capitanQuote:Original post by Toji
If anything GLSL would be slightly slower than will written ASM code, but only because it has to rely on the drivers compiler, which may or may not give you optimal performance. (Most of the time it's not going to make a bit of difference though.) Even so, there is no way that it could change the amount of texture use unless you changed the algorithm, as stated before. For example, if you go from using a normalization cube map to mathmatic normalization.
Newsflash: compilers produce faster code than gamedevers copypasting tutorials together.
Most likely the compiler is a better optimizer than you. This has been common knowledge around, since 1997? There isn't much point trying to beat the compiler, especially since the GLSL compilers are fairly simple and modern.
This is merely my opinion, but GLSL yields to much more readable and accessible code than the card ASM and also gives the developer patterns such as recursion and conditionals, which combined probably give a lot better results since you can do your own states in the shader. Furthermore you aren't forced to switch shaders in the midst of rendering which is quite expensive operation altogether.
Anyway, I don't know about you guys but I take readable code any day over faster one.
Heh, but that isn't the *only* reason. Like I said, GLSL can compile into a format more suitable to the card than ARB assembler. ARB assembler is a virtual machine, it only exists as a guideline to what those instructions should do as a bare minimum. With GLSL they don't have to provide an assembler virtual machine and can assemble directly to the native cards interface, which could potentially be much faster than ARB assembler.
Even if it is not faster shaders are getting complex enough now that writing them in Assembler would be very tedious.
Author
Quote:Original post by James Trotter
I don't see how glsl would inherently reduce the amount of texture units needed without, of course, changing your actual algorithm. Maybe you can explain exactly what you did?
Well for one you have noise functions available to you as soon as they get around to it in GLSL... so you could drop a texture unit for a noise texture. You can procedurally create a texture in GLSL where I don't know if thats possible in FP/VP code since you have no if\else statements. I am going to assume you can make a shadowmap on the fly in GLSL with variables being passed into GLSL instead of a texture unit having a shadowmap render to texture process?? <-this thought I might be totally wrong on and if so please correct me ;)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
