Luxmark OpenCL problem.

[DarkNido]

Luxmark OpenCL seems to not do anthing on my pc on the realbench 2.0b10_rc6
Other test work ok.
Luxmark OpenCL does open in background.
How long does Luxmark OpenCL run for to complete test.

PC specs.
asus P8Z68-V LE motherboard with latest bios update.
intel i5-2400 3.10GHz cpu
PNY PC3-10700 667MHz 4.00GB X2 ddr3 Ram.
OCZ agility3 80GB SSD
Nvidia GeForce GTX 550Ti
Windows 8.1 pro

I have all of the latest drivers installed.
I am using the multi gpu so I see both intel and nvidia in device manager.

[Ambidexter]

It does something on mine....it dies! 😄

I am overclocking at 4.6 + 2400 MHz memory. Prime 95 works for at least 30 mins. Realbench works OK, but sometime in the openCL test, Luxmark stops working.

Below are the details:
--------------------------------------------
Application error:
Faulting application name: LuxMark-x64.exe, version: 0.0.0.0, time stamp: 0x524968de
Faulting module name: MSVCR110.dll, version: 11.0.50727.1, time stamp: 0x5011a017
Exception code: 0xc0000409
Fault offset: 0x0000000000073904
Faulting process id: 0xfe0
Faulting application start time: 0x01cf128c5f2bc729
Faulting application path: d:\Users\Larry\Downloads\RealBench_v2.0b10_RC6_public_beta\RealBench\luxmark\LuxMark-x64.exe
Faulting module path: C:\WINDOWS\SYSTEM32\MSVCR110.dll
Report Id: dfd88742-7e7f-11e3-beb0-a0369f218d00
Faulting package full name:
Faulting package-relative application ID:
---------------------------------------------------------------------------------
Fault bucket -262032908, type 5
Event Name: BEX64
Response: Not available
Cab Id: 0

Problem signature:
P1: LuxMark-x64.exe
P2: 0.0.0.0
P3: 524968de
P4: MSVCR110.dll
P5: 11.0.50727.1
P6: 5011a017
P7: 0000000000073904
P8: c0000409
P9: 0000000000000007
P10:

Attached files:
C:\Users\Larry\AppData\Local\Temp\WER4700.tmp.WERInternalMetadata.xml
C:\Users\Larry\AppData\Local\Temp\WER52A9.tmp.appcompat.txt
memory.hdmp
C:\Users\Larry\AppData\Local\Temp\WER578E.tmp.WERDataCollectionFailure.txt

These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_LuxMark-x64.exe_619fbed9ad70406916fdb44afbc850665a2654_bb99fe57_0f6dd47a

Analysis symbol:
Rechecking for solution: 0
Report Id: dfd88742-7e7f-11e3-beb0-a0369f218d00
Report Status: 4104
Hashed bucket: 7ab43b0222daab9581b3e9eef03562f5
-----------------------
Report.wer file:

