Stephan Picker

Members
  • Content count

    20
  • Joined

  • Last visited

Community Reputation

139 Neutral

About Stephan Picker

  • Rank
    Member
  1. I'm trying to query the size of a SSBO I declared in a shader. layout(shared) buffer SourceBuffer { float s[NUM_ELEMENTS]; }; glGetProgramResourcei(programHandle, variables, index, GL_ARRAY_STRIDE) returns 16 = 4*sizeof(float)     when setting NUM_ELEMENTS to 4096-> we have NUM_ELEMENTS * STRIDE = 4096 * 4 = 16384 elements = 64kb glGetProgramResourcei(programHandle, GL_SHADER_STORAGE_BLOCK, interfaceBlockIndex, GL_BUFFER_DATA_SIZE); With that setup glGetProgramResourcei returns the correct size. But when I get higher as the 64kb it returns -16 ?!?!?!   My card fully supports OpenGL 4.3.
  2. Oh interesting face: I just played around with my SSBO.   and changd: layout(shared) buffer Classification { float h[MAX_FACES]; }; to layout(std430) buffer Classification { float h[MAX_FACES]; }; now the stride is sizeof(float). But since my application is very performance critical (the algorithm will be running for hours) I still want to know what's up. std430 now gives me a "good" alignmen, but "shared" offers a implementation specific optimized layout. So my GPU (Radeon 6950) must have a reason to stride it the way it is?!?
  3. Thank you very much Ohforf sake. Very good post.   Now for the last open question: I read that GPU preferabley have 128bit registers. so this could explain the odd allignment. I also remember quite briefly, that if it was tightly packed, the ALU would have to mask out single 32bit packets and store them in a register.
  4. I'am having some questions about Image Image-LoadStore and SSBOs (and also UBO).   I will move solved Questions down to Facts.   Questions: * why is a float[]-array not tighly packed when declared in a SSBO. ??? There is always a stride of sizeof(vec4). * ... why does this make sense ??? * what are typical use-cased for the two ???   Facts (or educated-guesses): * SSBO and Textures both reside in global memory?                                       normally yes. * Acces to SSBOs is uncached?                                                                       only L2 cache. * Acces to textures via LoadStore is cached (texture-cache)?                          yes, uses texture-Cache. * The actual load and store via LoadStore is done by texturing-hardware?      yes, uses texture-memory-pipeline. * which of the two is more performant?                                                             texture-cache has better 2d-spacial-locality, but latency longer * where do UBOs reside in memory?                                                                uniform-buffers reside in the constant-cache! (only 1-float per clock) * can I also write to an Uniform-Buffer?                                                             no.
  5. I'm working on a formular to calculate the index for the frustum of a 2D-Point-Light. My Light-System is rendering the Scene into 4 1D-Textures: Right, Left, Top and Bottom.   Now, in the fragment shader I want to query the index for the frustum corresponding to the fragment position in light-space, so I know which depth texture I have to sample.   I got one that works, but it's very complicated.     Or should I just do a series of "if" statements. My concern with that is, that inside a warp, only the body of one if-statement can be entered, which leaves all fragments idling, if they have different frustum.
  6. 2D point light shadow - depth interpolation problem

    I fixed the problem.   The thing is that you can't do: gl_Position = vec4( vs.lightSpace.y / vs.lightSpace.x, 0.0f, depthToHom(vs.lightSpace.x), 1.0f); because the vs.lightSpace.y / vs.lightSpace.x is a perspective divide - and you can't interpolate already divided values.    The Fix: gl_Position = vec4( vs.lightSpace.y, ... ... ..., ... ... ..., vs.lightSpace.x); The divident and divisor of the perspective projection have to be interpolated independently in order to guarantee a perspective correct interpolation of depth values. also the "... ... ..." have to be modified, but that's not essential to the point I'm trying to make.   - This cost me a hole day to figure out- 
  7. 2D point light shadow - depth interpolation problem

    I still want to known, where my math is wrong. Every context in my rendering is linear. So why do I see a curve?! When I insert more points it gets better.   I dumped the content of my shadow-map to see whats wrong. (The two color-transitions represent the content of the shadowMap - you can see - they are not the same - even though they should be)  
  8. 2D point light shadow - depth interpolation problem

    What do you mean by "screenspace raytracing".   Do you mean: for every light L - and every angle Alpha - you start at the origin of L and trace the direction given by Alpha until you hit a blocker in your fbo?
  9. I'm writing  a shader for a 2d point light shadow mapper.   I render the depth-values of the right Frustum of the light into a texture which is 1024x1 pixels in size.   I project the vertices myself, so I dont use the w coordinate.   This is my projection into the shadow-map. "vs.lightSpace" means that all vertices are in the coordinate-system of the light. (0,0) is it's origin. gl_Position = vec4( vs.lightSpace.y / vs.lightSpace.x, 0.0f, depthToHom(vs.lightSpace.x), 1.0f); float depthToHom(float depth) { float near = 0.5f; float far = 10.0f; return depth * 2.0f / (far - near) + (-far - near) / (far - near); } As you can see the depth-values are not interpolated correctly. On long edges there is a round curve in the shadow. Is this because I don't divide correctly? The big white circle is supposed to be a point-light.     To sample the depth I use: float depth = texture(shadowMap, vec2((lightSpace.y / lightSpace.x + 1.0f) * 0.5f, 0.5f)).x; if(depthToNorm(lightSpace.x) > depth) { //... ... ... } float depthToNorm(float depth) { float near = 0.5f; float far = 10.0f; return depth * (1.0f / (far - near)) + (-near) / (far - near); }
  10. Uniform Buffer & shared layout -> Index still -1

    ok! Doesn't sound unreasonable.   But Is there still a mechanic/technique, that allows me to query layout information even though I don't use any variable at all ?
  11. Uniform Buffer & shared layout -> Index still -1

    ... I just want to get a valid index/location for all of them - even if they're not used. Because they're shared and not every shader needs all of them.
  12. Uniform Buffer & shared layout -> Index still -1

    no ?!? But it's "shared": So it must not be optimized out.   If I'm not understanding right - whats the right approach to get the layout even for variables which are not used?
  13. <h1>Problem</h1>   Hello. I'm trying to share a Uniform Buffer among different programs. The problem is, that I have to query the layout - which is shared - at one point. I tried all possibilities, but it always return -1.   The specification tells me, that with the shared layout, the driver is not allowed to optimize and has toactivate the variables.   What did I miss?   <h1>Code</h1>   #version 420 core   layout(shared) uniform Camera { mat4 camViewProj; mat4 sunViewProj; mat4 sunViewCoordProj; };   out mat4 outVar;   void main() { //outVar = camViewProj; }   I only get a valid index for "camViewProj" when I uncomment the section above.   To Query the indices, I used:   glGetProgramResourceIndex(); glGetUniformIndices();
  14. Binding a specific Texture Level/Mip-Map

    ... ok, but still - as long as I use "textureLod" all I get is black pixels ...
  15. Binding a specific Texture Level/Mip-Map

      Doesn't Work.   I also just read that you can only use "textureLod" in vertex buffers. Isn't that nonsense?