Render bucket size control for OpenCL

[lukesleftleg]

First of all, let me say what an impressive piece of software Mandelbulber v2 is becoming, and thank you to everyone who's been working on it.

I've been taking a bit of a break, but it looks like I chose the right time to get back into some fractals. The limited OpenCL support in the latest alpha is already producing some extremely impressive results on my machine. (I've finally managed to get around to having a proper explore of Spudsville. Still got lost though  ).

Anyway, I'm happy to report that the OpenCL seems to be working perfectly well on my machine (Windows 10 64bit, GTX 780) as far as Mandelbulber goes, but I'm still running into a problem I had with the previous version (mentioned here). It seems that Windows itself has a time-out for GPU operations, and if part of a render takes too long, it crashes Mandelbulber with a message saying something like "Could not clear OpenCL queue". That's just from memory, I'll have to recreate the crash to get the exact text of the message which does need a very busy scene, or even just some small corner of a scene that's very busy.

In some other renderers, specifically ones that use render buckets rather than scanlines (like the OpenCL renderer), I've seen an option to change the size of the render bucket, usually just multiples of two - (16x16, 32x32, 64x64 etcetera). I'm wondering if something like that could help here. If I could render a scene in smaller buckets, it seems likely that Windows might time-out less often.

Would implementing a render bucket size control for OpenCL be a relatively trivial task, or would it be horribly complicated?

[mclarekin]

I will eave the bucket size issue to Buddhi

In the meantime, this could be a problem with the Windows time outs.

There is in one of Syntopia's blogs, some advice on editing the register to increase the timeout threshold,  which I have used successfully in the past for OpenCL.

I had a quick look but I can not find it, ,  but there is also similar advice at the windows site.

[lukesleftleg]

Hi mclarekin, and thanks for the reply.

You've successfully changed the Windows time-outs? I can't seem to find it now, but I'm sure I read a post in the Fragmentarium forum that said this was a bad idea for reasons I can't remember.

I did find this from Syntopia though:

The GPU is completely locked until a frame render completes in Fragmentarium. (Which is why Windows just kills the display driver if a GPU operation takes too long - it cannot show a dialog asking if you want to stop the operation).

Theoretically, the new WDDM 1.2 driver model in Windows 8 supports GPU Pre-emption (multitasking as we know it from desktop OS'es), but I don't know if the Nvidia and AMD drivers implement this yet - I don't think so.

The only way to keep the OS responsive is by rendering smaller tiles.

But if you say you've changed the registry without issue, then I can certainly look into this. Thanks for the advice.

I did try reducing the memory available to OpenCL, and that seemed the help in the old versions, but doesn't seem to make a difference here.

Also, I managed to recreate the crash. The exact text of the error is "Error: Cannot enqueue reading OpenCL output buffers". (If I then ask it to render again, it gives me that message followed by "Error: OpenCL command queue cannot be created!").

Anyway, sorry, I feel like I'm moaning when in fact I'm really impressed by what you guys have achieved here, not to mention grateful.

[mclarekin]

http://blog.hvidtfeldts.net/index.php/2011/12/fragmentarium-faq

is what i followed for the TDR registry thing.

But I am not sure if it will fix your problem, because with me the program was crashing, and windows would give me some sort of GPU error message

[lukesleftleg]

Aha! That looks like it's just what I need actually.

Thanks very much. I'll have a good read of that.  



Edit:

Hi mclarekin. That seems to have done it. Thanks very much for the link.
I've set both the TdrDelay and TdrDdiDelay keys to thirty seconds as the article advises, rebooted, and now the problem frames I had seem to be rendering just fine.

I also read something about how not using the GPU for displaying the Windows desktop doesn't cause the timeout to happen at all. Maybe I'll look into using my onboard video for the display when rendering overnight.

Anyway, thanks again for the advice. Much appreciated.

[zebastian]

btw i added an explanation to the handbook.
Here it is, see chapter "Trouble shooting OpenCL":
https://github.com/buddhi1980/mandelbulber_doc/releases/download/untagged-558def77623db40dbefd/handbook-compressed.pdf

This will be shipped with the next mandelbulber version...

Cheers

[lukesleftleg]

Ahh perfect. Thanks zebastian.

Oh and good call on adding "as decimal" to the values. That gave me pause when I set the registry keys.