Understanding Shaders
Re: Understanding Shaders
@Granyte Actually, is there any newer article describing Flow Control in detail?
Currently the concepts pretty much still apply.
Technology certainly does 'evolve' just not by random mutation! Natural selection anyone?
Currently the concepts pretty much still apply.
Technology certainly does 'evolve' just not by random mutation! Natural selection anyone?
Re: Understanding Shaders
Ok, some good advice here.
So I know now to stay away from "if's" but do you guys know how performance behaves on computers with integrated graphics on their CPU? (No actual graphics card)
And then the only way I know to stay away from "if's" is to create a bunch of different shaders, which means a bunch of irrlicht materials. Is there any drawback from having so many? It doesn't eat at my GPU memory, does it?
And if the vertex shader runs per vertex and the pixel shader runs per pixel on screen, how does the vertex know which pixel to send the TEXCOORD(or whatever) data to?
So I know now to stay away from "if's" but do you guys know how performance behaves on computers with integrated graphics on their CPU? (No actual graphics card)
And then the only way I know to stay away from "if's" is to create a bunch of different shaders, which means a bunch of irrlicht materials. Is there any drawback from having so many? It doesn't eat at my GPU memory, does it?
And if the vertex shader runs per vertex and the pixel shader runs per pixel on screen, how does the vertex know which pixel to send the TEXCOORD(or whatever) data to?
Re: Understanding Shaders
after reading the height map i should have effectivly scaled my texcoord that's planed for the next time i revisit that shader i should also build a normal map generator instead of building it on the fly like i do in the current shader
from that i know the data is interpolated betwen the diferent vertex
IGP have BAD performance as when ever you have to load data into your shader it has to go through your cpu memory bus to acces your RAM where a real gpu has it's own memory wich is much faster for the kind of acces the gpu does and also it won't have to fight with the cpu to get data
kevinsbro wrote:Ok, some good advice here.
So I know now to stay away from "if's" but do you guys know how performance behaves on computers with integrated graphics on their CPU? (No actual graphics card)
And then the only way I know to stay away from "if's" is to create a bunch of different shaders, which means a bunch of irrlicht materials. Is there any drawback from having so many? It doesn't eat at my GPU memory, does it?
And if the vertex shader runs per vertex and the pixel shader runs per pixel on screen, how does the vertex know which pixel to send the TEXCOORD(or whatever) data to?
from that i know the data is interpolated betwen the diferent vertex
IGP have BAD performance as when ever you have to load data into your shader it has to go through your cpu memory bus to acces your RAM where a real gpu has it's own memory wich is much faster for the kind of acces the gpu does and also it won't have to fight with the cpu to get data
Re: Understanding Shaders
The if statements and many branching operations may be simplified by the shader code generation step if the shader compiler finds a way to simplify them to a non branched version. It is suprising to see how in many situations the branching operations are reduced to just one or two, and the shader still works the same.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Re: Understanding Shaders
Well here's another thought. Does it cost memory or performance to pass a texture to the shader?
-
- Posts: 1215
- Joined: Tue Jan 09, 2007 7:03 pm
- Location: Leuven, Belgium
Re: Understanding Shaders
Of course it costs memory and performance, you do an upload to video memory when you bind a texture. These uploads have to go through the driver, and driver calls are pretty slow in most cases (hence the reason why should keep state switches to an absolute minimum while rendering). Texture samples in shaders could be costly too, so that's another point to be aware of.kevinsbro wrote:Well here's another thought. Does it cost memory or performance to pass a texture to the shader?
For memory usage you can do the math yourself: Say you have a 1024x1024 texture in an RGBA format, this means you'll have 8 bits per channel or 32 bits per pixel, which comes down to 4 bytes per pixel. Multiply this by your resolution and you get 4 * 1024^2 = 4194304 bytes, or 4096 kb or 4Mb used in video memory
On current-gen cards this doesn't sound like much, but it doesn't mean you should not keep your texture usage in mind
Re: Understanding Shaders
Thank you so much for all the advice!
Re: Understanding Shaders
If you also use mipmapping (enabled by default) it adds also the 512, 256, 128, 64, 32, 16,8,4,2 and 1 pixel versions of the texture (2 extra megabytes) and the anisotropic filter versions only makes things worse, so, yes, it is costly to add a texture to a shader. Minimize texture accesses, and if you have to access a texture more than once, do it near the first sample, as the hardware also keeps a texture cache that exploits this kind of access pattern. The DX documentation states that the most optimal texture size is 256x256 pixels.Radikalizm wrote:Of course it costs memory and performance, you do an upload to video memory when you bind a texture. These uploads have to go through the driver, and driver calls are pretty slow in most cases (hence the reason why should keep state switches to an absolute minimum while rendering). Texture samples in shaders could be costly too, so that's another point to be aware of.kevinsbro wrote:Well here's another thought. Does it cost memory or performance to pass a texture to the shader?
For memory usage you can do the math yourself: Say you have a 1024x1024 texture in an RGBA format, this means you'll have 8 bits per channel or 32 bits per pixel, which comes down to 4 bytes per pixel. Multiply this by your resolution and you get 4 * 1024^2 = 4194304 bytes, or 4096 kb or 4Mb used in video memory
On current-gen cards this doesn't sound like much, but it doesn't mean you should not keep your texture usage in mind
These general tips apply the same to DX and OpenGL, take a look.
http://msdn.microsoft.com/en-us/library ... 85%29.aspx
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Re: Understanding Shaders
what the 512, 256, 128, 64, 32, 16,8,4,2 and 1 what is this even usefull for
also in my app i experience a wierd behavior when i upgrade my heightmap size from 1024 to 2048 my memory usage jump from 120 mb to 500 mb (6 face X 2048px X 2 planet) so i guess my menory usage is exponential or i'm jjust not cleaning somethig properly in my conversion from RTT to normal texture
also in my app i experience a wierd behavior when i upgrade my heightmap size from 1024 to 2048 my memory usage jump from 120 mb to 500 mb (6 face X 2048px X 2 planet) so i guess my menory usage is exponential or i'm jjust not cleaning somethig properly in my conversion from RTT to normal texture
Re: Understanding Shaders
1. Why not google mipmapping? Do you want me to do it for you?
2. It is quadratic, not exponential. A 10x10 crossword has 100 squares, a 20x20 crossword has 400 squares.
2. It is quadratic, not exponential. A 10x10 crossword has 100 squares, a 20x20 crossword has 400 squares.
Re: Understanding Shaders
shouldn't mipmaps add 1,33 of the total size to texture size? so that 4MB becomes 5,33MB?
Junior Irrlicht Developer.
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
Re: Understanding Shaders
No, 1/n^2 sums up to approx. 1.65, so it's 2/3 that are added. And it's a factor, not a sum, so for 4MB original picture this makes 2.6MB
Re: Understanding Shaders
Err, I don't think this is correct.
1 + (1/2)^2 + (1/4)^2 + (1/8)^2 + (1/16)^2 + (1/32)^2 + ... = 1 + .25 + .0625 + .015625 + .00390625 + .0009765625 + ... ~ 1.4.
So 4 MB blows out to 5.6 MB.
1 + (1/2)^2 + (1/4)^2 + (1/8)^2 + (1/16)^2 + (1/32)^2 + ... = 1 + .25 + .0625 + .015625 + .00390625 + .0009765625 + ... ~ 1.4.
So 4 MB blows out to 5.6 MB.
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
Re: Understanding Shaders
Ah right, you only have a very few intermediate steps
Re: Understanding Shaders
I did a rough approximation.REDDemon wrote:shouldn't mipmaps add 1,33 of the total size to texture size? so that 4MB becomes 5,33MB?
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt