Closed dPavelDev closed 8 years ago
IMHO, it's worth considering. However, that would require buffer_value<T>
class to store command_queue
object.
If we don't want to store command_queue
object in vector
(and other containers), then we can at least provide at()
method which takes command_queue
as its 2nd argument. That would also be simpler and introduce less changes to containers.
If we don't want to store command_queue object in vector (and other containers), then we can at least provide at() method which takes command_queue as its 2nd argument.
It's rather good idea for getting value but how to set value? Operator = uses own command queue
It's easy. Method at()
does not return reference to the value itself but rather a buffer_value<T>
object that wraps that value. If we modify buffer_value<T>
to store command_queue
object then here we can use that queue instead of making a new one.
And just because I'm curious: Can you tell me where you use such a small array in GPU computing? I mean, in most cases operator[]
is not even needed since in GPGPU you operate on rather large sets of data, not single values.
Yes, you're right, operator[] needs rarely. For example, I have change only one value. When I build BVH-tree on GPU using my own algorithm, tree root value (only tree root) has undefined value. There are two ways: write kernel to modify only the one value or change this from host.
OK, thanks. I've just remembered, you can always do this:
compute::array<int_> a(context);
(a.begin() + 7).write(6, queue)
Read and write members with custom queue in buffer_iterator. Excellent! But nothing about it in documentation.
When I have to get/set some values from some index from vector using custom queue, I forced to use compute::copy function, not [] or at members. I can't use convenient methods to access elements!
I think, it is necessary to provide method "set_default_queue(queue)" and public method get_default_queue() for all containers.
Also, is it right to wright code similar to?