   Some semi-advanced questions
  unch of questions whose place is just a step beyond the "basic" stuff I suppose.1) Depth/Alpha testIs it possible that, despite getting rid of the fixed function pipeline, depth and alpha test are still managed by a GlEnable/GlDisable switch? I am wondering because I am not finding any reference to depth or alpha test in GLSL.2) Multiple fragment and vertex shadersI've seen that an arbitrary number of shaders can be attached to a program, so I wonder what does that mean exactly. Let's say I need to render meshes in two different ways: normal and alpha blended. Right now I'd stick to having to programs: one with a vertex and fragment shader designed to render solid objects, one with another vertex and another fragment shader designed to render transparent objects. I will then switch between the two programs as needed. Is that right? In that case what's the use of N fragment and N vertex shaders in a single program?3) Opengl "costs" reference sheetTrying to avoid performance pitfalls that would be handy. Has anyone compiled something like that? I am wondering, for example, how expensive is to enable/disable certain things, if a 2dTextureArray with a single slice performs a lot worse than a classic 2dTextures, etc. etc.Thanks in advance for your help,  andrea   
  I believe I can at least answer two of your questions. :)1) Yes, depth and alpha testing are both regulated by using the enable / disable calls, regardless of whether you are using the fixed pipeline or shaders. Shaders also produce a depth and alpha value, which are tested as you would expect. Depth testing in GLSL with a single rendertarget is not possible, because you cannot access the color or depth values of your destination rendertarget.2) Think of using multiple vertex or fragment shaders for a single shader program as using multiple source files for a single regular program. Both are linked together and need a single main function to run. You can store other functions in seperate shaders, which can then be called from your main function for instance.For simple shader programs, using a single source is fine.   ;  Hi Ignifex, and thanks :)Quote:Original post by IgnifexI believe I can at least answer two of your questions. :)1) Yes, depth and alpha testing are both regulated by using the enable / disable calls, regardless of whether you are using the fixed pipeline or shaders. Shaders also produce a depth and alpha value, which are tested as you would expect. Depth testing in GLSL with a single rendertarget is not possible, because you cannot access the color or depth values of your destination rendertarget.Indeed, that's right. I didn't actually mean that as in "performing the calculations by myself in the fragment shader", I was thinking of something more in the likes of DirectX's "techniques". With those, every "sampler state" ends in the shader too as you can write stuff liketechnique10 Gui{ pass P0 {  SetRasterizerState(RASTER_TRANSPARENT);  SetBlendState(BLEND_SOLID,float4(0,0,0,0),0xFFFFFFFF);  SetDepthStencilState(DEPTH_NONE,0);}But I suppose there's no GLSL equivalent of that, right?Quote:2) Think of using multipl1e vertex or fragment shaders for a single shader program as using multiple source files for a single regular program. Both are linked together and need a single main function to run. You can store other functions in seperate shaders, which can then be called from your main function for instance.For simple shader programs, using a single source is fine.Aaah I get it now. So, in the end, all the files I load and compile as GL_VERTEX_SHADER_OBJECT are somehow "joined" together at link time like they were one single big file. Exactly like #include something. Thanks, that helps a lot!   ;Quote:Original post by resle3) Opengl "costs" reference sheetTrying to avoid performance pitfalls that would be handy. Has anyone compiled something like that? I am wondering, for example, how expensive is to enable/disable certain things, if a 2dTextureArray with a single slice performs a lot worse than a classic 2dTextures, etc. etc.If I recall correctly, NVIDIA had a presentation a few years ago that mentioned the relative costs of changing different part of the renderer state. Both they and ATI have optimization guides available online, which are regularly updated and are very useful.   ;Quote:Original post by resleBut I suppose there's no GLSL equivalent of that, right?No, shaders can't change states. What you're calling techniques is the DirectX Effect Framework, which is built on top of HLSL, but is just a framework who does some abstraction and manages passes/techniques/etc.;  Thanks everyone for your answers, I am really coming to love how OpenGL evolved since the fixed function pipeline era.   