Like the explanation given:
• The runtime enforces the rule given in the Brook+ language specification that makes it illegal to bind
the same stream for both reading and writing. For compatibility with existing code, this type of aliasing
is permitted if the environment variable BRT_PERMIT_READ_WRITE_ALIASING is defined.
• We do not recommend this for new code because unpredictable results can occur without a detailed
understanding of the underlying hardware architecture.
o The maximum size of a stream is 2
26
elements.
Is there any detailed explanation?
Okay, let's see.
If I do something like this:
Stream<float4> vec_ref_next = *vec_ref;
then do
calc_vec_ref_next(row, alpha, winner, *fuzzy_number, *vec_ref,vec_ref_next);
Where *vec_ref is input and vec_ref_next is output, will it give correct result?
(So far it is correct)
I read streamSwap in Brook+ 1.4.1 uses
Stream<float4> vec_ref_next = *vec_ref;
to copy to temporary stream. Then I tried it, then there is a warning about BRT_PERMIT_READ_WRITE_ALIASING but the results are correct up to now.
=operator doesn't copy the complete data from one stream to another. It is just a shallow copy with increase in ref count.
What do you mean by shallow copy? What is that ref count? Any tricks to solve this? I don't really want to update whole stream, just a row in *vec_ref specified in winner.
Shallow copy means rather than copying complete GPU buffer, Brook+ just point the same GPU buffer to both the streams.
Using BRT_PERMIT_READ_WRITE_ALIASING should not be a problem if you are not using gather/scatter streams.
I see
kernel void calc_vec_ref_next( int row, float a, float4 winner[][], float4 input_fuzzy_numbers[][], out float4 vec_ref<>)
Will it be a problem if I do read and write to vec_ref?
The gather stream is winner and input_fuzzy_numbers right?
Sorry, dunno why it produce so many blank line