I committed part of the kernel changes now, mainly those that potentially affect CPU/CUDA/OpenCL. This will cause some merge conflicts, I can rebase this patch if needed.

In D5363#125233, @Stefan Werner (swerner) wrote:

Just thinking aloud, this might be an opportunity for a small refactor of cycles: currently, Cycles builds the BVH before it uploads geometry vertices to the device. Most ray tracing APIs (DXR, OptiX, Embree) work the other way round. Before we introduce an OptiX specific workaround, should we change Cycles to do vertices first, BVH second? That would also help the Embree backend and potentially a future DXR/Vulkan backend when we see more vendors deliver ray tracing hardware.

I normally try to refrain polluting diff reviews with "works for me!" but I think this patch fixes/compensates for what I see as a rendering deficiency in Cycles when it comes to motion blur.

Shadow Catcher Improvements: https://devtalk.blender.org/t/lets-finally-fix-the-shadowcatcher/691

Fixed some missing changes to "decode_node_uchar4" calls after rebase

Rebase against master and fix merge conflicts

Can you specify exactly which 2.79 build rendered fast with small tiles?

hello all,

I posted a workaround in [[ URL | https://developer.blender.org/T69014 ]]
Basically if you parent everything to the rig that you then proxy, moving the rig object should be sufficient to keep everything in sync (and not moving the instance origin)

I have removed the camera focal length from the task description, as that is already covered by T54050.
Now this task has only a single topic: importing data required for computing motion blur (probably vertex velocities is enough).

If it is related to Blender, then it is definitely a separate bug. Closing this one.

Updating my GPU driver resolved the issue for me. I last updated them about a month ago, but I downloaded the studio ready Nvidia drivers this time. The issue is also absent from the latest experimental build. Instead the Windows toolbar flashes around the point that the bug usually appeared, but whatever it is that's causing it seems to be handled appropriately now.

Changing the classification from 'Bug' to 'To Do', as this is a known limitation.

You increase the subversion in BKE_blender_version.h, and then use that new value in MAIN_VERSION_ATLEAST instead of 0

I cannot reproduce the issue here. Not sure if this is related; Please check if the same error happens in the newest nightly build and if you can update your GPU driver.

Thank you! That was fast!

Bigger tile sizes use more memory, especially when using denoising and render passes. If it runs out of memory because of that, it's not considered a bug.

Please try the latest daily 2.81 build, this may have been fixed by rB8f1a55831c89: Cycles: Fix wrong number of threads on multi-socket machines.

This looks like a duplicate of T56534

@Brecht Van Lommel (brecht) I have some questions. I'm working on the defaults improvements as suggested by @Carlo Andreacchio (candreacchio) using versioning_cycles.c but I'm not sure what to set MAIN_VERSION_ATLEAST() to.

All conflicts should be fixed and this patch has been made ready for merge to 2.81.

Cleaned up some unnecessary changes

@Michael March (cowmix): Yes, drivers >= 435.80 will work.

IMO internal GPU problem as memory or maybe too data to elaborate or so, however this is not a forum or chat, this is a Bug Tracker.
To make some chat Blender related ,you can use https://blender.chat/home #support or #today channel for technical discussions you can go in https://devtalk.blender.org/

oh, didnt realise that, my bad, thank you for your help. yet I would still like to know what causes the error... is it memory issue than? just curious...

your link is 2 year old and is related to Cycles to Rhino, Cycles had have a lot of improvement untill today, best tile size for Cycles in Blender depend on many parameter, for my porpuse best render tile size is 64 and my Workstation never had crash related to this render tile size

because I found this: https://discourse.mcneel.com/t/cycles-finding-the-optimal-tile-size/42276

Let's use that one instead.

Some existing related tasks: T53901

@Kévin Dietrich (kevindietrich) I suspected as much. Thanks for confirming ;-)

The instructions reference the pre-release drivers.

@Sybren A. Stüvel (sybren), sorry for the late response but I am not actively working on anything Blender related at the moment.

Missed one function name in last changes

Variable renaming for better readability

Rename and tidy up with comments from @Omar Ahmad (OmarSquircleArt)

Change XYZ sockets to a single vector socket

As EEVEE doesnt support object motion blur, a vector pass would also be a great addition to EEVEE if possible. Would save having to render each frame twice (once in eevee and once in cycles for the vector pass).

Fixed modified branched connect to light functions

Did a simple test to see if branched path tracing is affected by this, and in fact it is, as can be seen in these images. Note that this test was CPU only, so this is a regression and not limited to the new device backend. The branched functions will need to be corrected, I haven't looked too deeply at it yet, but it looks like some lines from the original are missing from the new versions of these functions. I'll do a more thorough look thru and testing later.

Cleanup and address comments from @Omar Ahmad (OmarSquircleArt) - thanks

Just thinking aloud, this might be an opportunity for a small refactor of cycles: currently, Cycles builds the BVH before it uploads geometry vertices to the device. Most ray tracing APIs (DXR, OptiX, Embree) work the other way round. Before we introduce an OptiX specific workaround, should we change Cycles to do vertices first, BVH second? That would also help the Embree backend and potentially a future DXR/Vulkan backend when we see more vendors deliver ray tracing hardware.

@Omar Ahmad (OmarSquircleArt) I've kept the eul_to_mat4 the same as in maths_rotation.c. OSL uses mat4 so I've tried to keep all the code as consistent as possible.

Address comments from @Omar Ahmad (OmarSquircleArt)

Fixed performance regression that caused BMW benchmark scene to only be 1.1x faster instead of 1.6x

In D3789#124877, @Charlie Jolly (charlie) wrote:

This wouldn't work with the mapping node as this exposes rotation values as socket inputs.

This wouldn't work with the mapping node as this exposes rotation values as socket inputs.

I wounder if we can implement this using graph expansion. It would expand to two nodes I think, a Vector Math node and a Mapping node. I used expansion before and it was very nice and easy to use. Maybe you should give it a try. Check the following commit for reference rB7a7eadaf.