Re: [Bf-committers] Changes to Windows Compiler Support.

[Brecht Van Lommel]

I think 13.2% of downloads is still a lot, that's about the same percentage
as macOS + Linux downloads. However by the time 2.8 is released that number
will be lower, and I expect most of those computers will not have a GPU
with the new OpenGL minimum requirements anyway.

The Steam hardware survey shows only 2% of their users have a 32 bit OS.
That makes me doubt if the Blender download statistics are representative
for the installed OS, though it's not clear to me why they wouldn't be.

Overall I think it's reasonable to stop supporting 32 bit.

On Sun, Jan 28, 2018 at 11:30 AM, blendergit <blender...@gmail.com> wrote:

> I think the point here is if we want use our limited resources in a
> version that is used by a few number of users.
>
> The decision must be more strategic than technical. The users using 32bits
> always can download 2.79, but if they want to use last 2.8 features, need a
> 64 bits computer (nothing fancy today).
>
> To have only 64 bits versions in windows will release some resources to
> work in improve Blender instead to use that time in keep running something
> outdated.
>
> Antonio
>
> De: Knapp
> Enviado: sábado, 27 de enero de 2018 23:10
> Para: bf-blender developers
> Asunto: Re: [Bf-committers] Changes to Windows Compiler Support.
>
> On Sat, Jan 27, 2018 at 9:36 PM, Ray Molenkamp <r...@lazydodo.com> wrote:
>
> > the website does a rather excellent job at giving people the proper
> > download for their platform, i'm pretty sure those are legitimate 32 bit
> > users.
> >
> > --Ray
>
>
> I was not falting the website at all, just that us users can sometimes be
> asleep. I know that I one time downloaded 32 bit 2.79 by misclicking and
> then came back and downloaded the correct one.
>
> --
> Douglas E Knapp, MSAOM, LAc.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Changes to Windows Compiler Support.

[blendergit]

I think the point here is if we want use our limited resources in a version 
that is used by a few number of users.

The decision must be more strategic than technical. The users using 32bits 
always can download 2.79, but if they want to use last 2.8 features, need a 64 
bits computer (nothing fancy today).

To have only 64 bits versions in windows will release some resources to work in 
improve Blender instead to use that time in keep running something outdated.

Antonio

De: Knapp
Enviado: sábado, 27 de enero de 2018 23:10
Para: bf-blender developers
Asunto: Re: [Bf-committers] Changes to Windows Compiler Support.

On Sat, Jan 27, 2018 at 9:36 PM, Ray Molenkamp <r...@lazydodo.com> wrote:

> the website does a rather excellent job at giving people the proper
> download for their platform, i'm pretty sure those are legitimate 32 bit
> users.
>
> --Ray


I was not falting the website at all, just that us users can sometimes be
asleep. I know that I one time downloaded 32 bit 2.79 by misclicking and
then came back and downloaded the correct one.

-- 
Douglas E Knapp, MSAOM, LAc.
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Changes to Windows Compiler Support.

[Knapp]

On Sat, Jan 27, 2018 at 9:36 PM, Ray Molenkamp  wrote:

> the website does a rather excellent job at giving people the proper
> download for their platform, i'm pretty sure those are legitimate 32 bit
> users.
>
> --Ray


I was not falting the website at all, just that us users can sometimes be
asleep. I know that I one time downloaded 32 bit 2.79 by misclicking and
then came back and downloaded the correct one.

-- 
Douglas E Knapp, MSAOM, LAc.
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Changes to Windows Compiler Support.

[Ray Molenkamp]

the website does a rather excellent job at giving people the proper download 
for their platform, i'm pretty sure those are legitimate 32 bit users.

--Ray


On 1/27/2018 12:18 PM, Knapp wrote:
> using this data looking at just the latest blender (2.79) limiting it to
>
> I wonder how many of those 13% clicked on the wrong thing through ignorance
> or just being distracted.
>

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Changes to Windows Compiler Support.

[Knapp]

On Sat, Jan 27, 2018 at 6:27 PM, Ray Molenkamp  wrote:

> if you bunch up all releases since 2014, yes that does seems to imply 36%
> are still on 32 bit.
>
> however if you split it out per version it paints a 'slightly' different
> picture
>
> https://imgur.com/a/ZG0Gb
>
> with only 13.2% of 32 bit users for 2.79 and in a rather steep decline
> from previous versions.
>
> --Ray
>
>
using this data looking at just the latest blender (2.79) limiting it to


I wonder how many of those 13% clicked on the wrong thing through ignorance
or just being distracted.

-- 
Douglas E Knapp, MSAOM, LAc.
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Changes to Windows Compiler Support.

[Ray Molenkamp]

if you bunch up all releases since 2014, yes that does seems to imply 36% are 
still on 32 bit.

however if you split it out per version it paints a 'slightly' different picture

https://imgur.com/a/ZG0Gb