Version=1
EventType=BEX64
EventTime=130343309443123188
ReportType=2
Consent=1
UploadTime=130343309443503554
ReportIdentifier=dfd88743-7e7f-11e3-beb0-a0369f218d00
IntegratorReportIdentifier=dfd88742-7e7f-11e3-beb0-a0369f218d00
NsAppName=LuxMark-x64.exe
Response.BucketId=7ab43b0222daab9581b3e9eef03562f5
Response.BucketTable=5
Response.LegacyBucketId=-262032908
Response.type=4
Sig[0].Name=Application Name
Sig[0].Value=LuxMark-x64.exe
Sig[1].Name=Application Version
Sig[1].Value=0.0.0.0
Sig[2].Name=Application Timestamp
Sig[2].Value=524968de
Sig[3].Name=Fault Module Name
Sig[3].Value=MSVCR110.dll
Sig[4].Name=Fault Module Version
Sig[4].Value=11.0.50727.1
Sig[5].Name=Fault Module Timestamp
Sig[5].Value=5011a017
Sig[6].Name=Exception Offset
Sig[6].Value=0000000000073904
Sig[7].Name=Exception Code
Sig[7].Value=c0000409
Sig[8].Name=Exception Data
Sig[8].Value=0000000000000007
DynamicSig[1].Name=OS Version
DynamicSig[1].Value=6.3.9600.2.0.0.256.103
DynamicSig[2].Name=Locale ID
DynamicSig[2].Value=1033
DynamicSig[22].Name=Additional Information 1
DynamicSig[22].Value=ba52
DynamicSig[23].Name=Additional Information 2
DynamicSig[23].Value=ba5287db630ac798a90afa4bbe44b778
DynamicSig[24].Name=Additional Information 3
DynamicSig[24].Value=82ba
DynamicSig[25].Name=Additional Information 4
DynamicSig[25].Value=82ba4d20b937c2a559e09b4d8da6a5b1
UI[2]=d:\Users\Larry\Downloads\RealBench_v2.0b10_RC6_public_beta\RealBench\luxmark\LuxMark-x64.exe
UI[3]=LuxMark-x64.exe has stopped working
UI[4]=Windows can check online for a solution to the problem.
UI[5]=Check online for a solution and close the program
UI[6]=Check online for a solution later and close the program
UI[7]=Close the program
LoadedModule[0]=d:\Users\Larry\Downloads\RealBench_v2.0b10_RC6_public_beta\RealBench\luxmark\LuxMark-x64.exe
LoadedModule[1]=C:\WINDOWS\SYSTEM32\ntdll.dll
LoadedModule[2]=C:\WINDOWS\system32\KERNEL32.DLL
LoadedModule[3]=C:\WINDOWS\system32\KERNELBASE.dll
LoadedModule[4]=C:\WINDOWS\system32\apphelp.dll
LoadedModule[5]=D:\Users\Larry\Downloads\RealBench_v2.0b10_RC6_public_beta\RealBench\Qt5Widgets.dll
LoadedModule[6]=D:\Users\Larry\Downloads\RealBench_v2.0b10_RC6_public_beta\RealBench\Qt5Network.dll
LoadedModule[7]=C:\WINDOWS\SYSTEM32\OPENGL32.dll
LoadedModule[8]=d:\Users\Larry\Downloads\RealBench_v2.0b10_RC6_public_beta\RealBench\luxmark\FreeImage.dll
LoadedModule[9]=C:\WINDOWS\SYSTEM32\OpenCL.dll
LoadedModule[10]=D:\Users\Larry\Downloads\RealBench_v2.0b10_RC6_public_beta\RealBench\Qt5Gui.dll
LoadedModule[11]=D:\Users\Larry\Downloads\RealBench_v2.0b10_RC6_public_beta\RealBench\Qt5Core.dll
LoadedModule[12]=C:\WINDOWS\SYSTEM32\MSVCP110.dll
LoadedModule[13]=C:\WINDOWS\SYSTEM32\MSVCR110.dll
LoadedModule[14]=C:\WINDOWS\system32\GDI32.dll
LoadedModule[15]=C:\WINDOWS\system32\USER32.dll
LoadedModule[16]=C:\WINDOWS\system32\SHELL32.dll
LoadedModule[17]=C:\WINDOWS\system32\WS2_32.dll
LoadedModule[18]=C:\WINDOWS\SYSTEM32\DNSAPI.dll
LoadedModule[19]=C:\WINDOWS\system32\ADVAPI32.dll
LoadedModule[20]=C:\WINDOWS\system32\CRYPT32.dll
LoadedModule[21]=C:\WINDOWS\system32\msvcrt.dll
LoadedModule[22]=C:\WINDOWS\SYSTEM32\GLU32.dll
LoadedModule[23]=C:\WINDOWS\SYSTEM32\DDRAW.dll
LoadedModule[24]=D:\Users\Larry\Downloads\RealBench_v2.0b10_RC6_public_beta\RealBench\VCOMP110.DLL
LoadedModule[25]=C:\WINDOWS\system32\ole32.dll
LoadedModule[26]=D:\Users\Larry\Downloads\RealBench_v2.0b10_RC6_public_beta\RealBench\icuin51.dll
LoadedModule[27]=D:\Users\Larry\Downloads\RealBench_v2.0b10_RC6_public_beta\RealBench\icuuc51.dll
LoadedModule[28]=C:\WINDOWS\SYSTEM32\combase.dll
LoadedModule[29]=C:\WINDOWS\system32\SHLWAPI.dll
LoadedModule[30]=C:\WINDOWS\system32\NSI.dll
LoadedModule[31]=C:\WINDOWS\system32\RPCRT4.dll
LoadedModule[32]=C:\WINDOWS\SYSTEM32\sechost.dll
LoadedModule[33]=C:\WINDOWS\system32\MSASN1.dll
LoadedModule[34]=C:\WINDOWS\SYSTEM32\DCIMAN32.dll
LoadedModule[35]=D:\Users\Larry\Downloads\RealBench_v2.0b10_RC6_public_beta\RealBench\icudt51.dll
LoadedModule[36]=C:\WINDOWS\system32\IMM32.DLL
LoadedModule[37]=C:\WINDOWS\system32\MSCTF.dll
LoadedModule[38]=C:\WINDOWS\SYSTEM32\CRYPTBASE.DLL
LoadedModule[39]=C:\WINDOWS\SYSTEM32\bcryptPrimitives.dll
LoadedModule[40]=D:\Users\Larry\Downloads\RealBench_v2.0b10_RC6_public_beta\RealBench\luxmark\platforms\qwindows.dll
LoadedModule[41]=C:\WINDOWS\SYSTEM32\WINMM.dll
LoadedModule[42]=C:\WINDOWS\system32\OLEAUT32.dll
LoadedModule[43]=C:\WINDOWS\SYSTEM32\WINMMBASE.dll
LoadedModule[44]=C:\WINDOWS\SYSTEM32\cfgmgr32.dll
LoadedModule[45]=C:\WINDOWS\SYSTEM32\DEVOBJ.dll
LoadedModule[46]=C:\WINDOWS\SYSTEM32\kernel.appcore.dll
LoadedModule[47]=C:\WINDOWS\system32\uxtheme.dll
LoadedModule[48]=C:\WINDOWS\system32\dwmapi.dll
LoadedModule[49]=C:\WINDOWS\SYSTEM32\CRYPTSP.dll
LoadedModule[50]=C:\WINDOWS\system32\rsaenh.dll
LoadedModule[51]=C:\WINDOWS\SYSTEM32\bcrypt.dll
LoadedModule[52]=C:\WINDOWS\SYSTEM32\nvopencl.dll
LoadedModule[53]=C:\WINDOWS\system32\SETUPAPI.dll
LoadedModule[54]=C:\WINDOWS\system32\nvapi64.dll
LoadedModule[55]=C:\WINDOWS\SYSTEM32\VERSION.dll
LoadedModule[56]=C:\WINDOWS\system32\WINTRUST.dll
State[0].Key=Transport.DoneStage1
State[0].Value=1
FriendlyEventName=Stopped working
ConsentKey=BEX64
AppName=LuxMark-x64.exe
AppPath=d:\Users\Larry\Downloads\RealBench_v2.0b10_RC6_public_beta\RealBench\luxmark\LuxMark-x64.exe
NsPartner=windows
NsGroup=windows8
ApplicationIdentity=2B0A4162A0E2B7B19B6765E547710A8D
------------------

