Jump to content

  • Log In with Google      Sign In   
  • Create Account


derKai

Member Since 04 Sep 2011
Offline Last Active Jul 26 2014 02:08 AM

Topics I've Started

Interesting Shading Linkage Behavior

07 February 2014 - 07:31 AM

Hi,
I encountered an issue I can’t really understand so I’ll try to explain it here to get a reasonable explanation of what’s happing. I modified the tiled deferred rendering code by Andrew Lauritzen (http://software.intel.com/en-us/articles/deferred-rendering-for-current-and-future-rendering-pipelines) to have shadows maps for each light. To be able to turn on and off shadows I’m using shader classes that look this:

interface iBaseVPLShadow
{
    bool IsEnabled();
    float GetVisibility(Texture2DArray shadowBuffer, float3 receiverWorldPos, float4x4 lightViewProjection, uint lightIndex);
};

The lighting is done in a compute shader. Basically like this:

#define TILE_DIM 8
[numthreads(TILE_DIM, TILE_DIM, 1)]
void main( … )
{         
    // Read GBuffer at current Texel
    // Calculate Tile Frustum        
    GroupMemoryBarrierWithGroupSync();           

    for all lights         
    {                  
        // each thread of the block culls one light                 
        // if the light intersects the tile frustum add it to the tiles light list         
    }
    GroupMemoryBarrierWithGroupSync();

    float3 luminance = float3(0,0,0);          
    for all lights in the tiles light list         
    {                 
        // shadow test                 
        float visibility = 1.0; 

        if (SlotVPLShadow.IsEnabled())         
            visibility = SlotVPLShadow.GetVisibility(VPLShadowBuffer, worldPosition, VPLViewProjectionData[tileLightIndex], tileLightIndex);   

        // light amount of the light arriving at the surface
        float3 irradiance = visibility * SlotVPL.GetIrradiance( … )        

        // light amount reflected by the surface (visible to the observer)  
        luminance += irradiance * SlotDiffuseMaterial.BRDF( … )
    }         
    // write luminance to output target
}

As stated by that pseudo code I’m using multiple interface. One class to describe the light source, one for the material brdf, and one for the shadows.  I implemented the iBaseVPLShadow interface to do a common shadow mapping with a Load in the shadow buffer and a comparison in light space depth. And I also implemented the interface for “no shadows” in which case the GetVisibility(…) method simply returns 1.0.

 

Now to the interesting part.

 

You may ask yourself why there is the IsEnabled() method. Actually I really don’t know^^ But if it is not there the execution time for the “no shadow” class is HIGHER than the “shadow mapping” class by factor 1.5. And there are shadow artifacts if don’t unroll the last loop in the latter case.

 

I think both problems might be related to the loop because it’s not clear how often to loop at compile time and number of lights easily goes beyond 100. But nevertheless it totally confuses my understanding on how shader classes work because everything is totally fine (and fast) with the IsEnabled() check to prevent the GetVisibility() call if the shadows are disabled.

 

Sorry for this vague description but I'm not able provide a mini sample because it's in a bigger system with lots of dependencies.


Using NVIDIA Nsight with SharpDX

13 December 2013 - 02:52 AM

Sorry to bother you with a lot SharpDX questions but since their forum is closed this seems to be the place to find the people ;)

 

Is anybody using Nsight with SharpDX? I'm not able to get it running. .even for SDK samples.

I read that managed code is not officially supported, but SharpDX is just a wrapper. The GPU calls are quite the same.

 

So please let me know if you've made other experience ;)

 

Thanks

- Kai


Dynamic Shader Linkage for Windows Store Apps (non-toolkit)

02 December 2013 - 10:27 AM

Hi,

I'm working with sharp dx (without the toolkit) and I'm trying to get dynamic shader linkage working. There is no real sample for dynamic shader linkage but looking into the dx sdk samples helps ;). as you can see there you need shader reflection and this is a part of the d3d compiler. While building for windows desktop everything works fine (at least if the native dlls are present d3dcompiler_4x.dll).

 

When building for windows store apps the application crashes as soon as i create the a shader reflection object.

The message says: d3dcompiler_46.dll is missing.

My solution to that: add the dll to the application content.. works fine, too.. but is dirty because i have to add this dll to each application

 

so i started a thread in the developer forum:

http://social.msdn.microsoft.com/Forums/windowsapps/en-US/b2e6e1c4-f1aa-4b6f-bf56-e2096cb97e73/load-a-dll-that-is-contained-in-the-content?forum=winappswithcsharp#a75c40a8-3f63-4698-a607-476000720204

 

and one guy there got furious ;) he says my solution is not legal ..  now there is no response so i decided to post this here again and ask for a better solution ;)

 

maybe there is a better way to get shader linkage working with sharp dx..

 

thanks

- Kai


Frustum Box Intersection (again i know)

04 November 2013 - 09:42 AM

hi,

im currently working on frustum culling and looked for frustum-box intersection tests.

i found a tutorial appearing all the time: http://www.lighthouse3d.com/tutorials/view-frustum-culling/geometric-approach-testing-boxes-ii/

even here in the forum: http://www.gamedev.net/topic/512123-fast--and-correct-frustum---aabb-intersection/

 

during debugging some objects that should be culled were rendered so i looked deeper into it..

i made a picture to visiualize my problem..

 

Attached File  FrustumBoxTest.png   272.8KB   15 downloads

 

is it possible that the algorithm misses that case?

what is the common solution to address this? I'm fine with AABBs ;)

 

thanks

- Kai


Shader Branching Costs for "constant" Conditions

28 October 2013 - 06:45 AM

Hey,

im wondering if there is a specified behavior for branches in shader code if the condition is not really dynamic.

While searching the forum i found some hints that dynamic branching is not possible if some functions like Sample(...) are used. What if the condition is a value defined in the constant buffer? In this case all threads are following the same path and evaluating both paths is theoretically not requiered. Is this depending on the compiler and driver or are there any specified  and documented rules?

 

with shader i mean sharder in general rendering pipeline and compute shader or cuda.

 

Thanks

- Kai


PARTNERS