[Bf-committers] CUDA Toolkit Update (Windows + Linux)

[Martijn Berger]

Hi Thomas,

This is of course already taken care of ( the installing cuda part)
I experimented with the fatbin and I am not sure it is actually that
useful.. Adding a sm5x ptx and loading that if all else fails does seem
useful but that is not the same as fatbin.


Martijn


On Tue, Dec 2, 2014 at 10:20 AM, Thomas Dinges <blender at dingto.org> wrote:

> As 2.73 will be mainly a maintenance release, I would ask you to update
> the Toolkit on the Buildbots (Linux and Windows), so we can enable the
> sm_52 kernel.
> Further changes (like fatbin) can go to 2.74.
>
> I would appreciate it Sergey and Martijn. :)
>
> Thanks,
> Thomas
>
> Am 23.11.2014 um 08:42 schrieb Thomas Dinges <blender at dingto.org>:
>
> > Fixing SSS would of course be the best solution, but I think that is
> > more a long term project.
> > I think for now we should just build the extra sm_52 kernel. Although I
> > like your last suggestion as well (build fatbin and let users of sm5x
> > optimize themselves).
> >
> > Some further food for fought:
> > * We only support sm_20 and above (Geforce 400 series), which was
> > released in 2010. I think 4-8 GB RAM was pretty standard back then
> already.
> > * We could save some kernel compilation time for 32bit Blender, by
> > dropping CUDA support there. I don't think that GPU rendering + 32bit
> > environment is common. And again, we only have to look back to 2010.
> > 64bit CPUs + OS were common back then already.
> >
> > Am 20.11.2014 um 09:55 schrieb Sergey Sharybin:
> >> Technically it's easy. The only thing which is worrying is we'll have 12
> >> kernels to be compiled now.
> >>
> >> Just to mention, fatbin is not gonna to help really. The thing here is
> ptx
> >> is really fast to compile, it's optimization to a specific arch takes
> loads
> >> of ram and time, So if we ship ptx with just ptx that'd mean users would
> >> need to have 8 gig to be able to get optimized code (which then being
> >> cached btw). it's not that nice at all.
> >>
> >> We can also look into making SSS more or less stable on GPU, or just
> >> declare GPUs not being feature-full. CMJ i don't think would give any
> >> issues btw.
> >>
> >> Another idea could be optimizing sm_20-sm_35 in the fatbin, users of
> sm_50,
> >> sm_52 would optimize on first render. They probably have enough ram for
> >> this :) A bit cruel i know, just throwing ideas for brainstorm of how to
> >> improve the situation.
> >>
> >> P.S. i don't mean we shouldn't switch to fatbin, that'd help making
> blender
> >> users to early users of new GPUs.
> >>
> >> On Thu, Nov 20, 2014 at 3:41 AM, Thomas Dinges <blender at dingto.org>
> wrote:
> >>
> >>> Hey,
> >>> in order to support Geforce 9xx cards optimally, we should update the
> >>> CUDA Toolkit (Release & Buildbot) and compile native sm_52 kernels.
> >>>
> >>> Sergey, Martijn, can you please update the buildbots?
> >>> https://developer.nvidia.com/cuda-downloads-geforce-gtx9xx
> >>> This version is equal to the 6.5.14 we use atm, but adds support for
> >>> sm_52. So it should be a smooth and safe update.
> >>>
> >>> There is no version for Mac, but I think the 9xx cards are not
> available
> >>> yet for Mac anyway.
> >>>
> >>> Thanks,
> >>> Thomas
> >>> _______________________________________________
> >>> 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
>