Please let me know if you can tell what the error was.


Thanks,

-Ambi

[Nodens]

@DarNido: I you are using Virtu try to disable it. If you are not then there's something wrong with your drivers. The test needs 130secs. It may also be instability related.

@Ambidexter: Driver issue (driver itself or bad isntallation of driver) or instability. If this happens during the stress test only it could also be bad PSU.

[Ambidexter]

Hi Nodens,

Thanks!

My issue is definitely an instability issue. What happens, the screen flash and the driver's recovery, looks exactly the same as when I run FurMark on my gtx770-dc2oc-2gd5 and GpuTweak too "aggressively", on the same machine. As I approach the point on GPUTweak/Furmark, the display shows some tearing, then the driver crash and recovery happens...there is no indication on the OpenGL window when it hits during RealBench. I don't get this with the benchmark mode, only the stress-test mode.

I'm exploring the boundaries of my OC'ing ability with this mobo/cpu/gpu, so I guess the OpenCL is having some borderline issue that, if the driver can't fix, it will crash. What I'd like to find out is what's the issue. I like that the whole OS doesn't BSOD, when it does, at other times, it's usually a 124 error. With this, when the GPU crashes, I can time it and then use AI Suite to tweak one voltage or setting, close and open RealBench, and try again. When I see which crashes less, or hopefully not at all, I'll be set. I occasionally put the current "best" setting in the UEFI and save it in one of the profiles.

I like these profiles in the UEFI, and the ones in AI Suite...it would be nice if I could write between them. I can write them both on the same USB drive, but they're different formats, I think.

So, in your experience, would a driver crash in the HAL with a WHEA_UNCORRECTABLE (0x124) error be caused by under- or over-volting? And would it be the CPU or the uncore (cache) that's got the problem? I can try auto settings for some of this, but my OC requirements work better manually, so far. It seems the 124 BSOD's are because of undervolting the CPU...so maybe the driver crashes are overvolting? BTW, on my FurMark tests, the driver crashes when I use GPUTweak to drive the memory to a higher speed that it likes.

