Jump to content
  • Advertisement

Stephan Picker

Member
  • 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. Stephan Picker

    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. Stephan Picker

    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. Stephan Picker

    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. Stephan Picker

    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. Stephan Picker

    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. Stephan Picker

    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. Stephan Picker

    Binding a specific Texture Level/Mip-Map

    ... ok, but still - as long as I use "textureLod" all I get is black pixels ...
  15. Stephan Picker

    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?
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!