[Bf-cycles] split kernel and CUDA - Bf-cycles Digest, Vol 61, Issue 9

[Brecht Van Lommel]

Hi Marc,

To be clear, the Cycles project only covers rendering. Physics
simulation and baking are separate Blender projects, share no code
with Cycles, and are currently CPU only.

Lots of improvements to GPU rendering are possible in Cycles, like:
* Splitting up the CUDA megakernel into smaller kernels as was done for OpenCL.
* Make the smaller OpenCL kernels support all CPU and CUDA features,
many are missing still.
* Better load balancing of the work, so that users don't manually have
to set big tile sizes to keep the GPU occupied, but automate this
somehow.
* Better balancing for multi-GPU rendering, which currently splits the
viewport up into fixed regions per GPU.
* Optimizations like using structure-of-arrays storage instead of
array-of-structures storage for some often used data structures.
* Out-of-core and paging support for rendering scenes bigger than GPU memory.

Of course these all require deep changes to the Cycles code. We're
happy to have people working on such topics, and if you're interested
in that we can discuss the specific about to best way to implement
these improvements. Or maybe you have other specific ideas to improve
things.

Certainly many users would be interested in having GPU acceleration
for the various physics systems in Blender as well. There's currently
many separate systems: cloth, particles, rigid bodies with bullet,
fluid and smoke (being replaced by mantaflow), all CPU only. These are
often lacking active developers to even improve the CPU implementation
though, and would ideally be unified more or replaced by a better
system.

If you have specific ideas there it's probably best to discuss them on
the bf-committers mailing list, since the relevant developers are not
necessarily reading this mailing list.

Regards,
Brecht.

On Thu, May 19, 2016 at 1:36 PM, Marc Binsted <marc at binsted.plus.com> wrote:
> Dear All,
>
> I first contacted Ton, mid-last year for advice on how to approach you
> guys with a project I am working on.
>
> I would be very interested in being involved with the development of
> Cycles, in particular for performance rendering and baking of physics
> and simulation systems within the GPU. I am currently developing a GPU
> based scalable cluster model for CGI to take advantage of many core
> processing, utilising Blender Cycles, Lux Render, Furry Ball and soon
> Octane, which has taken 18 months so far to research and build. I have
> been working on BVH building(QVBH and SVBH) and sorting algorithms,
> which could possibly be utilised with existing kernels. I have also
> experimented successfully with multi-GPU out-of-core memory and
> inter-GPU communication across PCIe and utilising various RDMA
> techniques, which can be developed as driver-aware with transparent
> operation under the cover however I have not been able to succesfully
> test through application recompiling as yet.
>
> I would like to see the benefits of efficient resource handling and,
> with full GPU utilisation, hence I would be interested to experiment
> with the simulation systems within Blender if anybody is developing GPU
> kernels for it via CUDA/OpenGL and also working with developers involved
> in the Cycles engine, with possible development of a micro-kernel
> library, or run-time compile for more efficient handling of the GPUs,
> scene geometry and work division, optimal tiling dimensions per
> architecture and improved memory handling for large scene files which
> will often defeat the GPU. I have been working with CUDA for a couple of
> years now, and have some knowledge of Nvidia Optix.
>
> I would also like to offer the potential access to the system for
> development, testing and trial renders. A further commercialised system
> will go online later in the year.
>
> I look forward to hearing from you.
>
> Kind regards,
>
> Marc Binsted
>
> On 19/05/2016 11:00, bf-cycles-request at blender.org wrote:
>> Re: split kernel and CUDA
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles