cmake's docs on if say

awesome! no changes needed then! I'll give it a go when i'm back home!

on further review of mesons requirements looks like we can just unpack a copy somewhere (like we do in dpcpp_deps.cmake) and call it directly through the python we already have , seems easy enough

suggested change is a suggestion only, if this lands as is it's fine with me.

kept no notes, but at quick glance i see no need for it, i likely wanted to keep options and the one with all boosts nonsense in it close together. changing the order back is fine with me.

still traveling, so i only took a quick glance, it's a little more problematic on windows, while ninja is just an executable we can drop in the executable and be on our way, meson depends on python, and we're going essentially out of our way to prevent any deps from picking up a system python and attempting to use it to the point, i have no system python anymore. We'll have to bootstrap meson into the python we build for blender, not impossible, we can probably just chuck it in with the other deps we install in site packages but we'll have to see if that drags in any other undesirable deps

no need to calm down, my list of points was merely a stern warning that this cannot land in its current form unless these issues are dealt with as it would break the build pretty badly, no-one is upset. some of these changes you can do (like replacing findpkg with some cmake magic) other i'll (or the other platform devs) will do (like scripting the dep for inclusion in our svn libs) others @Clément Foucault (fclem) / @Jeroen Bakker (jbakker) will have to look at and see if it's an issue (ie the wgl stuff) they are all however real issues and we have to deal with them at one point before this lands.

Couple of problems with this:

This has not been tested on other systems (Windows, macOS) as I do not have access to those systems and the build bot does not allow me to trigger experimental builds any more (I get "you need to have role 'any-control'").

In D15254#411617, @Sergey Sharybin (sergey) wrote:

Addendum.
The proposal for the DPC++ is to put it outside of SVN, so that we don't push it to every Blender developer and user who builds Blender from sources. We'll also make it an optional step of make deps, so that it is much better controlled on who and when builds the toolchain.

I think this should be good to go now, right?

I've noticed it too in the past, output has the same issue there's tons of them, they all do have a unique name though so that may help.

I can build with whatever flags you desire, he current x264 flags are pretty close to stock if someone has improvements to suggest i'll be happy to make some test builds to see if they improve things, i don't think a vp9 ticket is the ideal place to discuss this though.

Removed the part that says Blender saves the current scene as "quit.blend" when exiting, as it turns out this is not actually true.

took a closer look, it does the right thing for exotic instruction support, so that we could enable, still have to check why threading was disabled.

it appears to be giving the error if there's already a blender shortcut on the desktop, we should probably include the version in the shortcut anyhow given one could install 3.1 and 3.2 side by side.

The bug tracker is just for bugs, if you have questions about the code, please use devtalk.blender.org

@Germano Cavalcante (mano-wii) i can't locally repro, could you get the log file created by

rB6065fbb54393: Fix std::optional value() build error on older macOS SDK shows that using std::optional::value() has issues on macOS. Might want to test the patch thoroughly on the buildbots.

which can have very huge file sizes.

@Xavier Hallade (xavier) i see you quietly switched to sycl 20220529.

Can confirm, i can successfully build a kernel on centos now

In D15082#406821, @Brecht Van Lommel (brecht) wrote:

The API docs seems to say otherwise, but I have not tested it.
https://spec.oneapi.io/versions/1.0-rev-1/elements/oneTBB/source/memory_allocation/scalable_allocator_cls.html

Thanks for confirming my results, always good to know it's not just me :)

this patch isn't really related to replacing global malloc.

It's getting little confusing, maybe we should rename WITH_TBB_MALLOC_PROXY to a more suitable WITH_TBB_ALLOCATOR ?

Unsure how much progress you are expecting on an archived ticket, but i'll chime in nonetheless, you are likely trying to build cycles standalone, which only gets updated after each release against blender master libs which already has moved on to newer versions of most dependencies.

