Constructing the kernel for GaussianDEWithoutSsKernel causes indefinite hang on some systems

Issue #41 closed
David Haddad created an issue

After pulling down the Fractorium source code and doing some experiments, I was able to isolate the exact function that causes my openCL compile to hang.

Any codepath that causes me to build a kernel with GaussianDEWithoutSsKernel as the entrypoint causes an indefinite hangup at the kernel constructor. Execution reaches line 1077 in OpenCLWrapper.cpp, and progresses no further.

If I force EmberRender to use supersampling, the compile proceeds as it should. The problem is specifically with the “WithoutSs” variety of GaussianDE.

This still prevents me from using certain variants in Fractorium, because the preview defaults to a supersample of 1, thus inducing the bug.

I am on Windows 10, using an NVIDIA GTX 1660 with the latest drivers.

Comments (11)

  1. Matt Feemster repo owner

    Thanks for reporting this. Another user reported a similar problem in August of this year, but I couldn’t reproduce it, so the workaround we settled on was just using SS2 as you mentioned. But this is obviously not an ideal solution. Here was the post:

    https://bitbucket.org/mfeemster/fractorium/issues/36/problem-with-supersample-1-command-line

    Your post provides more clarity on what exactly is going on.

    I have attached two kernel dumps, which upon successful compilation, will be printed from emberrender if you pass the --dump_kernel command line option. It prints all three kernels used in rendering, and I’ve stripped them down to only the density filtering one.

    So it’s obvious that the OpenCL compiler is getting confused here when trying to compile that kernel. What’s so odd, is that it’s getting confused on the LESS complex kernel, the one for SS1. As you can see, the SS2 kernel has more code in it. For some reason, it appears to be processing that one fine.

    The only thing I can think of is that I am declaring some variable up above the conditional statements, when in reality, they could be declared inline. That might be confusing the compiler, but there’s no way to know.

    The problem is that it’s hard for me to really know, because it works fine on my system. But I would really like to get this issue resolved, so I can notify the other guy who posted the same thing.

    How would you like to go about testing? I can make a special build, put it in a zip file, and share it on a Google Drive link. Would you be up for that? We’d likely have to do several iterations.

    Last, as a final workaround: all density filtering code is skipped if you use a “DE max filter radius“ value of 0, which can be found under the Filter section of the Flame tab.

  2. Matt Feemster repo owner

    If you are able to build the code on your end, then you can mess with the kernel generation. Let me know how you want to proceed.

    BTW, I commend you for finding the exact place in the code where the problem was. Most people can’t do that so quickly, because it’s a large and complex project.

  3. David Haddad reporter

    Sorry for the delay; I missed that there were comments here.

    I don’t think I’ll do much good building on my end - the only way I got the thing to compile was by hacking it to bits and QT really doesn’t like my system.

    I can definitely run a custom build and provide feedback. One thing that would make this much smoother is if the dumpkernel options dumped the kernel before it tried to compile, not after.

  4. Matt Feemster repo owner

    Good point, perhaps that’s something I can look into. I can try doing a custom build for you. It’s definitely going to be tedious and cumbersome, especially if we do it via this bug tracking system.

    Are you on Discord? We have a room there called fractal chats. Once we’re both in there, we can PM each other, and then collaborate that way.

    Would you be willing to do that? If you’re not on Discord, I can do just regular Google chat.

    Let me know your preference. I’d really like to get this solved because as I mentioned above, another user reported this, but I didn’t understand the problem until now.

  5. Matt Feemster repo owner

    Well, it’s not specifically for fractorium, but general fractal art and tools. Many long time fractalists and software developers are in there, carried over from the decade+ on deviant art. Try this invite link:

    https://discord.gg/aqHsZ3Za

    I’m under the same name there, so tag me when you get there and we can chat.

  6. David Haddad reporter

    Sorry, I didn’t catch that link in time, and it’s now expired. My Discord handle is dahud#1435

  7. Matt Feemster repo owner

    We’ve resolved this by reducing nesting which had barrier calls in them. It’ll be included in the next release. Closing now.

  8. Log in to comment