cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

ryta1203
Journeyman III

break in _k->map()?

void mcollid(float4 F1to4[], float4 F5to8[], float4 F9[], float4 f1to4[], float4 f5to8[], float4 f9[], float s[], float GEO[], float G, int gx, int gy,
int e[], int r[], int mx, int my, int bk)
{
int size = gx*gy;
float4 Fs1to4_1< size>;
float4 Fs1to4_2< size>;
float4 Fs5to8_1< size>;
float4 Fs5to8_2< size>;
float4 Fs9_1< size>;
float4 Fs9_2< size>;

float4 fs1to4_1< size>;
float4 fs5to8_1< size>;
float4 fs9_1< size>;
float GEOs< size>;
float ss< 9>;

streamRead(fs1to4_1, f1to4);
streamRead(fs5to8_1, f5to8);
streamRead(fs9_1, f9);
streamRead(Fs1to4_1, F1to4);
streamRead(Fs5to8_1, F5to8);
streamRead(Fs9_1, F9);
streamRead(ss, s);
streamRead(GEOs, GEO);
mcollid_s(Fs1to4_1, Fs5to8_1, Fs9_1, fs1to4_1, fs5to8_1, fs9_1, GEOs, ss, G, Fs9_2, Fs5to8_2, Fs1to4_2);
streamWrite(Fs9_2, F9);
streamWrite(Fs1to4_2, F1to4);
streamWrite(Fs5to8_2, F5to8);
}

This crashes. All the arrays are the same size as the streams. I don't know if this occurred in a previous SDK since I was using the same variable for input and output, aka: Fs1to4_1 was Fs1to4 and Fs1to4_2 was Fs1to4 also, any ideas?

This works for the first iteration but crashes on the second. Also, I tried this with other kernels that do the same thing and I get the same error so I don't think it's the kernels (also, both kernels were working in previous SDK but to avoid "unpredictable results" I am now trying it this way, even though it was working before).
0 Likes
7 Replies
jean-claude
Journeyman III

1) Did you try to enable the logging flag in order to get in debug mode the BROOK_RT_LOG file, you should have more hints.

2)what about running it for a while (check purpose) in CPU mode ?

Having said so I suspect too a k_map() bug related to the overall numberof input streams as I reported in :

http://forums.amd.com/devforum/messageview.cfm?catid=328&threadid=101210&enterthread=y

0 Likes

Jean,

1. I have not enabled the log file, but it runs fine if BRT_RUNTIME=CPU not that that means much since the differences are not documented anywhere.
2. Can someone from AMD confirm whether or not this is indeed a bug?

It still seems like AMD is unconcerned with doing anything with Brook+, maybe they are phasing it out, I don't know. Meanwhile, CAL is simply not practical for writing from scratch unless your kernel(s) is uber-simple. My code uses 6 long/complex kernels, CAL is not an option for me.

AMD, any thoughts?
0 Likes

Tried running a similar kernel on Vista32, the program simply collapses,

Entering into windows debug mode, apparently the incriminated code is at :

22D7417D  call        std::vector<brook:esc::gpu_technique_desc,std::allocator<brook:esc::gpu_technique_desc> >::~vector<brook:esc::gpu_technique_desc,std::allocator<brook:esc::gpu_technique_desc> > (22D611FEh)

Well, sounds like a bug !!

0 Likes

If you can email a test case that shows this issue to streamdeveloper@amd.com then we can have an engineer look at it and see what is going on here.

Thanks,
0 Likes

Hi Micah,

I'm doing it strait away, you'll get the file mailed in a few minutes.

Thanks for your support.

Could you please have a look too at :

http://forums.amd.com/devforum/messageview.cfm?catid=328&threadid=101074&enterthread=y

Thanks

Jean-Claude

0 Likes

Thanks for the bug report. This has been reported to the correct engineers.
0 Likes
nberger
Adept I

Hi!
I also see this bug and it keeps me from using the 1.2 SDK. If you come up with any workaround or patch, please let me know ASAP; I do not mind recompiling the runtime or brcc. Thanks a lot
Nik
0 Likes