[Bf-cycles] OpenCL on AMD GPUs
nazim.mer at gmail.com
Tue Mar 3 00:17:44 CET 2015
i apreciate the reply, and the efforts all developers are putting into the cycles renderer, i did overlook the concept where you think about functions and features first and refactoring last...... i remember the days when alot of poeple were dissing brecht for being bias towards cuda,.....i guess that when more progress is educated to the masses all critisim would be put at rest.......i.e. amd dishing out empty promises.....
I hope that the code behind amd drivers and software become viewable to the public but closed to external developers and that they listen to there users through forums and other social media.... along this note the first graphics vender to endorce this...would be welcome to my hard earned cash....(A MAN CAN ONLY DWEAM!!!!!!!)
Good luck to healthy competition as when this finally happens amd would finally and truly beable to compete with nvidia....their opencl which is the only gpu utilisation api for them is the closest and probably the only competitor to cuda
Sent from myMail app for Android
Monday, 02 March 2015, 07:21PM +00:00 from Sergey Sharybin <sergey.vfx at gmail.com>:
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 more tricky.
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 on CPU.
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 developements.....
>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....!!!!!
>Bf-cycles mailing list
>Bf-cycles at blender.org
With best regards, Sergey Sharybin
Bf-cycles mailing list
Bf-cycles at blender.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bf-cycles