Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

Adept II

Any time schedule about next APP SDK (v2.9?) ?


Is there any time schedule about the next APP SDK version? It's been about 6 months since the previous version was released.

Thank you.

23 Replies

Plans are underway...But, What are you expecting from 2.9? Can you talk a bit more on your expectation?


Although I am not in direct need of the feature, SPIR support is not yet implemented in 2.8 if I'm not mistaken. During little mailing with Clang dev working on the C++AMP prototype inside the Clang compiler asked me whether I knew any platform that implemented SPIR compilation yet. As of now he implemented NVPTX frontend, but naturally SPIR would be better. (Since NV is not expected to implement SPIR compilation anytime soon, I'd expect both intermediates to be stored inside the binary for portability.)


Hi I expect to AMD to support all new OCL 1.2 extensions anounced late last year specially graphics ones (please at least can you gather expected ETA on graphics ones and what ones are going to be implemented?)




please provide this ones!

other interesting one:


and security ones would be good:



+1 cl_khr_gl_depth_images

A very long time ago someone tried to acquire depth buffers and failed to. I figured something like this would surely be solved in a matter of years. Now I see this feature is actually an OpenCL 1.2 extension. Since I'm about to implement Object Distributed Render, and I will need Z-composition roughly 3 weeks from now, if this feature would make it, that would rock. (I know if things go wrong I could always implement it in pixel shaders, but hey... since it's an interop app anyway...


maybe relevant what to expect in next release


I would expect console support under linux without root (although this might be a GPU driver issue), linux zero copy support for older than GCN GPUs (am I expecting too much?) and an updated reference manual (covering Sea Islands changes).

ekondis, All these are really from the driver side. Not really from APP SDK.

As far as manual update for sea islands -- I will fwd your request.

Console support -- Driver team is already working on it.

Linux zero-copy suppor for non-GCN } - Do you mean to say windows supports and Linux does not? Can you elaborate?


read the programing guide table 4.2. CL_MEM_USE_PERSISTENT_MEM_AMD flag is supported on Windows Vista/7. On Linux only Southern Islands. Also driver version doesn't contain VM which AFAIK indicate zero copy support. and when we are at difference between Linux and Windows it will be nice if we could use whole VRAM on Linux as currently it is still limited to 50%.

Regarding "zero-copy support" I mean what nou posted.


I would also like to add exposing the GDS (global data store) as an OpenCL extension.

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-)

>And a clinfo that doesn't crash when 1.1 platforms are also present 8-)

The ones in the beta drivers (3.6?) works.


Thanks for the update. It should be fixed in the next APP SDK as well


If non-root console GPU support is really implemented in the next driver version, I wouldn't mind some tool to see/control the state of the GPUs, possibly soft-reset them without a hard reboot in case of lock-up (e.g. infinite loop due to bad coding), etc (iow, something similar to the nvidia-smi tool that nvidia provides for their cards).


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.


Hi h.g.,

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/ and shared library path in /etc/


Thanks for the suggestion.


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.

SPIR is being taken by AMD as per priority. Thanks for your interest in it

Adept II

Although a minor upgrade of the SDK was recently introduced (v. 2.8.1), the core documentation (AMD Accelerated Parallel Processing OpenCL Programming Guide) has not yet been updated (v2.8).


Thanks for the reminder. It will be updated soon