BKE_id_move_to_same_lib
behavior with invalid parameters.
I think generally the approach is the safest for 4.3 and for porting to 4.2.
Why do we need to set it in the cache? I'd imagine it will be the same as HIP_VERSION
, HIP_VERSION_SHORT
.
Explicit yield()
is definitely better than sleep for 1 millisecond. Solving the immediate crash is good, but we should revisit those waits in a foreseeable future.
@mont29 Seems to make sense to me. The only suggestion I have is to target 4.3, any thoughts?
Don't use std::move
in return
. Compilers should actually warn about, but I didn't double-check it in Blender/Cycles code :)
Generally fine, but would be nice to have some details about the alignment requirement.
I don't really understand the alignment here. 8
seems to be some odd-ball, at least intuitively. Where is this requirement coming from?
I love to see functions becoming more aligned with the single responsibility principle!
I primarily want to avoid situations where thousands of lines of harmless warnings are logged.
Those wouldn't be warnings, but verbose insights about what's going on with Cycles's decisions.…
I don't think the failure in Cycles is related to this change?
To me it all sounds good! But I'm kinda in the minority of "gimme all the logs".
To me it sounds that these standards define a "thing" that has particular properties. So you can't mix and match properties of multiple standards in one "thing".
There mighr indeed some…
By the reading the code and explanation and such seems fine.
So I think, that we should either make a property for which encoding is to be used or switch encoding based on movie resolution. In case of automatic switching, question would be what to do…