@Brecht Van Lommel (brecht), mind having a look here? Thanks!
Mon, Feb 19
This shouldn't have been closed yet.
Fri, Feb 16
Nothing changed with the opengl32.dll.
However, I couldn't say if the Intel graphical drivers are up to date (it's a company computer and I'm not admin on it).
Ensure both your OS and drivers are fully up-to-date (and use official GPU drivers, not those provided by windows or tablet/laptop maker).
Launch Blender from the command line with -d option and attach as text file here any error printed out in the console (do not paste it directly in comment).
Try to run Blender through Software OpenGL, this will be much slower however, if everything works then it means that the bug is spefic for your GPU/Driver and you should report the bug to your GPU vendor instead.
Tue, Feb 13
Eh, guess this report is to be re-opened.
Mon, Feb 12
This is by design currently. Cycles viewport rendering always uses viewport settings. This ensure quick redraws using the same meshes that are drawn in other viewports.
Sun, Feb 11
Fri, Feb 9
Processor: i3-6100 @ 3.7GHz ; 64 bits
RAM: 8 Go
OS: Windows 7 Pro SP1
Graphics: Intel(R) HD Graphics 530 chipset
That's not what the Bump node is supposed to be used for, it generates a normal that you can plugin into BSDF nodes, using it as displacement doesn't really make sense. For displacement, you should link a Displacement or Vector Displacement node.
Thu, Feb 8
Can not reproduce the issue, on nether latest master build nor 2.79 release.
Wed, Feb 7
Well, even if we can't reproduce right now, there's always more things we can try and code we can inspect. But in this case it seems we are mostly out of ideas for now .. so if you want to move it go ahead.
@Brecht Van Lommel (brecht), it doesn't help having reports in main tracker which we can not even reproduce. Also if we can not reproduce issue, we can not fix it, not in reasonable amount of time at least. Someone from the community with a technical skills need to reproduce the issue and provide crucial information or even a patch...
I can't redo this issue anymore, and I never was able to redo it with a more recent build after 2.79. There's also been lots CUDA changes in the meantime, related to using host memory for rendering.
AMD GPU rendering on Mac is indeed quite poor currently, partially due to bugs in the OpenCL driver, partially due to none of the Cycles developers having this hardware or enough time to optimize for it. There's not much users can do in testing, it mainly requires a developer to spend significant time.
@Brecht Van Lommel (brecht), i can not reproduce the error on neither of my machines. If you can look into the issue, that'd be great (AFAIR, you managed to redo the issue). Otherwise, afraid this report should go to hardware related tracker.
Tue, Feb 6
We don't need the specific file you found the bug in, but any .blend that shows the problem. This can be created from scratch, or for example by removing all but one or two objects from the file you have.
Please attach a .blend file that demonstrates the issue.
Please attach a .blend file that demonstrates the issue.
I have this black tile issue with denonising on GPU also. Im running an iMac Pro with the Radeon Pro Vega 64 16 GB graphics card, for me I have to turn off all the direct denoising to get an image looking like the expected render
At the moment the bump mapping code only works with heights, computed by taking the dot product between the normal and the displacement vector. The math in svm_node_set_bump will likely need to change quite a lot to make this work.
Mon, Feb 5
Please always follow bug report guidelines and provide exact steps needed to reproduce the issue. If the issue can not be reproduced within few steps from factory startup, attach .blend file.
Looks like that's the issue. Alright, I'll make a report then. Thanks.
Here is a file for you:
Alright, but what is the full correct RNA path that I should use to make the "Driver source" directly control "ScaleX"?
if that's another bug make a new report, with all the steps and demo file needed to reproduce it.
It seems like it is another bug, Blender doesn't save the path I specified here using "Add driver from target"
Material owns it's node tree, and the only "standalone" node trees you will see will come from node groups. So for your case you need to read from material datablock, using it's node_tree in RNA path.
Sun, Feb 4
As we still are default c99, a patch is needed:
Sat, Feb 3
Looks good to me, still works on Linux.
Fix compiler warning in runtime compilation.
Fri, Feb 2
add missing comma
Thu, Feb 1
no GPU rendering for me then,
Wed, Jan 31
- Fix problem with spaces in cuda tookit path
- replaced call to cuewCompilerVersion with cuewNvrtcVersion since nvcc might not be in the path.
- added support for Cuda 9.1
After looking through now with proper time, seems indeed some High Sierra issue.
From the description, this must be a bug in the Apple OpenCL driver. We've seen this before where if it's given a complex OpenCL kernel, it can hang for a longe time and eventually crash or return an error.
More than a week passed without a reply.
So I'll open this again, yet I can't repro.
Factory startup is just that, it removes all settings to default, and removes GPU compute selection from settings.
Check if this happens with 2.79a-rc:
Blender 2.79a rc macOS
As it seems that it's not blender bug, marking this as resolved. Feel free to comment, I'll try to help.
Start with --factory-startup, then do some settings you usually have, and save it as new startup.blend
... can you give me an idea what to try then? I'm not a coding guru. (Unless chaos is worshipped, I that case I may stand a fair chance)
It can be also your startup .blend
Ah, it is not an add on problem,
That sounds like a good approach. I suspect that in general, transparent intersections can lead to incorrect path termination. Note how for example how an environment light with diffuse bounces = 0 will not provide direct illumination through transparency. Volume emission currently also provides direct light to surfaces inside the volume's bounds, but not to surfaces outside of the volume's bounds.
Tue, Jan 30
needs an update to support cuda91 (dll name has changed again)
Console gives this output though, (see attachement)
When switching to factory settings, enabling Cycles and then switch to GPU and start a render, it actually works!
If you start with --factory-startup, does the kernel compiling hang?
Here's the terminal output:
I would like to see the terminal console, it seems to hang when trying to build OpenCL kernels.
No, not really,
but here's a screenshot, so you can look for yourself, perhaps spot something I've missed...
Does --debug-gpu option give anything to the console before freeze?
The intended behavior is that when max_volume_bounce is 0, we gather direct lighting and emission from surfaces and volumes. The latter is also considered to be "direct lighting", so that a mesh light behaves the same as any other light. Using next event estimation or not should not make any difference in the converged render result, but it is different in this case due to an inconsistency with the handling of transparent surfaces.
I see what you mean.
Mon, Jan 29
This commit is affecting many regression tests, and investigating it more closely I don't think it's correct, so I'll revert it for now to keep the tests passing. After this change it's no longer possible to get just direct volume lighting, it will always do at least 1 indirect volume bounce as well.
Sun, Jan 28
We do not currently support rendering with the open source OpenCL driver, you need to install the closed source one. Last we tested, the driver was not yet complete or mature enough for software like Cycles, Luxrender, etc.
Sat, Jan 27
Looks good to me.