Software Archive
Read-only legacy content
17061 Discussions

Amplifier usage

bishgada
Beginner
1,054 Views
Hi,
I just started to work with Parallel Studio. I got reports from the Amplifier. Part of them are attached.

As seen in the reports about 25s from a total of 93s are spend in the DrvCopyContext which is a driver function and 8s of that in the KiFastSystemCallRet and 7s in the WaitForSingleObject which are OS functions.

Besides that most of the time is spend in functions from other libraries I use in my application (OpenSceneGraph and image processing).
Only about 8% of the time is spent in my own function.

What is the best way to approach such a situation? I don't know how to avoid (by using other functions) the calls to DrvCopyContext. I might be able to bypass the calls to readImagePixels (~15% of the execution time) by using PBO and take advantage of the DMA, ut besides that I see no low hanging fruits.

Is it possible to Parallelize such code which is not invoked by my own functions?

Where can I find tricks to bypass these calls?

Otherwise I don't see how to gain more then few percentage of speed gain, which means the tool doesn't help much in this case.

Thanks,
Guy Lifchitz.
0 Kudos
6 Replies
Vladimir_T_Intel
Moderator
1,054 Views
Quoting - bishgada
As seen in the reports about 25s from a total of 93s are spend in the DrvCopyContext which is a driver function and 8s of that in the KiFastSystemCallRet and 7s in the WaitForSingleObject which are OS functions.

To be more correct the functionDrvCopyContext does not consume CPU time itself, but it calls the other functions which end up in the system calls toKiFastSystemCallRet, etc.

Quoting -bishgada

Is it possible to Parallelize such code which is not invoked by my own functions?

You might want to consider theDrvCopyContext function or the function one level above (main) to establish parallelism if the data structure would allow it.

Quoting -bishgada
Where can I find tricks to bypass these calls?

Otherwise I don't see how to gain more then few percentage of speed gain, which means the tool doesn't help much in this case.


This hard to give any advise as you know the logic of your application and the tool is just a handle to unveil the internalbehaviorof your application.
0 Kudos
bishgada
Beginner
1,054 Views
You might want to consider the DrvCopyContext function or the function one level above (main) to establish parallelism if the data structure would allow it.

How? DrvCopyContext is not mine to change. It's code that runs in the driver nvogl
I have access only to the code in ThreadProc which doesn't trigger the specific 6s DrvCopyContext in the example.

0 Kudos
Vladimir_T_Intel
Moderator
1,054 Views
Quoting - bishgada
How? DrvCopyContext is not mine to change. It's code that runs in the driver nvogl
I have access only to the code in ThreadProc which doesn't trigger the specific 6s DrvCopyContext in the example.


Oh, I see now. So, if you do not control the calls to driver, why you think it can be parallelized/optimized anyhow?
0 Kudos
bishgada
Beginner
1,054 Views

Oh, I see now. So, if you do not control the calls to driver, why you think it can be parallelized/optimized anyhow?

I didn't think it is possible or impossible. I don't know and hoped someone knows if there is a way to do it (like telling the sysem I'm going to use this driver in that process and wants you to use a different thread for it's calls) or maybe someone who is familiar with NVidia driver can tell something like "Sure, the openGL call a,b,c and d cause the calls to DrvCopyContexts, but if you use instead function k,l,m and n you can reduce these calls to a minimum and by pass the unecessary overhead" or that someone who is familiar with the subject will say something like "Dude, don't bother struggling with this issue, EVERYBODY (besides you of course) knows that this overhead can't be solved".

So here are the reasons I started this discussion and I still hope to get usefull information.

Thanks for trying to help anyway :)
Guy.
0 Kudos
Vladimir_T_Intel
Moderator
1,054 Views
So, why not asking this question on theDeveloping Software for Visual Computing forum? ;)
0 Kudos
bishgada
Beginner
1,054 Views
So, why not asking this question on theDeveloping Software for Visual Computing forum? ;)

Goodquestion :)

When post the message I wasn't aware of it's existance. I'll post the question there now.

thanks.
0 Kudos
Reply