Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!

Filling opencl buffer/image with zeros

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
2 replies to this topic

#1 zerorepent   Members   -  Reputation: 663


Posted 20 March 2013 - 03:33 AM


What is the way to fill a opencl buffer (or texture) with zeros? 


cl_int errorCode;
float arg = 0; //or a larger datastructure/type
errorCode = m_Queue->enqueueFillBuffer<float>(destinationBuffer,arg,0,size,NULL,0);

This operation seems really wasteful, but maybe I'm wrong? Is it perhaps better to use map/unmap and memset with zeros?  


For example I want to create a buffer of size x, fill it with z amounts of data (z<x) and fill the rest of the buffer with zeros. Is the only option then to first write z data, and then do a fill-function call like the one above with an offset? Is it possible to intialize a buffer filled with zeros. Googling only seem to result in information about zero-copy memory (which is interesting in itself, but not what I'm looking for). 


#2 Bacterius   Crossbones+   -  Reputation: 10309


Posted 20 March 2013 - 04:46 AM

What do you mean by wasteful? the enqueueFillBuffer functions are really self-documenting, they are meant to be used to fill buffers. Mapping and unmapping is another option, but the problem is that your memory usage spikes up if your buffer is large, unless you do it in small increments in which case you end up calling the API a lot which can also hurt (and isn't very elegant).


Of course, it's only available under OpenCL 1.2, so if that's the only 1.2 feature you're using it might make more sense to use a less modern approach and just implement the fill function yourself (it's actually not too hard, just enqueueWriteBuffer the given pattern over the entire buffer, just remember to use CL_FALSE for non-blocking writes, for the love of god).


Another option is to write a kernel designed to set buffers to zero, which might actually win out to every other approach bar zero-copy memory for large buffers on hardware devices (like GPU's) but this is very inelegant and tedious in terms of implementation. Though I'm not exactly sure how the enqueueFillBuffer is implemented, perhaps it uses that under the hood when appropriate.


Also, don't make the mistake I did. Don't foolishly memset an array of floats to zero. When I did that, it set them all to NaN in the OpenCL kernel for some reason sad.png

Edited by Bacterius, 20 March 2013 - 04:50 AM.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.


- Pessimal Algorithms and Simplexity Analysis

#3 zerorepent   Members   -  Reputation: 663


Posted 20 March 2013 - 05:08 AM

wasteful might have been a poor choice of words, but what I mean is that since I'm not using complex pattern, i.e. just filling with zero using fill seems a bit overkill.

The Buffer sizes is in ranges between ~64KB and ~128MB. Using a small pattern a float seems to be rather inefficient because even if it zero:ed it still need to do size/4 memcopies. Thats why I thought maybe using unmap/map and memset might be faster, I guess my best option is to time it and compare. (or something similar to that)

Edited by zerorepent, 20 March 2013 - 05:09 AM.

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.