Hi, while we love to hear these ideas, this is not the right place for them. This website is mainly used to track bug reports and not feature requests. But luckly, there are some other nice solutions you can take, so please use one of the other forms of communication listed below:

no problem

on win7 with sm_30 (gtx670) which was one of the problematic ones

is the bmw scene linked different from the one in our benchmark suite? or was it just linked for convenience?

For future reference for all devs involved, this problem is indicative of the usage of the python multiprocessing module on windows, what it tries to do is spawn a new python interpreter by starting another copy of the currently running process with some extra parameters, sadly in our case, the running process is blender.exe and blender doesn't get any of the python specific command line options soo that ends up working really badly.

the default displacement method got set back to bump for various reasons ( rBrB3a527357a556491406ee9d33a79ab0af5f79e326 ) set it back to displacement and you'll be fine.

seems like the image sequences are missing?

Please provide a complete example with all required files and steps to reproduce this issue.

it's a use after free bug ASAN will catch it if you can't repro

I can repro this with both the builds from the buildbot and local builds.

No idea, both the .zip and .msi are packaged from the same binaries, there's not even a recompile there so the behavior should be identical between the two.

Thanks for the report, but this add-on is not developed by Blender, please report the bug to the original author

Seems fine here, most of the install size seems to go to the sub features.

that seemed to have done it! thanks!

In rBc1da8e3b28f95188f9e9152383856c95f29586b4#216661, @Sergey Sharybin (sergey) wrote:

@LazyDodo (LazyDodo), can this be unconcerned now?

yeah it but doesn't seem to want to let me?

I Can't reproduce with the latest nightly.

I Can't reproduce with the latest nightly.

as @Robert Guetzkow (rjg) suggested try the --debug and perhaps --debug-gpu flags , run from the console and see if there's any interesting log messages shortly before crashing.

I have, i can't reproduce

I have no interest to insert my self in this quarrel, however i would like to point out that while looking at P896 i have no issues reading the lines with w/o in it, my brain infers 'without' instantly, on the other hand the lines with just w/ stops me right in my tracks while my brain tries to comprehend what is going on, it looks like there is something missing after the /, after a short while it figures it out, and has to re-read the whole line with this time keeping the epiphany it just had in mind. and the next line with w/ we do it all over again.

probably using your distro's build of blender, try a build from www.blender.org and you'll most likely be ok.

I can't count on python being available on windows, I'd prefer doing this from cmake if possible.

On windows .clang-format and .editorconfig will override any of the defaults set in VS unless the user deliberately goes out of their way to disable support for it.

is that 6.0+ or is a bare 6.0 'good enough' on windows we have 6.0.0 on vs2017, and 7.0.0 on the vs2019(-pre release) out of the box shipped with vs. We have a 6.0.1 copy in the svn libraries, but that will have to be manually configured by the end user if we want to use that.

A: On Mac, clang-format is available by default as part of XCode. On Linux it is available with sudo apt-get install clang-format. On Windows, it is available as part of the Windows builds.

That's something the unity people will need to look at.

In T53211#594895, @Brecht Van Lommel (brecht) wrote:

This would be ideal, the issue AFAICS is there is no way to tell clang-format to do this.

Right, clang-format can't add or remove braces. I just meant for the guidelines that we follow manually.

Looks like clang-tidy may be able to do this , not ideal, but we'd have to run it once during migration to the new rules so it may not be that bad...

Hi, while we love to hear these ideas, this is not the right place for them. This website is mainly used to track bug reports and not feature requests. But luckly, there are some other nice solutions you can take, so please use one of the other forms of communication listed below:

why not control it with the options in the performance section of blender? set it to use a single thread and off you go, leaving it on auto (which in your case is probably 12) and limiting affinity manually to a single core will lead to excessive context switches ruining performance.

Given 2.8 has finally made it to master, is there any chance we can get this moving again?

I'm still on win7, @Joshua Leung (aligorith) do you have time to take a look at this?

Can't reproduce on win64, try starting with --factory-startup and see if that helps.

This website is used to track bugs, feature requests or ideas are not supposed to be here, hence there is no category for them in the list you mentioned.

Different issue, for mac opencl support has been dropped

Nothing wrong with that, if you want to do some cleanup and replace the SHGetSpecialFolderPathW calls with SHGetKnownFolderPath I say go for it, I'll happily accept cleanup patches, it's not the most glamorous work but it's a great way to contribute some code :)

In D4145#93779, @Harley Acheson (harley) wrote:

