I fully agree it’s about time to drop the old and focus most/all resources on the new
On Sat, Jan 27, 2018 at 3:38 AM, Aaron Carlisle <[email protected]> wrote: > +1 From me too. > > Re fully dropping 32bit > > I think this is an acceptable change the biggest issue we may have here is > schools and other small teachings institutes running older hardware. > However, like we said they can stick to 2.7x. > Any serious artist (one who will want the newest features) will probably > be running 64-bit and won't affect artists. > > On Fri, Jan 26, 2018 at 3:38 PM, Danrae Pray <[email protected]> > wrote: > > > Big +1 from me. Especially the notes about dropping ancient hardware > > support... > > > > Thanks for the great work on Windows stuff Ray! > > > > On Jan 26, 2018 12:54 PM, "Mike Erwin" <[email protected]> > wrote: > > > > > +1 on all points. > > > > > > Unifying around MSVC 2017 would clean up our build instructions & > benefit > > > from MS's latest bug fixes. > > > > > > MacOS has been 64-bit only since 10.7 (Lion) so it won't affect any > users > > > there. > > > > > > While I appreciate vintage computers, and have lots of 32-bit systems > > > myself, I don't expect to run the latest software on them. > > > > > > Mike Erwin > > > musician, naturalist, pixel pusher, hacker extraordinaire > > > > > > On Fri, Jan 26, 2018 at 12:51 PM, Ray Molenkamp <[email protected]> > > wrote: > > > > > > > All, > > > > > > > > With 2.8 coming up I'd like to make some changes to the supported > > > > compilers for Blender. However since these are rather large changes > > > > I'd like to give everyone an opportunity to express any concerns. > > > > > > > > Issues: > > > > > > > > 1) Currently we support msvc 2013(vc12)/2015(vc14)/2017(vc14) > > > > for building, however we ship all our releases with msvc2013(vc12). > > This > > > > has > > > > lead to some interesting issues with python, since any binary addons > > the > > > > user > > > > might install with pip (or just manually copy in) will be using the > > vc14 > > > > crt. > > > > It's rare to run into issues, but when it does it's an instant > process > > > > termination > > > > (the crt does not deal meeting it's future/past self very well) > > > > > > > > Given python is our most important dependency I'd like to propose > that > > > any > > > > blender > > > > version we ship in the future (2.8+, 2.79x can keep doing what it's > > > doing) > > > > matches > > > > the official python recommendation for that version [1] so we have > > > maximum > > > > compatibility with any python addons > > > > > > > > 2) To support msvc 2017 we'll officially need a newer boost version, > > > sadly > > > > support > > > > for the latest is only available in 1.66 and i have not tested yet if > > all > > > > our > > > > dependencies can actually build against it. However we have no > failing > > > > tests when > > > > building blender with boost 1.60+2017. it is just a bit (212 warns) > > > chatty > > > > with > > > > unknown compiler warnings, we could possibly repress these. > > > > > > > > 3) We recently added a switch in cmake to force the compiler to read > > all > > > > our code > > > > as utf-8 (since there were some users on other codepages that got > > > compiler > > > > errors > > > > on some utf8 strings) this added 290 C4828 compiler warnings to a > full > > > > blender build. > > > > not great. None of these originate in our code, they are dragged in > > > though > > > > 3rd party > > > > headers. > > > > > > > > 10 in extern/bullet (we can probably fix these) > > > > 19 in lib/boost (this one is fixed in newer boost versions [2]) > > > > 261 in lib/OpenCollada (we can easily send a pull upstream) > > > > > > > > however all of these are in comments, completely repressing C4828 > might > > > > not be the > > > > worst thing here. > > > > > > > > 4) Libraries > > > > > > > > There's a library upgrade [3] coming up for OSL/LLVM/OIIO that just > > > > doesn't build on > > > > msvc2013. > > > > > > > > 5) Cuda > > > > > > > > Nvidia is notoriously slow with supporting newer msvc versions > severely > > > > limiting the > > > > compiler versions we can use (cuda9 only supports 2017 RTM, and we're > > on > > > > update 5 > > > > for msvc currently), to resolve this hostage situation I have > created a > > > > small wrapper > > > > around nvrtc that's able to compile cycles [4], however nvidia > doesn't > > > > allow nvrtc > > > > to create 32 bit cubins. which held me back from committing it. > > > > > > > > 6) 32 bit support > > > > > > > > I spend a fair amount of time building the blender deps in various > > > > formats, x86 > > > > it starting to cost more and more time since a few of the projects > just > > > > seem > > > > to test on linux, sometimes on windows/x64 but rarely on x86 leading > to > > > > all kinds > > > > of obscure (usually sse) related build errors. This is starting to > take > > > up > > > > a > > > > significant amount of my time for only a small percentage of end > users > > > > (last > > > > time I asked ~15% of the blender downloads were for 32 bit users) and > > by > > > > the > > > > time we release 2.8 this number will probably have dropped even > > further. > > > > > > > > Proposal: > > > > > > > > Officially drop msvc 2013 support for master/2.80 and make vs2017.5 > the > > > > new standard. > > > > > > > > 1) Land D2913, I had been dragging my heels on this because of the > > > > breakage for x86 > > > > but given brecht recently put out an email [5] saying we were going > to > > > > drop support > > > > there's no reason not to apply this anymore. > > > > > > > > 2) Retire the 2013+2015 buildbots, and replace them with vs2017 based > > > > builds. > > > > > > > > 3) Block msvc2013 version in cmake > > > > > > > > 4) Remove the vc12 folders from svn > > > > > > > > 5) Silence the 'unknown compiler warning in our boost version' > > > > > > > > 6) Add C4828 to the ignored warning list. > > > > > > > > 7) Update the wiki build instructions. > > > > > > > > I can do most of these my self, but will probably need sergey to do > no > > 2. > > > > > > > > Pushing my luck: > > > > > > > > Is it too soon to drop x86 support? > > > > > > > > Note that all of these changes are for master/2.80. any updates for > > 2.79 > > > > a/b/c/etc > > > > will remain on msvc2013 with the current libraries. > > > > > > > > --Ray > > > > > > > > [1] https://wiki.python.org/moin/WindowsCompilers > > > > [2] https://github.com/boostorg/format/commit/ > > > > 045c6f15b9f6ef654642906f458d26b584b0b4c9 > > > > [3] https://developer.blender.org/D2915 > > > > [4] https://developer.blender.org/D2913 > > > > [5] https://lists.blender.org/pipermail/bf-committers/2018- > > > > January/049029.html > > > > > > > > _______________________________________________ > > > > Bf-committers mailing list > > > > [email protected] > > > > https://lists.blender.org/mailman/listinfo/bf-committers > > > > > > > _______________________________________________ > > > Bf-committers mailing list > > > [email protected] > > > https://lists.blender.org/mailman/listinfo/bf-committers > > > > > _______________________________________________ > > Bf-committers mailing list > > [email protected] > > https://lists.blender.org/mailman/listinfo/bf-committers > > > > > > -- > Aaron Carlisle > > Picture taker | Bit cruncher | Pixel pusher | Document writer | Artist > Project administrator for the Blender 3D Documentation Project > _______________________________________________ > Bf-committers mailing list > [email protected] > https://lists.blender.org/mailman/listinfo/bf-committers > > _______________________________________________ Bf-committers mailing list [email protected] https://lists.blender.org/mailman/listinfo/bf-committers
