GDS support via extension would be pretty cool, and also many of the extensions mentioned in other posts. Myself, I'd rather see most of the issues fixed (properly announce support for cl_khr_fp16, console support —which seems to be underway already—, support for asynchronous copies and kernel execution even with profiling enabled, zero-copy on older hardware as others mentioned in this thread). Of course I wouldn't mind a few addition, such as an attribute to get the number of registers per CU in the cl_amd_device_attribute_query.
But I think most of these changes are in the driver, not the SDK. For the SDK, it's more about the tools and documentation. So I would assume the next APP SDK would include updated documentation (to the latest HW generation), examples for all the various supported extensions. Many of the tools are now available independently (sprofile, CodeXL), but still having a new baseline with the SDK would be a nice opportunity. And a clinfo that doesn't crash when 1.1 platforms are also present 8-)
Hi, i expect to been able to compile blender Cycles, now there's some problem with function calls or kernel size... or whatever that causes to run out of memory when trying to compile.
Blender cycles is being worked upon by AMD Engineers, for some time now. As of now i do not have any new information to give there, but you can probably check some other rendering engines like luxrender smalluxgpu that are reported to be working.
Thanks for your patience.
well, OpenCL implementation in cycles has been working with nvidia and intel since late ~2011, we're in june 2013 and amd is not able to compile the same code.
The lack of information and the time that has passed without a fix is provoking rumors like the impossibility of the actual amd hardware to compile complex kernels.
Is taking too long to solve this, and is not only affecting Blender but a lot of other complex programs that only could support nvidia and intel hardware due the lack of concern shown by amd in solving their opencl problems.
If it is a hardware limitation just say it and try to solve it in the next gen, but too much time has passed already too just say that Amd engineers are working on it.
P.S. Just don't say use another render that are reported to work cause if i follow your advice i could ended using another hardware that is reported to work next time.
The current 2.8 installer "abuses" /etc/profile by putting the AMDAPPSDKROOT variable and shared library path in there.
The Linux friendly way would be to put the environment variable in, e.g., /etc/profile.d/amdapp.sh and shared library path in /etc/ld.so.conf.d
For me, the most exiciting feature will be SPIR.
At my enterprise, our boss prohibited us to use OpenCL because we had to release the source code which is against our company's policy.... so we had to use CUDA.