cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

riza_guntur
Journeyman III

BRT_PERMIT_READ_WRITE_ALIASING why not recommended?

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?

0 Likes
7 Replies

Riza,
Unlike the CPU, the GPU does not have a unified address space, so if you read and write to the same memory locaitions, you are not always gauranteed to have proper coherency. Now if you know enough about the underlying hardware where you can guarantee that your code will produce the expected results, then you can turn the flag on to remove this restriction.
0 Likes

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.

0 Likes

=operator doesn't copy the complete data from one stream to another. It is just a shallow copy with increase in ref count.

0 Likes

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.

0 Likes

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.

0 Likes

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?

0 Likes

Sorry, dunno why it produce so many blank line

0 Likes