>>>But, when I use the Concurrency Visualizer integrated in Visual Studio 2012, it appears that my rendering thread sometimes stalls quite randomly in the frame for more than 10ms, inside the intel driver according to the sampled callstack, which looks like to wait an internal even>>>

Can you post the stalled thread call stack?

Quote:

iliyapolak wrote:

>>>But, when I use the Concurrency Visualizer integrated in Visual Studio 2012, it appears that my rendering thread sometimes stalls quite randomly in the frame for more than 10ms, inside the intel driver according to the sampled callstack, which looks like to wait an internal even>>>

Can you post the stalled thread call stack?

Another option to try is to run your DirectX app under windbg and check for processor hog.Sadly !runaway command is user mode command and in order to fully inspect and find the culprit you need to perform kernel mode debugging coupled with the user mode debugging.

Obviously your rendering thread entered so called synchronous waiting state and was swapped.The main problem is locate the culprit responsible
for the thread's stall.Sadly can not find any information regarding this driver and its functions 'dxgmms1.sys!VIDMM_GLOBAL'.
My bet is that this is user mode driver which is responsible for receiving commands from the DirectX runtime.
These 3 functions calls are crucial for understanding the cause for the extended wait:

dxgmms1.sys!VIDMM_GLOBAL::xWaitOnDMAReferences+0xa2
dxgmms1.sys!VIDMM_GLOBAL::BeginCPUAccess+0x7e3
dxgmms1.sys!VidMmBeginCPUAccess+0x28

While going through the WDK display driver documentation i was not able to find any relevant information regarding dxgmms.sys driver.
By looking at the call stack I think that the possible reason could be related to the DMA buffer(s) and if I'm not wrong for allocation of DMA buffers is responsible display miniport driver.Moreover miniport driver needs to lock DMA buffer pages so this can be an issue i.e waiting for the lock to be obtained/released.
It is very hard to exactly understand what those functions are doing without the putting a breakpoint on one of them and doing single step through the dissasembly.
My advice is to run GpuView.exe utility which will collect statistics about the GPU and CPU performance and maybe you will be able to pinpoint the source of your problem.
Another option is to run your app under windbg and issue !runaway 3 command for the tracing processor hog.
Another option is to do kernel mode debugging for the stalled process.

>>>wow64win.dll!ZwGdiDdDDILock+0xa>>>

Do you run 32-bit app on 64-bit Windows OS?

Hi djiz!

Do you have a checked build of dxgkrnl.sys?If you do you can enable extended logging feature which will be displayed on the debugger break in.
If you do not so you can still log those errors.
As I stated earlier in my previous post GpuView.exe is an essential tool to be used in the case of DMA buffer errors.

>>>Hi,
Thanks for your answers.
You're right, I'm running a 32 bit app on a 64-bit Windows 7. Could it be related to the stalls ?>>>

Hardly to say if this is the reason for the thread stalls.Wow64 is simply hooking ,intercepting and translating your 32-bit system calls.If you were able to run your app on 32-bit Win it could be great we could have been able to eliminate the or to remove the responsibility from the WoW64.dll

>>>How can I do that ?>>> For this so called checked build of Windows is needed it is not free and if you have somehow possibility to obtain at least checked dxgkrnl.sys it could be very helpful in your case.

P.S

 Checked build Windows is available for MSDN subscribers only.

>>>For your other suggest, I've tried a little GPUView one year ago but at that time I thought it was to much complex for my needs. Now with the current issue, this is probably more adapted. I'll give it a deeper try.>>>

I strongly advise you to use GPUView tool this program can gather information about the performance of GPU.More obscure alternative is to perform full blown kernel debugging.

@djiz

Do you have any updates regarding your stalled application?

Hi dijz!

Checked build Windows is not free in order to download it you must be MSDN subscriber and this will cost you a 700$.For efficient dxgkrnl.sys debugging you need checked build directX kernel driver which is te special version filled with debugger assertions and this functionality will make easier driver debugging by performing debugger break-in on trigerred assertion.

Can GPUView provide you with the DMA related call stack?Can you follow function which calls HAL dma functions.IIRC DMA buffers are managed by HAL.DLL routines.As I stated earlier in my post for DMA allocations is responsible miniport driver the one that is working with your video hardware.I do not know how exactly  Intel miniport driver is accessing DMA functionality.As I told you earlier there is an option to dig deep down those DMA related features this option is to perform kernel debugging on your stalled thread by using !dma instruction.You can also run driver verifier which will help you to test DMA functionality. I strongly advise to run driver verifier and test DMA.Please post the results.

 You can a lot of information about the driver verifier in this link :http://support.microsoft.com/kb/244617

Did you test you display driver with driver verifier?

@dijz

Do you have any updates?

Quote:

djiz wrote:

Hi,

Sorry. I was very busy with other things these days, but when I have more time to spend on this, I'll post updates here.
Thanks again. 

Ok I will be waiting for any updates.

Btw Are you DirectX developer?

Hi

Any updates on the status of your problem?

>>>Unfortunately, still no updates on this because of other high priority tasks. I'm sure you know what I mean>>>

Yes I understand this pretty well:)

>>>I'm quite frustrated when working on PC with a lot of various "opaque" arhitectures and unknown driver-side or os-side behavior ;)>>>

You mean "Windows".Sadly Micrososft decided that for efficient GDI and DirectX debugging there is need to install checked build release which is not free of course.Moreover many features are undocumented.

I do not know the programming model of consoles.Do you work with some kind of API (could that be OpenGL)?

>>>I've already heard that Linux offers much better control, but I've never experienced it myself.>>> This the case with Intel and Ati graphics hardware as I heard Nvidia is reluctant to reveal it hardware architecture for the open source community.I remember that I was excited when AMD-ATI revealed to the general public R600 registers specification.If you are interested in getting closer to the GPU hardware I advise you to follow a reversing of nvidia drivers done by the developers from the Nouveau project.

Quote:

djiz wrote:

Quote:

iliyapolak wrote:If you are interested in getting closer to the GPU hardware I advise you to follow a reversing of nvidia drivers done by the developers from the Nouveau project.

Do you have any link to provide to me plz ?

Yes of course:)I'm posting link without the http or www(because of anti-spam filter )

 nouveau.freedesktop.org