Archives Discussions

[nberger]

Hi!
I gather from this forum that the release of the 1.0 version of the SDK is planned for April. Do you plan for any beta releases before then? On the Stanford Brook page there is a list of current issues with brook; these seem to persist in the alpha version of Brook+ - do you already know which of these will be addressed in the 1.0 release of Brook+?
I also a bug in the Brook+ compiler (is this the right place to report this?): Members of structs used for streams cannot be named x,y,z,w,a,b (and probably others), as this generates non-compiling code.

Thanks for any information

Nik

[michael_chu]

It is our intention to come out with a beta release of the SDK and that should be available in a week or 2 barring any major issues found during testing.

The Brook+ team is largely working to make sure the Brook+ infrastructure is more stable for v1.0. Are there particular issues or features you were particularly looking for? If so, let me know and I'll make sure they are brought to the Brook+ team's attention.

Let me check on the struct member naming for you and get it filed as an bug for you.

This forum (as well as streamdeveloper@amd.com) is the right place to ask questions and well as let us know about issues.

Thanks!

Michael.

[bayoumi]

Dear Michael,
when do you expect to release a Linux SDK?
Best Regards
Amr

[michael_chu]

I expect Linux support in v1.0 which is due out in April. There are some remaining driver support work being done targeted for that release time.

Michael.

[nberger]

Dear Michael!

Thanks a lot for the quick and comprehensive reply. I am looking forward to testing your next release. For my particular application it would be very helpful if I could use arrays as stream elements.
Cheers
Nik

[michael_chu]

Nik,

Just so I can check properly for you, do you have a code snippet of what you'd like to do? Would you like to pass in a pointer to the array elements?

Michael.

[nberger]

Hi Michael!
In my application, I have to perform a multiplication of two medium sized matrices (one of them constant) a few ten thousand times. The matrices are complex and hermitian, so the contents can be packed somewhat; they end up having a few dozen to a few hundred entries. The result is then a sum over elements, so I do not need an array in the output. As their size is determined at runtime, it would be extremely tedious to have a struct for every possible matrix size. So what I would like to do is something like
kernel matmult(float matrix1[]<>, float mattrix2[], int nelements, out float some_result){
...
}
If you know of a better way to implement this, I am very open for suggestions.
Ah, one more thing: It would be very nice if address virtualization would work without restrictions (reductions), so I do not have to care about the size of my arrays.

Cheers
Nik

[michael_chu]

I checked with engineering and they said, unfortunately, arrays as stream elements isn't currently supported. But I have added it to my features request list.

Let me pass your code on to internal engineering to see if they have ideas.

Michael.

[michael_chu]

By the way, do you already have sample C code that does this? I'm sure the engineers would like to browse over actual code so they can properly suggest something.

If you wanted to send the code just to me, use michael.chu@amd.com.

Thanks!

Michael.

[nberger]

Hi!
Unfortunately I do not have sample C code; there is an old implementation in Fortran, which worked quite differently, and I have a running RapidMind implementation, where I use random access to 2D arrays, one dimensin representing the "stream" and one the array elements. I suppose this would also be possible withhin brook+, the trouble (that I also have with RapidMind) is that the array size is limited and I have to do some paging. This is probably also the way I am going to implement this in brook until arrays become available.
Cheers

Nik