Jump to content
  • Advertisement

Stephan Picker

Member
  • Content Count

    20
  • Joined

  • Last visited

Everything posted by Stephan Picker

  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. 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.
  4. 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.
  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. 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); }
  8. 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)  
  9. 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?
  • 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!