But with in mind we should instead consider changing from the unsupported SHGetSpecialFolderPathW

It's only unsupported in a sense of that the arm builds don't have it, and given we don't support arm on windows currently, no big deal. (currently, if we ever go the arm route this will have to change)

please try with a build from builder.blender.org, just to rule out a distro specific packaging issue.

Are these builds from builder.blender.org or homebuild/distro build?

On XP and up CSIDL_PERSONAL and CSIDL_MYDOCUMENTS are equivalent and since the lowest we support is vista this change should not make a difference on any of our supported platforms.

I'm pretty sure this got fixed this week, please try with a newer build first.

please do not assign priority your self, this will cause the triage team to miss your ticket

Patches shouldn't be needed though, the win32 buildbots are having no issues

Build instructions here.

In D3960#93242, @Brecht Van Lommel (brecht) wrote:

It shouldn't be defined multiple times in the first place. If we check if it has been defined before, we don't know if the macro has been defined correctly.

I've never seen this warning though, it would help to see the compiler warning log to understand why it happens.

In T48096#586329, @Tuomo Keskitalo (tkeskita) wrote:

In T48096#585785, @LazyDodo (LazyDodo) wrote:

I was browsing the scraped copy last week, and bumped into a searchbox somewhere, we'd probably have to get rid of those otherwise users will use them and make tickets that it is not working.

I guess you mean the quick search on lower left corner? Good idea! I'll also remove the "Page" menu from top right and "Wiki" menu from bottom right.

I was browsing the scraped copy last week, and bumped into a searchbox somewhere, we'd probably have to get rid of those otherwise users will use them and make tickets that it is not working.

from your system-info

		CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MAJOR			2
		CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MINOR			1

that's a compute 2.1 card, those are no longer supported.

wait, this is your own build? please try with prebuild blender from https://builder.blender.org/download/

Thanks for the report, but this add-on is not developed by Blender, please report the bug to the original author.

openCL support has been disabled for mac so sadly this seems to be by design.

please do not assign priority your self

please do not triage tickets your self, by doing this it will make it less likely the triage team will see your ticket and assign it to the right developer.

Actually it has always been there on windows, it works in 2.79, but when i packaged py3.7 i missed a dll. Should be fixed in the next nightly

the crashdump seems to imply dxgmms2.sys is at fault, which is a microsoft driver , you appear to be running the april 2018 update of windows 10, updating to the latest (october) would probably not be the worst thing to try.

In D4062#91945, @Nick Renieris (velocity) wrote:

And yeah @LazyDodo (LazyDodo) there would be some neat things that could be done, if it wasn't for the annoying 15 char POSIX limitation.

No need to worry about that, I'll do it, and will let you know here when it's done.

Not sure how much information this really adds, It's pretty clear the code is running in a threadpool by simply looking at the callstack. And the first question you then generally have is 'who queued this?' which this doesn't answer, (we could store a callstack i suppose from the location that pushed the work, but i doubt it's worth the overhead) however if it doesn't break anything, and people find it useful, i have nothing against naming the threads.

there's some background on the cuda 9.1/10 issue in T56858 but as i said earlier if 9.1 doesn't work for this issue, it's very likely a different issue and we shouldn't be mixing the reports cause that'll just confuse everyone.

with that function name change lgtm.

please do not assign priority your self, since it actually makes it less likely for the people triaging the bug tracker to look at your report.

GT555M is an sm_21/fermi based card, for which support in cuda has been dropped.

On windows all dialogs have the button order by design agree/disagree/cancel , this is what people expect, this is what every other application does, this is what D3118 does, this commit doesn't do that and breaks the platform UI standards.

this wasn't enabled yet on all platforms due to wrong order of the buttons on some platforms (*cough*windows*cough*) and lack of a 'default' button support, see D3118 for details, please revert for the time being.

if 9.1 doesn't work, it's definitely a different bug, opening back up.

It's a bug in cuda10(some cards)/9.2(all cards) we cannot work around, nvidia has been informed, there's nothing we can do on our side, so no need to keep a ticket open.

also that's a cuda 10 bug, use 9.1 and you'll be allright.

please do not assign priority your self.

Which is one of the reasons i picked sentry unlike other solutions in this space, it's opensource and you can run it on your own servers.

We got a native crackle a while ago, grab a nightly build at http://builder.blender.org and enjoy.

you can leave out the url bit, by just mentioning D3971 in the text, phabricator will link the two for you :)