embree.diff is not included in the patch? If this is not too complicated, I'm still hoping we can contribute this upstream rather than maintain it ourselves.
Mon, Nov 30
Updates according to comments:
- embree arm64 build merged into normal embree build in build_script
- removed windows-breaking commands
- few typos / small fixes
Fri, Nov 27
Thx getting back! Cannot reproduce the vertex-color-glitch.
Thu, Nov 26
I am going over old reports, I have seen similar reports here on tracker with Mesa + Intel. Since @bassam kurdali (bassamk) can't check anymore, I will close this one.
@Philipp Oeser (lichtwerk) : Actually no, not happening anymore :) The motion-blur thing I mean. Seems to be fixed.
Cannot reproduce here
Thanks everyone for the responses!
Wed, Nov 25
Mon, Nov 23
I guess the next step here would be to bisect and find the commit that caused this, which could be done either by the triaging team or another developer.
Fri, Nov 20
I've added myself as reviewer, as Linux platform maintainer.
Overall there seems to be very little consideration for other platforms and various arbitrary changes.
Am not especially thrilled to have to deal with two code paths in install_deps for a single lib... main question here for me is, if arm64 need Embree 3.12, can't we switch whole Blender deps to that version of Embree?
@Brecht Van Lommel (brecht): dont think there is anything more that the triaging team can do here?
Thu, Nov 19
Compiler docs is one thing, actual compiler implementation is totally another thing. Code might be looking correct, but it will behave wrong. Or not compile.
Since you guys are not comfortable checking correctness of the code based on compiler docs, here's an alternative that removes the need to check it at all.
Remove uint64_t bit atomics from public API, and solve session UUID with D9605 instead.
@Sergey Sharybin (sergey) I'm not getting a straight answer from @Brecht Van Lommel (brecht) about who is responsible for testing platform-specific fixes, and where the line between "supported" and "unsupported" lies. What I read in his recent answer on bf-committers is "I know this patch will work, so I don't need to test it". I strongly disagree with that mentality, but I'll just accept his assumption that he's right in this case and stop discussing it.
Wed, Nov 18
After D9590 is applied we would have an easier way of verifying this module works as it is intended.
Tue, Nov 17
adding ARCH_ARM64 constant to cmake files
Mon, Nov 16
I'll post about this on bf-committers, I think that is a better place to discuss & clarify such policies than on this code review.
When writing or reviewing code, you ensure that there is always a processor architecture independent code path. And if you get a report and it turns out such a code path is missing or broken, you fix it. It's the same for x86, mips, sparc, etc.
I still wouldn't mind to know more about the status of 32-bit platform support, because it's all very unclear to me. So far I didn't bother with that too much, but now that I'm the Linux platform maintainer, it's kind of relevant for me to get a clearer picture of this.
The policy was communicated here:
What is official policy even about 32bit platforms?
Thu, Nov 12
Sat, Nov 7
Blender user for 3 years now here, on Linux - I have that same issues since 2.83 came. 2.82a is still working flawlessly.
Oct 27 2020
Oct 18 2020
OK, thx getting back - and solving the issue yourself :)
Oct 16 2020
I just tested 2.91.0 Alpha (ba8233174cd7) with the legacy nVidia cards, it works. Both 2.83.7 and 2.90.1 are not working.
Oct 14 2020
Here on linux I can even reproduce it on a single axis (any border, not only corners). I think this is related to hdpi mice, the current time check is a bit to strict in those cases and can still allow for double-wraps sometimes.