with only 13.2% of 32 bit users for 2.79 and in a rather steep decline from 
previous versions.

--Ray


using this data looking at just the latest blender (2.79) limiting it to


On 1/27/2018 9:39 AM, Dan McGrath wrote:
> Hi,
>
>> 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.
> Out of curiosity, I parsed all of our download.blender.org logs since near
> the end of 2014, right up until today and stored them in an sqlite3
> database for people to check. You can download the file at:
>
>   https://download.blender.org/ftp/dan/admin/blender_logs.sqlite.bz2
>
> I specifically limited the list to 200 status files and only valid
> filenames. The schema is:
>
> sqlite> .schema
> CREATE TABLE logs (log_date date NOT NULL, url text NOT NULL, filename text
> NOT NULL, blender_version varchar(10) NULL, bits integer);
> CREATE INDEX idx_bits on logs(bits);
> CREATE INDEX idx_filename on logs(filename);
> CREATE INDEX idx_url on logs(url);
> sqlite> select * from logs limit 3;
> 26/Mar/2014|/release/Blender2.49b/blender-2.49b-windows.exe|blender-2.49b-windows.exe|2.49b|0
> 26/Mar/2014|/release/Blender2.70/blender-2.70-OSX_10.6-x86_64.zip|blender-2.70-OSX_10.6-x86_64.zip|2.70|64
> 26/Mar/2014|/release/Blender2.69/blender-2.69-windows32.exe|blender-2.69-windows32.exe|2.69|32
> sqlite> select count(*) from logs;
> 304113
> sqlite> select count(*) from logs where bits = 32;
> 101756
> sqlite> select count(*) from logs where bits = 64;
> 175647
>
> (bits = 0 is for unknown bit size)
>
> Anyway, for those who were maybe interested, have fun!
>
>
> Cheers,
>
> Dan McGrath
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Changes to Windows Compiler Support.

[Dan McGrath]

Hi,

> 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.

Out of curiosity, I parsed all of our download.blender.org logs since near
the end of 2014, right up until today and stored them in an sqlite3
database for people to check. You can download the file at:

  https://download.blender.org/ftp/dan/admin/blender_logs.sqlite.bz2

I specifically limited the list to 200 status files and only valid
filenames. The schema is:

sqlite> .schema
CREATE TABLE logs (log_date date NOT NULL, url text NOT NULL, filename text
NOT NULL, blender_version varchar(10) NULL, bits integer);
CREATE INDEX idx_bits on logs(bits);
CREATE INDEX idx_filename on logs(filename);
CREATE INDEX idx_url on logs(url);
sqlite> select * from logs limit 3;
26/Mar/2014|/release/Blender2.49b/blender-2.49b-windows.exe|blender-2.49b-windows.exe|2.49b|0
26/Mar/2014|/release/Blender2.70/blender-2.70-OSX_10.6-x86_64.zip|blender-2.70-OSX_10.6-x86_64.zip|2.70|64
26/Mar/2014|/release/Blender2.69/blender-2.69-windows32.exe|blender-2.69-windows32.exe|2.69|32
sqlite> select count(*) from logs;
304113
sqlite> select count(*) from logs where bits = 32;
101756
sqlite> select count(*) from logs where bits = 64;
175647

(bits = 0 is for unknown bit size)

Anyway, for those who were maybe interested, have fun!


Cheers,

Dan McGrath
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Changes to Windows Compiler Support.

[yul brynner]

Thanks very much to people who are doing windows libs maintenance! On my side, 
I see no pb to use VS 2017 instead of 2013 and use 64bits (I guess people who 
have old 32 bits computers could not use eevee anyway)
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Changes to Windows Compiler Support.

[Aaron Carlisle]

+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 
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"  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 
> 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
> > 

Re: [Bf-committers] Changes to Windows Compiler Support.

[Danrae Pray]

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"  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  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 

Re: [Bf-committers] Changes to Windows Compiler Support.

[Mike Erwin]

+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  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 

Re: [Bf-committers] Changes to Windows Compiler Support.

[Knapp]

As a users I have two comments about not supporting 32 bit.

First we are dropping Nvidia GTX 580 and older models of graphics cards so
why not 32 bit as well?

Second anyone that has an old computer can download an older version of
Blender. They are likely doing that anyway as a lot of Linux systems
dropped 32 bit support a long time ago.

https://itsfoss.com/end-of-32-bit-linux/

I would rather see the devs spending their time making Blender better than
working on very old 32 bit systems.

PS. I run a 64 bit system with a 580 GPU. I will have to update and I don't
like it but I would much rather have a great Blender than see it bogged
down with old tech. Naturally, I can only speak for myself.

Keep up the great work!


On Fri, Jan 26, 2018 at 6:51 PM, Ray Molenkamp  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] 

[Bf-committers] Changes to Windows Compiler Support.

[Ray Molenkamp]

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
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers