cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

SDK 1.4 Feedback

Now that 1.4 has been released to the public, we would like feedback on it un order to further improve future releases of the SDK. we would appreciate your help in providing feedback in this thread so that the information does not get buried in other threads. Please make sure you label each item as a 'Feature Request', 'Bug Reports', 'Documentation' or 'Other'. As always, you can send an email to 'streamcomputing@amd.com' for general requests or 'streamdeveloper@amd.com' for development related requests.

If you wish to file a Feature Request, please include a description of the feature request and the part of the SDK that this request applies to.

If you wish to file a Bug Report, please include the hardware you are running on, operating system, SDK version, driver/catalyst version, and if possible either a detailed description on how to reproduce the problem or a test case. A test case is preferable as it can help reduce the time it takes to determine the cause of the issue.

If you wish to file a Documentation request, please specify the document, what you believe is in error or what you believe should be added and which SDK the document is from.

Thank you for your feedback.
AMD Stream Computing Team

0 Likes
115 Replies
Juro
Journeyman III

Other:

Does HD 4770:

1) work with the SDK1.4 ?

2) have double precision (FP64) support ?

0 Likes

The 4770 will get the official supported designation in June/July. It is really a matter of getting it made part of our testing matrix. Unofficially, I haven't heard any issues from our engineering team about it though.

It will have DPFP support and will be annotated (or rather not annotated since we only mark the cards without DPFP support) appropriately on the sys req page for the SDK.

Michael.

0 Likes

The 4770 will get the official supported designation in June/July. It is really a matter of getting it made part of our testing matrix. Unofficially, I haven't heard any issues from our engineering team about it though.

It will have DPFP support and will be annotated (or rather not annotated since we only mark the cards without DPFP support) appropriately on the sys req page for the SDK.

Michael.

0 Likes

The 4770 will get the official supported designation in June/July. It is really a matter of getting it made part of our testing matrix. Unofficially, I haven't heard any issues from our engineering team about it though.

It will have DPFP support and will be annotated (or rather not annotated since we only mark the cards without DPFP support) appropriately on the sys req page for the SDK.

Michael.

0 Likes

The 4770 will get the official supported designation in June/July. It is really a matter of getting it made part of our testing matrix. Unofficially, I haven't heard any issues from our engineering team about it though.

It will have DPFP support and will be annotated (or rather not annotated since we only mark the cards without DPFP support) appropriately on the sys req page for the SDK.

Michael.

0 Likes

The 4770 will get the official supported designation in June/July. It is really a matter of getting it made part of our testing matrix. Unofficially, I haven't heard any issues from our engineering team about it though.

It will have DPFP support and will be annotated (or rather not annotated since we only mark the cards without DPFP support) appropriately on the sys req page for the SDK.

Michael.

0 Likes

If I have code:

::brook::Stream<float>* divG;

which has some data and I want to make temp variable that has the same data. If I write

::brook::Stream<float> *temp=new ::brook::Stream<float>(*divG);

which I thought is a copy constructor, then I cant use this temp variable in a call like this:

calculate_and_add_divergence_gpu_ati(cols,rows,*Gx,*Gy,*temp,*divG)

where divG is output stream. The runtime reports the error: "Input stream is the same as the output stream."

I get the same error even after the code like this:

temp->assign(divG);

or

*temp=*divG;

If I could just get the dimension of divG I could make a temp variable like

::brook::Stream<float> *temp=new ::brook::Stream<float>(1,&dimension); And then use assign method.

Here is the kernel which I am calling:

kernel void calculate_and_add_divergence_gpu_ati(int cols,int rows,float Gx[],float Gy[],float temp<>, out float divG<>{
    float divGx, divGy;
    int idx=instance().x;
    int ky = idx % cols;
    int kx=idx-ky*cols;
   
    if(kx == 0)
        divGx = Gx[idx];
    else   
        divGx = Gx[idx] - Gx[idx-1];

    if(ky == 0)
        divGy = Gy[idx];
    else   
        divGy = Gy[idx] - Gy[idx - cols];           

    divG = temp + divGx + divGy;
}

So the simple method getDimensions of class Stream would be really nice.

Thank you for your support.

0 Likes
bamend
Journeyman III

Bug Report: brcc/brcc_d (Linux/Windows XP SP3) requires infinite time to compile the following program instead of reporting an compile error.

The Stream KernelAnalyzer reports "Error - Brook+ timed out whilst compiling.".

kernel float func(float i[][]) {
    int2 pos = instance().xy;
    return i[pos.y][pos.x];
}

kernel void func2(float i[][], out float o<>) {
    o = func(i);
}

0 Likes

Feature Request: making the counters more accessible, it doesn't make any sense at all that if one wants to use the counters that they have to recode every line of code from the sample

0 Likes
ztatsuch
Journeyman III

When can we use ati stream sdk with gcc-4.3 on X64-linux(ubuntu9.04/Fedora11/OpenSUSE11.*) or OpenSolaris ?

0 Likes

Documentation: Can we please have better documentation??? We've been asking for this for almost a year now and while it has gotten better, it's not where it needs to be by any extent.

0 Likes

Feature Request: 4x 4870x2 support under Linux.  2x 4870x2 works, but half my hardware is still sitting in boxes.  If I have to start 2 X servers with 2 cards each,  that would be ok, but presently fglrx only supports 1 X server.

Feature Request: CAL without X (like CUDA standalone module) for a GPU cluster.

 

0 Likes
hagen
Journeyman III

Feature request:

Not allowing for local arrays inside a kernel turns out to be a big problem for certain applications I am writing.  Are there plans to include local array creation in brook+ soon?  Or are there ways to circumvent this limitation?

0 Likes
kos
Journeyman III

Reachable from code AMD HLSL compiler, with IL on output, in SDK.

0 Likes
sorcerer
Journeyman III

fearure request: possibility to use without running X-server

having to configure X on a dedicated compute server makes things really messy; and if you accidentally use "ssh -X", you are wondering why things go wrong.

[Edit:]

Quoting from "Running ATI Stream Applications Remotely" (ATI Knowledge base):

"If your X server console is not the active console, your remote CAL applications wait for the X server to become active again."

You cannot really mean that serious?!

I'm currently planning to set up a GPU cluster for CFD computations, and that misfeature is definitely going to influence my decision which hardware I'm going to buy.

 

0 Likes

BUG

kernel void Generate_v_alt_full (out double v_alt<>, double orig_x[][], int aout_full[] )
{
    int2 ind = instance().xy;
    v_alt = orig_x[ind.y][aout_full[ind.x]];
}

Above compiles well

 

 

kernel void Generate_v_alt_full (out double v_alt<>, double orig_x[][], int aout_full[] )
{
    int2 ind = instance().xy;
    v_alt = orig_x[aout_full[ind.x]][ind.y];
}

Interchanging the indices spews a bunch of parser error

While processing <buffer>:176
In compiler at zzerror()[parser.y:112]
  message = syntax error

ERROR: Parse error. Invalid expression.
While processing <buffer>:176
In compiler at zzparse()[parser.y:301]
  (yyvsp[0]).ToString() = ")"
Aborting...
Problem with compiling brookgenfiles/misc_kernels_Copy_Stream_kv.hlsl
Error--:cal back end failed to compile kernel "Copy_Stream_kv"
NOTICE: Parse error
In compiler at zzerror()[parser.y:112]
  message = syntax error

ERROR: Parse error. Expected declaration.
In compiler at zzparse()[parser.y:198]
  (yyvsp[0]) = ")"

 

Declaring a temp variable for aout_full[ind.x] and substituting in the last kernel makes the parse errors go away.

 

SDK 1.4, Debian Unstable x64.

 

0 Likes

Better documentation,

easier multi-gpu API/automatic scalability over multiple GPU,

kernel call spooling on the hardware, so repetitive kernel call won't take time that long, for example:

for(int epoch = 0; epoch < num_of_epoch;epoch++)
    {
        for(int i = 0; i < (int) yB; i++)
        {
            Stream<float4> myu_min(rank[2], streamSizeMinOfVecCluster);
            Stream<float4> myu_max_of_min(rank[2], streamSizeMaxOfMin);
            myufy(i,fuzzy_number,vec_ref,myu)
            minimum_myu_cluster(myu,myu_min);
            max_of_min_myu(myu_min,myu_max_of_min);
        }
    }

0 Likes

My BIG WISH for 1.5 is global synchronizing threads

Becouse time of launching simple function on GPU via ATISTREAM is very big, ten times slower than launching function on GPU via CUDA

0 Likes

Becouse time of launching simple function on GPU via ATISTREAM is very big, ten times slower than launching function on GPU via CUDA


The main reason for this overhead is online compilation of generated IL in kernel call. On the other hand, nvcc directly generates GPU assembly and use it in kernel call.

A better support for offline compilation should be added in CAL.

0 Likes

Gaurav,
This is already possible in CAL with calImageRead and calclImageWrite. You can compile a IL program to a calImage and then write that image to a CALvoid buffer and then save it offline. The only issue is that we do not use a custom compilation step to do this and a seperate tool needs to be written that does this. The samples used to do this around version 0.9 or beta 1.0 of CAL.
0 Likes

Originally posted by: MicahVillmow Gaurav, This is already possible in CAL with calImageRead and calclImageWrite. You can compile a IL program to a calImage and then write that image to a CALvoid buffer and then save it offline. The only issue is that we do not use a custom compilation step to do this and a seperate tool needs to be written that does this. The samples used to do this around version 0.9 or beta 1.0 of CAL.


When it will be integrated with Brook+ compile step? I don't want to rewrite my code in CAL.

0 Likes

Originally posted by: MicahVillmow

Gaurav,

This is already possible in CAL with calImageRead and calclImageWrite. You can compile a IL program to a calImage and then write that image to a CALvoid buffer and then save it offline. The only issue is that we do not use a custom compilation step to do this and a seperate tool needs to be written that does this. The samples used to do this around version 0.9 or beta 1.0 of CAL.


Is it possible to use such form of ready kernels precaching combined with Brook+ sources?
Or this on-fly recompilation is unavoidable with Brook+ ?
(
It's very important cause I didn't see any kernel call shorter than ~0,4ms - it's huge time for computationally-intensive tasks...
)
0 Likes

multi mon and crossfire combined

get it fixed or else

0 Likes

Just wanted to report that with 1.4 SDK performance of BarsWF dropped by a factor of 2.5.

That means I gave up on this, and distributed version would support nVidia only.

 

That is really sad, because AMD cards showed much higher potential (up to 2.6 billions of hashes per second on 5870). nVidia needed at least 4 chips to get there.

0 Likes

Originally posted by: BarsMonster Just wanted to report that with 1.4 SDK performance of BarsWF dropped by a factor of 2.5.

 

That means I gave up on this, and distributed version would support nVidia only.

 

Which version were you using previously? Is it possible for you find out which part of the code is showing drop in performance? If you can point down 1 or 2 kernel, we can try to help you.

0 Likes

Originally posted by: gaurav.garg
Originally posted by: BarsMonster Just wanted to report that with 1.4 SDK performance of BarsWF dropped by a factor of 2.5.

 

 

 

That means I gave up on this, and distributed version would support nVidia only.

 

 

 

 

Which version were you using previously? Is it possible for you find out which part of the code is showing drop in performance? If you can point down 1 or 2 kernel, we can try to help you.

 

 

1.2 or 1.3... Do not remember, the one requiring Catalyst <=8.12.

I have the only kernel, and it's pretty huge, takes around 2 second for first launch (i.e. compilation), and then it runs for ~150ms (amount of work is variable to reach that timing). So it's not "1ms kernel speed" issue.

Probably need to downgrade display driver & SDK and compare CAL sources & doublecheck performance increase in older version.

0 Likes

Another option is to migrate it to OpenCL.

I've already did OpenCL migration for nVidia, and speed drop was under 5%.

If OpenCL in AMD would be not much worse, it might be the best bet option.

0 Likes

There are few things those are slower with Brook+ 1.3 or 1.4 SDK. If you can avoid those features, you can get much better performance.

1. Are you using stream re-size feature? i.e. Is there any size mis-match between sizes of your stream arguments of kernel?

2. Are you using domain operator?

3. Are you using scatter stream in your kernel?

Is it possible for you to post the kernel signature and the kernel call from host?

Also, the size of each stream passed to kernel?

0 Likes

Originally posted by: gaurav.garg There are few things those are slower with Brook+ 1.3 or 1.4 SDK. If you can avoid those features, you can get much better performance.

 

1. Are you using stream re-size feature? i.e. Is there any size mis-match between sizes of your stream arguments of kernel?

 

2. Are you using domain operator?

 

3. Are you using scatter stream in your kernel?

 

Is it possible for you to post the kernel signature and the kernel call from host?

 

Also, the size of each stream passed to kernel?

 

1) No

2) No

3) No

kernel void hello_brook_check(int k1, int k2, int k3, int k4, int len, int _ta, int _tb, int _tc, int _td, int charset[], int charset_len, out int output<> )

Launched as simple as

hello_brook_check(data->data_h[0], data->data_h[1],data->data_h[2],data->data_h[3],perm: : pwd_len8,g->hash_i[0],g->hash_i[1],g->hash_i[2],g->hash_i[3],data->charset[0], perm::charset_len,data->output[0]);

output stream size is 8000

charset size is ~80.

What kernel does is just calculating around 5*5'000 itterations of MD5 and comparing resulting hash with a target value (_ta,_tb,_tc,_td).

In the old version there was also 20 more input streams, but I optimized them away with almost no performance boost.

 

CPU-part(preparing workunit) is able to give out ~120 times more work, there were no changes in CPU part, so I doubt it was any slower.

 

0 Likes

Install previuos version of Brook on existing Catalyst and see if you get any performance improvement. It will help us to track down the issue to Brook+ changes or Catalyst changes.

0 Likes

Originally posted by: gaurav.garg Install previuos version of Brook on existing Catalyst and see if you get any performance improvement. It will help us to track down the issue to Brook+ changes or Catalyst changes.

 

 

Well, previous Brook+ required Catalist 8.12 or earlier (because that DLL renaming).

