[2.1+] RenderDoc HLSL debugging with "Fast Shader Build Hack"

Discussion area about developing with Ogre-Next (2.1, 2.2 and beyond)


Post Reply
rujialiu
Goblin
Posts: 296
Joined: Mon May 09, 2016 8:21 am
x 35

[2.1+] RenderDoc HLSL debugging with "Fast Shader Build Hack"

Post by rujialiu »

Dear all,

Today I found that RenderDoc 1.1 added HLSL level debugging: https://github.com/baldurk/renderdoc/releases/v1.1

So I gave it a try. However, when debugging the fragment shader, I noticed that the debugger gave very different result with or without "Fast Shader Build Hack". Actually with the hack, most lighting codes are skipped due to lightMask is mostly zero.

With the hack, worldMaterialIdx is defined as:

Code: Select all

uint4 worldMaterialIdx[2];
and the light mask is retried this way:

Code: Select all

@piece( DeclareObjLightMask )uint objLightMask = worldMaterialIdx[inPs.drawId].z;@end
However, all objLightMask starting from drawId=2, are all zeros. It looks like RenderDoc's debugging is based on its own bytecode intepreter, which detects out-of-bound errros and gives 0 when isPs.drawId >= 2?

Anyway, this is one more reason why Fast Shader Build Hack may be disabled :)
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5299
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1280
Contact:

Re: [2.1+] RenderDoc HLSL debugging with "Fast Shader Build Hack"

Post by dark_sylinc »

Yeah, the main reason "Fast Shader Build Hack" is there is for better shader debugging. The second reason is "just in case" for some reason in the future a vendor decides to break the hack (btw it wouldn't break just us: it would also break lots of major titles).

I've opened a ticket at RenderDoc to request the debugger matches what the GPU is doing.
rujialiu
Goblin
Posts: 296
Joined: Mon May 09, 2016 8:21 am
x 35

Re: [2.1+] RenderDoc HLSL debugging with "Fast Shader Build Hack"

Post by rujialiu »

dark_sylinc wrote: Wed Aug 22, 2018 4:50 pm Yeah, the main reason "Fast Shader Build Hack" is there is for better shader debugging. The second reason is "just in case" for some reason in the future a vendor decides to break the hack (btw it wouldn't break just us: it would also break lots of major titles).

I've opened a ticket at RenderDoc to request the debugger matches what the GPU is doing.
baldurk already closed this issue 4 minutes ago because he thought it's a "undefined-behaviour-for-undefined-behaviour compatibility"... anyway, we can add this info in Ogre 2.1 FAQ and source code.
Post Reply