@Kent Davis (mac4kent) please be patient and kind towards the people trying to help you, there are currently 2069 open reports on the bug tracker so things tend to take some time, and by specifically demanding only mac dev/triager to may look at your report that wait will be even longer since there are fewer of those.

even easier, we can just wait it out :)

In T70495#791431, @Brecht Van Lommel (brecht) wrote:

We do not support loading PSD from from memory as happens for packed files, since that is not supported by OpenImageIO.
We could work around this by writing the memory block to a temporary file on disk and then reading that.

The memory should have come from GlobalAlloc and not LocalAlloc in the first place per the documentation here

alight, not what i was hoping for, given i have no desire to go debug ocloc but progress nonetheless

soo.. some good news, bad news.

oh wow, this has been wrong for 13 years....

note for future me:

https://builder.blender.org/admin/#/builders/18/builds/434

agree a better commit message is needed though

LGTM, the test coverage seems extensive enough to trust this has been implemented properly. The real test on how complete the code is will probably be when the debian guys update to a version that has these tests.

@Sebastian Parborg (zeddb) / @Sergey Sharybin (sergey) can you two get to a consensus what to ship?

Just to see if understand this correctly there's 3 AV1 libraries libaom-av1, librav1e, and libsvtav1. is it suggested we enable all 3 in the build we ship on blender.org? The updated unit test only seems to add a test for libaom-av1 can anyone clarify this? (asking since i'm the one most likely doing the work of updating our ffmpeg build)

all the buildscripts should be complete, they should build with no issues on both windows and centos (centos7 disclaimer, the stock flex is outdated, needs to be replaced with a build from source 2.6.4 or you'll have build errors), the blender windows build with dg2 enabled I made @Xavier Hallade (xavier) was able to confirm as working, on linux all the puzzle pieces are in place but due to my centos container running out of ram i could not complete a blender build there.

but no need to get picky on the gcc version by the looks of it, it seems to repro on all GCC versions

it's gcc 9.3.1. on centos7

It seems thoroughly covered by tests, that i like, kicked off a build to see how all compilers like it

Any network drives that may be unavailable?

I had to revert this as it caused build errors on mac X64, mac ARM and newer versions of MSVC where it actually has include <stdatomic.h> but does not support building in C mode.

If neither of us is sure, I'd say go find out. blender HAS to link with something to get the symbols it needs. So either this diff will cause a build error, or your premise you can't link the python binary that provides these symbols is false

Way out of my comfort zone, can't say i understand, if we're not allowed to link against python, how does it get the python symbols we rely on?

Scripted sycl (and it's deps) for both windows and linux should be available in the deps builder of cycles_oneapi

Please use the rightclickselect site for future requests.

In D14993#403631, @Jacques Lucke (JacquesLucke) wrote:

I'm not sure a guard is necessary.

All attributes unknown to an implementation are ignored without causing an error. (https://en.cppreference.com/w/cpp/language/attributes)

In D14953#403469, @Sebastian Parborg (zeddb) wrote:

From what I gathered is that they haven't implemented stdatomic in their C compiler -_-

The windows implementation is ok, since our lower bar is 16.9 which this attribute got added in, so in the clear there, I'm unsure where exactly our gcc/clang bar sits ? should we guard this with some kind of test in cmake to see if the compiler supports it?

it's usually a bad unpack of the zip file and files are missing

The msvc implementation is special, the attribute does nothing unless you use msvc::no_unique_address

I don't think you can make any assumptions in code about the default codepage, if code is accommodating for wide paths on windows, they are likely to call multibytetowidechar by them selves, (which also advises against relying on CP_ACP) and call the W variant, I'm a little hesitant since it's a new option not sure if we'll run into unintended consequences, we are still in bcon1 for 3.3 and it's a 5 line patch, it's an easy revert, it be more comfortable landing it for 3.3 only rather than for 3.3+3.2

current concerns:

possible fix in D14981 but i'm not super thrilled it only fixes things on win10 1903+

still a problem