Some guys on my forum were able to hack newer drivers to work with older Brook, but I don't think it's realiable 🙂

0 Likes

I am not asking you to ship it as product, but to test it so that we can get the main cause of performace drop. You can rename aticalrt.dll and aticalcl.dll (available under Windows/system32 and windows/SysWow64 ) to amdcalrt.dll and amdcalcl.dll.

0 Likes

After looking in .il code I've realized that 2/3 of instructions are mov ones.
With that much registers on the card, I do not see how compiler might want to use move that often :-S

 

Ahh, it is supposed to be non-optimized, I see...

0 Likes

BarsMonster,
Please look at the ISA and not the IL as the underlying CAL compiler will optimize the unnecessary move instructions away.
0 Likes

Originally posted by: MicahVillmow BarsMonster, Please look at the ISA and not the IL as the underlying CAL compiler will optimize the unnecessary move instructions away.


Unfortunately I cannot check how ISA looks like, because Stream Kernel analizer causes brcc to crash (probably SKA is 1.3 and SDK is 1.4). Is there any other way of checking ISA code?

0 Likes
jfurtek
Journeyman III

The CAL sampler parameter extensions are documented in the Stream 2.0 Computing User Guide, but the function pointer types and relevant enumerations aren't in the cal_ext.h header file. (I checked the 1.4 and 2.0 Stream SDK releases, and neither one has the sampler extension info in cal_ext.h.)

The functions seem to be supported in the CAL libraries - if I add one to the last CALextid in the SDK header file cal_ext.h and call calExtGetProc() with "calCtxGetSamplerParams" or "calCtxSetSamplerParams", calExtGetProc() returns successfully. Calls to the returned function pointers seem to work as I would expect (although I've only tried Windows XP). So the fix might only require additions to the header files.

Jeremy Furtek

 

0 Likes