[Bf-cycles] OpenCL on AMD GPUs
sergey.vfx at gmail.com
Mon Mar 2 20:21:02 CET 2015
All i know is there are assigned AMD developers to split the megakernel
and they're doing quite some progress. Exact status i'd prefer them to
report themselves and get all the honors of presenting the work :)
There're no actual issues with the megakernel nature of Cycles for CPU.
Brecht indeed didn't lay down the split-kernel infrastructure from the
beginning because of couple of reasons:
- It complicates the code, making development more difficult. That
complication is not something you want on the early days of your project.
- Such a kernel split now is relatively simple to do, but back in the days
with much less evolved OpenCL and CUDA that would have been quite a bit
It just happened so CUDA is still manages to compile the kernel (but it
does cause major PITA to maintain). Open standards is for sure something we
should support, and we're doing our best on that. Just sometimes it's a bit
more difficult than it sounds.. And wouldn't say Cycles wasn't written
incorrect, that was the only way to make it feature-complete by a one man
in that period of time.
Anyway,, now Cycles is almost feature complete and we can make kernel a bit
more complicated by splitting it, using fancy OpenCL 2 and other modern
technologies. No worries with that, split happen sooner than later. It'll
also help maintaining CUDA kernels as well, and maybe even help performance
P.S. OpenCL is supported on Intel GPUs as far as i concerned, and making it
official support is something we should consider doing as well.
On Mon, Mar 2, 2015 at 7:40 AM, Nazim Mer <nazim.mer at gmail.com> wrote:
> Hello Nirved and amd developers or anyone else thats set out to sort out
> blender cycles on amd gpus,
> is there any progress on your work, i really do hope this works out well
> as i am hoping to get an amd gpu soon.....
> Every thing i use at the moment uses open standards except cuda,
> the more features that use open standards i.e. opencl the better it is for
> the longevity of a feature as well as portability...?
> please enlighten us on the progress of cycles on amd gpus and its
> cycles should have been written correctly in the first place, now we face
> an issue where it suffers from some aspects of blender internal but is also
> better than internal.....a major oxymoron....!!!!!
> Nazim Mer
> Bf-cycles mailing list
> Bf-cycles at blender.org
With best regards, Sergey Sharybin
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bf-cycles