Understanding Shaders

You are an experienced programmer and have a problem with the engine, shaders, or advanced effects? Here you'll get answers.
No questions about C++ programming or topics which are answered in the tutorials!

Re: Understanding Shaders

Postby ACE247 » Sat Jan 14, 2012 5:50 pm

@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! :D Natural selection anyone?
H8L6L5M4G3H5M7N8S7N9O1R8J1P5M7N9O4P2Q5R6T7U4M3N8X6S5T8W (If you want the secret, why not 'TRY' decrypting it? )
This Door's lock doesn't need a key, the Lock is the key to open the Lock and you don't know how to turn the key...
Link: My Blog :)
User avatar
ACE247
 
Posts: 695
Joined: Tue Mar 16, 2010 12:31 am
Location: Namibia

Re: Understanding Shaders

Postby kevinsbro » Sat Jan 14, 2012 5:55 pm

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?
kevinsbro
 
Posts: 48
Joined: Fri Nov 05, 2010 8:18 pm

Re: Understanding Shaders

Postby Granyte » Sat Jan 14, 2012 5:57 pm

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

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
Granyte
 
Posts: 515
Joined: Tue Jan 25, 2011 11:07 pm

Re: Understanding Shaders

Postby Mel » Sat Jan 14, 2012 6:27 pm

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.
http://santiagong.daportfolio.com/
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
User avatar
Mel
Competition winner
 
Posts: 1783
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Re: Understanding Shaders

Postby kevinsbro » Mon Jan 16, 2012 4:47 am

Well here's another thought. Does it cost memory or performance to pass a texture to the shader?
kevinsbro
 
Posts: 48
Joined: Fri Nov 05, 2010 8:18 pm

Re: Understanding Shaders

Postby Radikalizm » Mon Jan 16, 2012 10:21 am

kevinsbro wrote:Well here's another thought. Does it cost memory or performance to pass a texture to the shader?


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.

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
Radikalizm
 
Posts: 1215
Joined: Tue Jan 09, 2007 7:03 pm
Location: Leuven, Belgium

Re: Understanding Shaders

Postby kevinsbro » Mon Jan 16, 2012 4:35 pm

Thank you so much for all the advice!
kevinsbro
 
Posts: 48
Joined: Fri Nov 05, 2010 8:18 pm

Re: Understanding Shaders

Postby Mel » Tue Jan 17, 2012 1:44 am

Radikalizm wrote:
kevinsbro wrote:Well here's another thought. Does it cost memory or performance to pass a texture to the shader?


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.

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


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.

These general tips apply the same to DX and OpenGL, take a look.
http://msdn.microsoft.com/en-us/library ... 85%29.aspx
http://santiagong.daportfolio.com/
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
User avatar
Mel
Competition winner
 
Posts: 1783
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Re: Understanding Shaders

Postby Granyte » Tue Jan 17, 2012 2:04 am

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
Granyte
 
Posts: 515
Joined: Tue Jan 25, 2011 11:07 pm

Re: Understanding Shaders

Postby mongoose7 » Tue Jan 17, 2012 3:55 am

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.
mongoose7
 
Posts: 514
Joined: Wed Apr 06, 2011 12:13 pm

Re: Understanding Shaders

Postby REDDemon » Tue Jan 17, 2012 6:21 am

shouldn't mipmaps add 1,33 of the total size to texture size? so that 4MB becomes 5,33MB? :?
OpenGL is not hard. What you have to do is just explained in specifications. What is hard is dealing with poor OpenGL implementations.
User avatar
REDDemon
 
Posts: 831
Joined: Tue Aug 31, 2010 8:06 pm
Location: Genova (Italy)

Re: Understanding Shaders

Postby hybrid » Tue Jan 17, 2012 8:17 am

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
hybrid
Admin
 
Posts: 13943
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany

Re: Understanding Shaders

Postby mongoose7 » Tue Jan 17, 2012 11:41 am

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.
mongoose7
 
Posts: 514
Joined: Wed Apr 06, 2011 12:13 pm

Re: Understanding Shaders

Postby hybrid » Tue Jan 17, 2012 4:28 pm

Ah right, you only have a very few intermediate steps
hybrid
Admin
 
Posts: 13943
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany

Re: Understanding Shaders

Postby Mel » Tue Jan 17, 2012 6:43 pm

REDDemon wrote:shouldn't mipmaps add 1,33 of the total size to texture size? so that 4MB becomes 5,33MB? :?

I did a rough approximation.
http://santiagong.daportfolio.com/
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
User avatar
Mel
Competition winner
 
Posts: 1783
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

PreviousNext

Return to Advanced Help

Who is online

Users browsing this forum: No registered users and 1 guest