Regarding octane closing with pathtracing & high resolutions

[radiance]

PROBLEM: Octane render works with Directlighting, but crashes when i switch to Pathtracing.

Checklist:

1. Wrong driver version installed.

Make sure you are running the exact same driver we recommend in the accompanying readme.txt, which comes in the release.
If you are using different drivers, we cannot guarantee stability, nor provide support.

2. for beta1 and lower, If you have a Geforce 8000 Series, or a low-end 9000 series like a 9400, use the octane8000.exe
If you have a Quadro Series card, check on what technology it's based. It can be based on a 8000 chipset too. (use google)
beta2 and up don't have this split system anymore, just one the single octane executable for both cards.

3. If you enable path tracing and you render to a high resolution, a render pass can take long,
sometimes up to a few seconds, because path tracing is more complicated to compute than directlighting.

This is the time the operating system cannot use the GPU, and some operating systems will automatically close the application that takes the GPU for longer than a few seconds.\
This depends on the operating system type AND version.

There are ways to increase this timeout, but we do not recommend them as they involve modifying the registry settings.
If you still want to try, you do so at your own risk.

Turning off 'filter' in the path tracing options (which is enabled by default, and does'nt do anything with the octane8000),
can help as it speeds up the rendering pass.

If you still can't get it to work, you either buy a 2nd GPU, as a 2nd GPU can render passes without being interrupted by the OS,
or you wait until we have released beta3, which will solve this issue.

People on slow GPUs will often have this problem, with pathtracing on high resolutions.


Yours,
Radiance

[paq]

Hello there,

I've find some info here :

http://www.microsoft.com/whdc/device/di ... meout.mspx

Registry Keys
The following registry keys are documented for testing purposes only. These registry keys should not be manipulated by any applications outside targeted testing or debugging.

The TDR-related registry keys are located under HKLM\System\CurrentControlSet\Control\GraphicsDrivers.

• TdrLevel: REG_DWORD. The initial level of recovery. The possible values are:

• TdrLevelOff (0). – Detection disabled.

• TdrLevelBugcheck (1) – Bug check on detected timeout, for example, no recovery.

• TdrLevelRecoverVGA (2) – Recover to VGA (not implemented).

• TdrLevelRecover(3) – Recover on timeout. This is the default value.


• TdrDelay: REG_DWORD. The number of seconds that the GPU is allowed to delay the preempt request from the scheduler. This is effectively the timeout threshold. The default value is 2.

• TdrDdiDelay: REG_DWORD. The number of seconds that the operating system allows threads to leave the driver. After a specified time, the operating system bug checks the system with the code VIDEO_TDR_FAILURE (0x116). The default value is 5.

• TdrTestMode: REG_DWORD: Internal test usage.

• TdrDebugMode: REG_DWORD: The debugging-related behavior of the TDR process.

• TDR_DEBUG_MODE_OFF (0) breaks to kernel debugger before the recovery to allow investigation of the timeout.

• TDR_DEBUG_MODE_IGNORE_TIMEOUT (1) ignores any timeout.

• TDR_DEBUG_MODE_RECOVER_NO_PROMPT (2) recovers without break into the debugger. This is the default value.

• TDR_DEBUG_MODE_RECOVER_UNCONDITIONAL (3) recovers even if some recovery conditions are not met (for example, recovers on consecutive timeouts).


• TdrLimitTime: REG_DWORD (Windows Vista SP1 and later versions only): The default time within which a "TdrLimitCount" number of TDRs are allowed without crashing the system.

• TdrLimitCount: REG_DWORD (Windows Vista SP1 and later versions only): The default number of TDRs (0x117) that are allowed in "TdrLimitTime" without crashing the system.

This is currently for Vista, but it also work (so far) in Seven
Actually tested on Windows 7 64

I've add a key in :

HKEY_LOCAL_MACHINE / SYSTEM / CurrentControlSet / Control / GraphicsDrivers

Rightclick Add / New / DWORD

Name : TdrLevel
Value : 0

Reboot

I can now render my test scene using pathtracing at 8 with AA.

I didn't made any other test for the moment, I'm not exaclty sure of what I'm doing ... at you own risk

[face]

HKEY_LOCAL_MACHINE / SYSTEM / CurrentControlSet / GraphicsDrivers

It should be in HKEY_LOCAL_MACHINE / SYSTEM / CurrentControlSet / Control /GraphicsDrivers

[paq]

Indeed face, sorry

[Proupin]

I have a GT 220 with 1 GB of Video Memory, on a scene I'm working I can go as far as 3072 pixels wide, while 4096 pixels wide seems to be too much... blue screen, total freeze or restart. I have tried to downgrade the driver to yours recommended, but when I tried to install it doesn't find my card compatible with the driver!!

What do you recommend?

[Sam]

Currently rendering at 3840 by 2160 pixels without filtering
Will downsample to 1920 by 1080 pixels

I added to the registry these values

TdrDdiDelay = 600
TdrDelay = 600
TdrLevel = 3

And Octane doesn't crash
(GTX260 at 892mb)

[Proupin]

Sam is this tweak safe, and does it work on XP?

I have a spare card too, that would fix the problem right? kinda sucks since my other card is somehow low-end...

EDIT: screw the drivers, as I have read here: http://www.refractivesoftware.com/forum ... 8033#p8033 from radiance beta2 will be built based on newer drivers wohoo!

[Proupin]

I'll definetely try the second card... even in beta2 it freezes... I'm trying to render an interior, with sun coming in, now I start to want MLT and portals because it's slooow ATM

[radiance]

it's not really needed on window XP as the default timeout is much higher.

Radiance

[Proupin]

I guess the timeout is not long enough because I find Octane shutting down... I will definetely try the second card thing, after all a GT220 is not that much of a card Cuda-wise