[Bf-cycles] Regarding the state of cycles OpenCL

[Brecht Van Lommel]

Hi Martijn,

I don't really agree with this, this is how it used to be before and I
intentionally added the environment variable. It discourages use of
the OpenCL backend because no end user should be using it, there's no
point, either it renders slower or it locks up their system trying to
compile the kernel. It doesn't really matter who is at fault, I do not
want to release and support a feature like that.

In my experience half-working features in the UI do not motivate
developers. You can get users tinkering with settings or reporting
issues but it doesn't lead to real progress. There's also already
plenty of discussion among users about OpenCL, what we need is
knowledgeable developers working to split up the kernel and
investigating OpenCL performance in Cycles, and working with
AMD/Apple/Intel to fix bugs in their drivers.


Maximum register count control is indeed something we need, I've asked
driver developers about implementing register spilling before but got
no clear answer. For now the main AMD/Apple issues have been internal
compiler errors that may or may not be related to this, if those are
solved we can worry about performance.

Brecht.

On Sun, Aug 11, 2013 at 11:48 AM, Martijn Berger
<martijn.berger at gmail.com> wrote:
> Currently OpenCL support is hidden behind an environment variable called
> ‘CYCLES_OPENCL_TEST’. I believe this should change for 2.69 for the
> following reasons.
>
>
> 1) It discourages use of the OpenCL backend. While it is true the experience
> of using opencl might be less good than using cuda on some platforms and
> fail totally on some others (AMD/ATI GPU’s) it is not Blender fault as much
> as it is the vendors providing not the best possible OpenCL support. Users
> actually complaining to them would help us.
>
>
> 2) It discourages development. If no one uses it no one cares and no one
> will invest time to keep OpenCL working or make it work more great.
>
>
> 3) It discourages industry backing the project. They could perceive the
> current state of our OpenCL support as not enabled or even non existent.
>
>
> All of this enforces the chicken - egg problem we are having with regards to
> OpenCL
>
>
> I would like to propose that we change this and enable OpenCL before
> releasing 2.69. Given how close we are to the blender 2.7x development
> changes and the special status that will give 2.69x the change should really
> happen this cycles to have any impact.
>
>
> Maybe we could add a warning in some cases for platforms where we know using
> it is not recommended.
>
>
> Further I think we should communicate very clearly with the vendors of GPU
> and GPU like platforms that we might need something like Nvidia’s
> maxrregcount setting as we do not want cycles complexity to eat up all to
> available registers and thereby decrease the amount of threads to much. For
> performance on those platforms we need a lot of threads even though that
> implies spilling and for the best performance we will most likely need to be
> able to influence how much threads we want to use.
>
>
> As a last point I would like to express how stunning it is to me that
> specifically AMD seems to have such a hard time getting these features in
> place. I think they need them to compete in the GPU space and they need to
> compete their to make the their APU strategy work.
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>