Already fixed in rB725b59d9b44a632095c90e1912f14431b0171f1d

Can confirm the threadspin seems to be gone, and the perf got a massive boost! well done @Jeroen Bakker (jbakker) !

• fix typos and whitespace

Somehow this never got committed, i updated it to latest master.

Update to latest master

This seems fun, mind if i take it?

If it takes down the whole machine, there's no amount of logging in blender that could help, best to follow @Asher (ThatAsherGuy) 's advise and check the system logs

I asked for the ticket on chat, WITH_CYCLES_NATIVE_ONLY is not an option that gets a whole lot of exercise on windows, so if there's a problem with it i'd like to look into it and resolve the issue, that being said i'm unable repro

I have to admit, scraping the bottom of the barrel here

Ok not easily defeated try

Can you try this?

I matched your build options as close as i could, still nothing.

can't seem to repro with the standard developer profile options,could you share your cmakecache.txt ?

manually added it to the blacklist, dialog seems to work!

Executable shouldn't increase dramatically, i ran a quick local test with a self signed cert

There were some other linker shenanigans, builds now, but it didn't seem to give me a warn on mesa/llvm pipe on windows, so i didn't actually see the dialog.

• small build fixes

near the top of the file, it changes the target version back to XP, just remove it, it's being set correctly in platform_win32.cmake

Probably placebo effect, or the result of hard work by other devs that perhaps committed optimizations in the last 24 hours.

• add volatile to the func1 case as well

use volatile rather than telling clang /Ob1

I tried to extract a repro and i'm kinda stumped only msvc seems to handle this correctly, both llvm and gcc get overly aggressive.

• Merge remote-tracking branch 'origin/master' into tmp_clang_openmp_fix
• Add quotes for libopmp to resolve linker errors when there are spaces in its path.

Started bisecting with a lite build rather than a full build hoping it would could down the time required, and the numbers didn't seem to line up at all. here's something interesting:

my measurements were with vsync off, taken with fraps with a blender release build windows, picked the highest number that stayed long enough on screen for me to actually read it.

Platform wise, not a huge fan of sprinkling #ifdef win32's all over the place, but there currently is no place to segregate platform specific stuff like this, so what you have now will do just fine for now.

Retested this ticket, no measurable improvement with the fix committed by @Clément Foucault (fclem)

I got a slew of linker errors on linux, not entirely sure what is up there, mind having a peek there @Sybren A. Stüvel (sybren) ?

A better version by @Jeroen Bakker (jbakker) has landed

nobody is advocating dropping support for older gpu's, this ticket is merely here to index the 'bad driver versions' and notify the users on how to rectify the situation, rather than just having blender crash on their system.

This is actually less complicated than you may think, in vista (our current low bar) we got a [[ https://docs.microsoft.com/en-us/windows/win32/controls/task-dialogs | new dialog API ]]for simple things like this.

Took a closer look, the working folder should actually be the bin folder, but due to a bug in our buildscripts it is not, will address in a separate diff since it really has nothing to do with openmp.

Are other dlls copied to the tests directory?

no , but we kinda count on the msvc run-time being installed since we just ran the compiler... so that took care of that issue for regular msvc builds

I can confirm, the difference between 2.80 and latest master (measured with fraps cause blender's counter was waaaaaaaaaay to jumpy)

While this restores OpenMP support for the main blender executable, the test executables that end up in bin\tests\release and they won't run until you manually copy libomp.dll there not entirely sure where would be the best place to copy that automatically?

See P1124 for how to add a help button on windows , not super thrilled about that global for storing the link, but didn't see a neat other way to do it.

When you start blender with the blender_factory_startup.cmd batch file located in the same folder as blender, does it start on a different monitor?

It's the terms nvidia users to distinguish between high level virtual architecture (ptx) and actual code(sm)

Do you have more reasoning on why ? and why this would benefit windows devs more than other devs?

I'd probably start by validating it is a TDR issue, by looking in the event viewer from around the time of the crash and see if there are any TDR events reported.

I'm gonna guess it's a TDR issue, too much work is queued and the OS kills the GPU driver after it gets unresponsive for more than a few seconds.

test raise concern, @Julian Eisel (Severin) mentioned it stopped working.

It's a little bit of a hack, it bugged me enough to fix it, but not to make it available in the UI for end users, it's one of those "it scratched my itch" patches, if we don't want this in mainline I understand.

why not just do it once in GHOST_SystemWin32::init() ?

When you run the following code on the python console and re-open the file dialog does the problem still occur?

All done! thanks for the patch!

beyond that one whitespace change looks good

if you want to test with self sign, there's a pretty good guide for making your own cert over here

bubbling up the native system dialog from ghost is somewhat of a hairy mess, i'll deal with that in a separate diff and come back to this one once that has landed.

after some discussion with @Dalai Felinto (dfelinto) on chat re-triaged as medium.

I did some profiling

That's a rather significant patch to embree, most of the other patches we have in the deps_builder are mostly oneliners to deal with build issues on various platforms, are there any plans to upstream these changes?

Pretty sure i know what's up, but i'm unsure how to go about debugging/fixing it.