Odd profiler results

Profiled some D3D code and found that most of the time was spent in D3DXSHProjectCubeMap which is for spherical harmonics.

After searching the entire solution I could not find a single call to this function yet 60% of runtime is devoted to this function.

Anyone else have similar issues when profiling Direct3D code? Googled and found one forum question just like this...but had no replies.

O_o

This is probably D3DX10SHProjectCubeMap or D3DX11SHProjectCubeMap.

I can't imagine why this is so costly for you.

Soma

Put a breakpoint on it, then do a backtrace to see where it came from?

That's just it - I can't breakpoint it. It is never called in any of the code. I'm wondering if some D3DX functions are calling it internally.

So how do you know it's being called then?

The debugger should allow you to set a breakpoint at any given address - not just source lines you can click on.

Does your profiler know the difference between public and private symbols?

Code:

void foo ( ) {
  // not a lot, I don't think I call this
}

static void bar ( ) {
  // expensive function being called
}

Some stupid profilers will mistakenly attach all the run-time of bar() to the foo() function.

So how do you know it's being called then?

It's in the profiler function coverage results. I think we ran VTune and another open-source profiler and both came back with nearly the same results. Not sure if the profiler knows the difference between public and private symbols. All I can gather is that perhaps D3DX is using this function internally or one of the libs we are using is. It is very odd though b/c we have no use for this function in the system.

It's certainly strange that you can't apparently put a breakpoint on it.

The profile results - do they give you file:line information, or is it more basic "address+offset" information?

From what I remember of the output it appeared to give function and address + offset only. I did not see any line number information. If it is internal to D3DX I will not be able to breakpoint it since I do not have the source. I might be able to breakpoint it in assembly code to find and then walk backwards to find out the caller but that doesn't sound like that much fun.

I must say it is the strangest profiler results I've seen so far. I would like to address the issue but I really can't until I figure out who or what is calling this function. Sorta hard to optimize code when you don't know why, who, or what is calling a function where most of the time is spent.

In WinDbg, setting breakpoints is a matter of
bp dllname!symbol+offset

Another thing to look at is a map file (which also shows symbol names and addresses).
With some luck, you might be able to figure out the extents of functions, and whether your profile results really are inside that function (or some other unnamed local).

Also see if Microsoft have an updated symbol pack for your version of D3DX.
That in itself might get better information from the profiler.

Very true. I didn't think of that.

Thanks for all the help. When I find out exactly what is going on I'll be sure and share it here so that others in the future won't have to do all this to figure it out. It isn't often when Google draws a blank so I'm beginning to think my situation is an isolated specific one due to the mix of libs being utilized.

Have you had any luck?

Soma

(I'm interested in this.)

Nope.

Well... good luck with it.

Soma

The profile also revealed a 3rd party library was performing poorly. Rather than search for the source of the D3DX call I figured my time was better spent optimizing my use of the library in question.