[Bf-committers] State of Visual Studio 201X... Warning: may contain chaotic content ...

Jürgen Herrmann shadowrom at me.com
Mon Feb 17 22:34:02 CET 2014


Hi Brecht,

You're right its a lot of work to maintain this...
Too bad AMP isn't available to other platforms than MS Windows.
It would make things easier for devs because AMP makes developing for different architectures quite straight forward.
No NVidia/ATI fuzz just code ;)
But I don't think it'll be adopted by other platforms in the near future so it's no option for us at all.
I'll stop working on VS 2012 portability and help with VS2013 then.

/Jürgen

> Am 17.02.2014 um 20:07 schrieb Brecht Van Lommel <brechtvanlommel at pandora.be>:
> 
> Hi,
> 
> I prefer the solution proposed by Martijn for now. It's a bit of a
> hassle for Windows developers to set it up, but not that many need to
> build with CUDA for typical development, and I don't think it will
> take that long for CUDA to support VS 2013. For best performance we
> need CUDA 5.0 anyway which doesn't work with VS 2012 either.
> 
> Porting Cycles to C++/AMP is not a realistic option I fear, it would
> be a lot of work to maintain and debug the particular issues with that
> platform. CUDA and OpenCL are already tricky and have their own
> issues, C++/AMP is going to be the same and end up being more work
> than the admittedly somewhat hacky option of installing an older
> compiler for CUDA.
> 
> Brecht.
> 
>> On Mon, Feb 17, 2014 at 7:38 PM, Jürgen Herrmann <shadowrom at me.com> wrote:
>> Hi Martijn,
>> 
>> that would do, but for how long? Will this workaround be reliable on Windows
>> 9 and later?
>> I am not a fan of workarounds like this one. It may work as expected, but
>> the future is uncertain.
>> I may be a bit paranoid on this because of some bad experience I made with
>> other projects in the past.
>> 
>> It requires multiple runtime libraries to be installed.
>> Developers will always have to keep older Platform SDKs installed on their
>> machines.
>> 
>> I would like a clean solution for this, blender is already complex enough ;)
>> 
>> /Jürgen
>> 
>> P.S.: Please don't take this as a personal attack against your efforts , I
>> really respect and appreciate the work you did on VS2013 support for
>> blender.
>> 
>> 
>> 
>> -----Ursprüngliche Nachricht-----
>> Von: bf-committers-bounces at blender.org
>> [mailto:bf-committers-bounces at blender.org] Im Auftrag von Martijn Berger
>> Gesendet: Montag, 17. Februar 2014 19:27
>> An: bf-blender developers
>> Betreff: Re: [Bf-committers] State of Visual Studio 201X... Warning: may
>> contain chaotic content ...
>> 
>> Hi Jürgen,
>> 
>> You can also use CUDA 5.0 with windows 7.1 SDK to build cubins and build
>> rest of blender with MSVC 2013.
>> The buildbot for MSVC 2013 already does this. I should add cmake support for
>> it and it is a work around but one that works very well and reliably for me.
>> 
>> Best Regards,
>> 
>> Martijn
>> 
>> 
>> 
>>> On Mon, Feb 17, 2014 at 6:54 PM, Jürgen Herrmann <shadowrom at me.com> wrote:
>>> 
>>> Hey there,
>>> 
>>> 
>>> 
>>> I had some time to look into blender code recently and found some
>>> disturbing problems with both VS2012 and VS 2013.
>>> 
>>> With Visual Studio 2013 released I would like to drop support for 2012
>>> and take the transition to VS 2013 directly because of the much better
>>> C99/C++11
>>> support.
>>> 
>>> I think we should bundle resources on one migration project instead of
>>> porting to two different versions of VC.
>>> 
>>> 
>>> 
>>> But (there is always a "But" ;):
>>> 
>>> 
>>> 
>>> Unfortunately Nvidia seems to be unable to release a Cuda toolkit with
>>> Compiler support for VC12. That's driving me crazy. Cuda 6 RC does not
>>> support VS2013 and I am not sure when they get this done.
>>> 
>>> IMHO there are multiple possibilities how to handle this:
>>> 
>>> 
>>> 
>>> 1.)    Port to MSVC 2013 and port Cycles' kernel to C++/AMP (I bet this
>> can
>>> be done)
>>> 
>>> a.       Pro: Makes us independent from NVidia Cuda and OpenCL fuzz
>>> 
>>> b.      Pro: Updates to VS are easier because we won't have to wait for
>>> NVidia
>>> 
>>> c.       Contra: Generates a lot of work (one time work load)
>>> 
>>> d.      Contra: Another Cycles kernel that has to be maintained
>>> 
>>> 2.)    Port to VS2012/Cuda 5.5 and postpone our effords on VS2013 until we
>>> get a working compiler from NVidia
>>> 
>>> a.       Pro: Majority of work is done, we'll just have to tie everything
>>> together and fix some problems
>>> 
>>> b.      Contra: We'll end up waiting for NVidia until we can make a
>>> transition to a newer VS version
>>> 
>>> c.       We may have to stick to this version of VS literally "forever"
>>> like
>>> we did with VS2008
>>> 
>>> 3.)    We stick to VS2008 / Cuda 5.0
>>> 
>>> a.       Pro: Nothing to do, just go on as is.
>>> 
>>> b.      Contra: No possibility to use newer technology
>>> 
>>> c.       Contra: Binaries might have compatibility issues with future
>>> versions of Windows (9+)
>>> 
>>> 4.)    Any other ideas?
>>> 
>>> 
>>> 
>>> I'd like to hear an official decision before I get started just to
>>> avoid a waste of resources and time.
>>> 
>>> 
>>> 
>>> Best regards,
>>> 
>>> 
>>> 
>>> Jürgen
>>> 
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>> 
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>> 
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers


More information about the Bf-committers mailing list