I'll keep trying and let you all know, but for RealBench, I'd like it to notice that the driver's crashed, and stop the test. Sometimes I can't control the screen as the stress is still working and the "stop" button is hidden or minimized.

And DarNido, did you get any help with this?

Cheers,

-Ambi

P.S. For what it's worth, OpenGL crashes when I use 100 BCLK and 46 multi (4600 MHz), or a 125 strap and 36 multi (4500 MHz) I suspect I'll get it stable with the 125 strap after a while. But it's frustrating that AIDA64, prime95, etc. doesn't BSOD or crash me...just RealBench in stress mode! 😞

Nodens wrote:
@DarNido: I you are using Virtu try to disable it. If you are not then there's something wrong with your drivers. The test needs 130secs. It may also be instability related.

@Ambidexter: Driver issue (driver itself or bad isntallation of driver) or instability. If this happens during the stress test only it could also be bad PSU.

[Ambidexter]

I solved my crashing LuxMark issue!!! :cool: I can now RealBench the StressTest all day and everyhing without the driver crash. (I do still get a BSOD when trying 8G, but I'm still tweaking my settings, so I'll figure that out...it's just not the darn video driver crash!)

When we get a crash in LuxMark, and it's caused by an Nvidia driver crash where the video "recovers", this is because the driver for the card did not respond within the stock 2 second default time for the Nvidia drivers.

After reading the links below, I determined that TdrDelay was something I needed to add to my registry. Also, TdrLevel, when set to "0" will disable TDR on the card. So, if the card freezes, it will freeze hard. I didn't want that, I did want to avoid some crashes caused by hangs that may be < 10 seconds, but > 2 seconds. Feel free to tweak the setting by changing the "a" value to something less, if you want < 10 but greater than 2 seconds of delay. I rebooted after changing it, I don;t know if this is required, but just to make sure.

The following registry file can be merged in to accomplish this. Note: I left the line in for TdrLevel=0, remove this if you want the TDR to recover your card's graphics session.

I've not tried this yet, but I should be able to make this fail at will by overclocking my video card with GpuTweak...that's when I first saw this driver crash and recovery. BTW, I'm not clear if an update from Nvida/Asus for the graphics card will overwrite the TDR settings, so keep the .reg file around to merge back in if you need to.

Let me know if this work for anybody else.

Regards,

-Ambi

P.S. The interesting thing about this TDR is that when viewing where the tests used to get the driver crash, I see no delay...not a 8+ second delay and not even a 2 second delay. So it's possible it was queued data or something else, but it's not noticeable, AFAIK. Just like some benchmarks make the system laggy and some don't it seems the TdrDelay fix will allow us to overcome a lag in the video...at least for Nvidia. Have Fun!

================= Begin "Nvidia TDR Settings.reg" file ==========================
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers]
"TdrDelay"=dword:0000000a
"TdrLevel"=dword:00000000
================= End "Nvidia TDR Settings.reg" file ==========================

http://http.developer.nvidia.com/NsightVisualStudio/2.2/Documentation/UserGuide/HTML/Content/Timeout...

http://support.microsoft.com/kb/2665946

http://answers.microsoft.com/en-us/windows/forum/windows_8-hardware/display-driver-has-stopped-worki...

http://social.technet.microsoft.com/Forums/windows/en-US/77ca3fdd-c52c-4614-8817-d6d6c6c09225/that-o...

[Nodens]

System instability is system instability. The driver crashes because the system is unstable. You should not do what you did. You should not mess with TDR settings at all. Those settings are there for us developers only and they're meant for debugging. By increasing the value above 2 seconds you are effectively risking huge data corruption. Either get your overclocking to a stable state or reduce the clocks. Messing with TDR is bad. Very bad.

The TDR mechanism was first introduced in Vista. Before that any video driver crash would create a Stop Error (BSOD). The system tries to recover and if it can't recover it will throw a Stop Error in order to protect your data. It is calibrated in a very specific way. By changing the timeout value you're shooting yourself on the foot.

Also this happens with RB stress test and not the others because RB's ST is way heavier than those and utilizes all the available subsystems.

[Ambidexter]

Hi Nodens,

Thanks for the heads-up! I am certainly happy that the developers of the Nvidia drivers used TDR, as my Asus card will crash via TDR when I push FurMark too hard. As I said before, I prefer the driver crash type of error, vs. the BSOD reboot, rebould my RAID, etc. path! So, I'm glad it works in RB!

One thing FurMark does is notice when the driver crashes, and the bench that's in progress is terminated. That's not the case with RB, the stress still runs after the graphics card crashes. Perhaps it's hard for you to implement something like that, as there are two (or multiple) threads and not sufficient communication between them to tell a process dies? Maybe a way to disable the OpenCL part of the test, or a way to slow it down to the benchmark level would help for initial stability testing? Then we can incrementally see "how far away" we are from OK.

It is a nice thing to see a bench that was failing with the driver error, run after changing a voltage via AI Suite. So, I'll back out the TDR change, and see if there's some way to tell what to change when a driver crash happens.

When in GPUTweak, I can tell that incrementing memory speed or voltage, etc. is what the issue is and just dial it back...FurMark displays graphs of voltage, current, power, etc., I wish I could tell what parameter RB was having issues with. (I know, getting a stable rig - even at 3900 MHz and proceeding with one change at a time, until it starts to crash is the way to go). But most of my crashes are 124 BSODs which I take as "not enough voltage", and tweak the volts some more, and then see it continue. Do you think the crash is caused by a voltage or a timing issue when I get the driver recovery? It would be nice if RB could throw an error that states what happened other than the driver crash itself, perhaps from key fields of the windows message log or driver return code(s), or even sensor data (temps, fan RPM, voltages, current, card % of TDP, whatever you could measure or synthesize to help us when it crashes would be appreciated!

Thanks for all your work! I love this tool!

Cheers,

-Ambi

Nodens wrote:
System instability is system instability. The driver crashes because the system is unstable. You should not do what you did. You should not mess with TDR settings at all. Those settings are there for us developers only and they're meant for debugging. By increasing the value above 2 seconds you are effectively risking huge data corruption. Either get your overclocking to a stable state or reduce the clocks. Messing with TDR is bad. Very bad.

The TDR mechanism was first introduced in Vista. Before that any video driver crash would create a Stop Error (BSOD). The system tries to recover and if it can't recover it will throw a Stop Error in order to protect your data. It is calibrated in a very specific way. By changing the timeout value you're shooting yourself on the foot.

Also this happens with RB stress test and not the others because RB's ST is way heavier than those and utilizes all the available subsystems.

[Ambidexter]

Hi Nodens,

My M6F has a ROG_EXT and ROG Connect port. Can I use either of these to check for instability? When something is unstable, how does it manifest, other than rebooting your PC? Do you see voltage droop before a BSOD if it's low? Do you see extra heat or wattage being spent if a voltage is too high, etc.?

Thanks,

-Ambi

[Nodens]

You are comparing a driver crash with a system wide crash when you should not. The first happens when there's something wrong with the driver or the hardware and the second happens in order to protect your data. Without it you would reinstall Windows several times per month. A system wide crash (Stop Error AKA BSOD) can happen because of a variety of reasons. One of which is a driver crash from which the system can not recover. In video driver's case, one of the methods of detecting this is the TDR mechanism.

Furmark detects the driver crashing because it is actively and directly using the video card, through the GFX API and video driver. RB uses Luxmark which uses the video card and in a different way (OpenCL libraries and driver). You can not compare them as the design is entirely different. Inter-thread communication is irrelevant. I do not think you understand these things properly.
For initial stability testing you can use the plain benchmark mode. Disabling any component of the ST mode would render the ST useless as the point is to load everything at the same time.


The only way to troubleshoot overclocking is making one change at a time and test. There is no magic way of knowing anything. The Stop Errors just shows you specific stuff related to the OS and how it failed. It's true purpose is troubleshooting OS issues and not overclocking ones. How that translates into platform parameters can only be seen through experience and careful testing and again there's no real recipe to follow (Eg 124 can be caused by any condition that throws the CPU off and that includes a variety of voltages/parameters).

ROG_EXP port is for the OC Panel. And the ROG Connect port is for ROG connect. They are not for troubleshooting stability. Actually nothing is. There is no tool for what you are asking.

[Bags333]

I overclocked my CPU and thought this was the cause of Luxmark crashing, but it stops working for me during RealBench stress test at stock

MB: ASUS Z87 Sabertooth
CPU: Intel i7 4770k 3.5GHz
RAM: Corsair 32G 1600Mhz
GPU: EVGA Geforce GTX 780 Ti
OS: Windows 8.1 pro

My drivers have all been updated

Any help appreciated