Thanks for your feedbacks - case closed !
1)Release and retain are for, as expected, releasing (decrement reference count) and retaining (increment reference count) memory objects. Each memory object has a reference count (i.e. number of processes, sub routines etc. that are using a memory object)..when the reference count is less than zero (or one less than when it was allocated, whatever the initial value) then the memory object can be assumed to be unused and the memory specificed by the mem object can be freed up. *I think this is how it works*
2)The API calls you are talking about are for both images and buffer objects - they are both memory objects (cl_mem) - for enqueueing mapped host memory space there are seperate calls for buffers and images memory types.
I don't really understand the question. The spec has creation and data movement functions that are different for images and buffers because in those cases it matters. Retain/release just do reference counting because those are much more generic and we don't care what type of memory object it is from an API point of view.
Referring to OpenCL specification page 20 http://www.khronos.org/registry/cl/specs/opencl-1.1.pdf
http://www.khronos.org/registry/cl/specs/opencl-1.1.pdfMemObjet class is depicted as abstrac class and its base class for
Buffer and Image classes which thereby inherit from MemObject.
My questions restated (sorry):
(1/3) Does user/programmer use MemObject class services ?
(2/3) Is it so that users either use Buffer or Image class servises ?
(3/3) Is it so that MemObject class is only for developers of Buffer and
Image class so that they can use the inheritance feature of C++ ?
Trying to be more specific in future,
I still don't really understand what you're asking.
That's not really subclassing, it's an "is-a" relationship - from which subclassing comes. When you write C++ class hierarchies you define inheritance around that is-a relationship. If this is implemented as C++ inheritance internally then that's the reason, rather than the API being defined to support inheritance.
Buffers and Images are memory objects. They are entities that sit in memory and they are the two ways to describe memory in OpenCL. Kernels are not memory, events are not memory, buffers and images are. That is all the diagram is really saying.
Thanks guys for your answers!
My question: what are your comments to the following two(2) cases:
Case #1 - using memory object API instead of buffer/image object API
"To get information that is common to all memory objects (buffer and image objects), one can use theclGetMemObjectInfo function described in section 5.4.3.The first paramater is cl_mem memobj specifying the memory object being queriedFunction returns CL_MEM_TYPE = CL_MEM_OBJECT_BUFFER/CL_MEM_OBJECT_IMAGE2D/CL_MEM_OBJECT_IMAGE3D"
i.e. having cl_mem memobj but NOT knowing which kind of memory objects it is ,you can use clGetMemObjectInfo to find its type (buffer/2D image/3D image)and then continue based on memory object type.
Case #2 - creating memory object without using buffer or image create function
"An OpenCL memory object created from an OpenGL object (hereinafter refered to as a “sharedCL/GL object”) remains valid as long as the corresponding GL object has not been deleted "
i.e. OpenGL is used to create memory objects
Note that OpenCL API does not specify create function for memory objects.
Can you just explain what you're trying to do???What is it your coding? Show us your code and it will help clear up the confusion because I don't think most people understand what you are specifically tring to accomplish...
What are your comments to the following two(2) cases?! Are you just conducting a survey or something? Asking things in such a round-about way often doesn't make sense, you need to state your purpose.
Why is it so important to know what type of memory object your working with when most likely you are the one who hase allocated/acquired it? explain. Why are you concerned about GL shared memory objects when your're not using GL interop? This makes no sense whatsoever
Which AMD APP SDK version do I need to use clGetMemObjectInfo function in my programs - the latest v2.5 ?
What AMD GPU cards support clGetMemObjectInfo - only those which also support image objects ?
~ trying to program a function
~ function calls clGetMemObjectInfo to find out objects type (buffer/2Dimage/3Dimage) - object is passed as parameter
~ function has not allocated/acquired object - its caller has done that
~ I'm not concerned about GL shared memory objects - they just offer one way to create memory objects
Thanks for your answers !
There seem to be real and useful functions for memory objects (although
the class was depicted as abstract class) to be used in my programs!
Which software and hardware version from AMD support clGetMemObjectInfo function?
Originally posted by: dragonxi4amd 2) if memory objects are either image or buffer objects, why is API specified for memory objects ?
2) if memory objects are either image or buffer objects, why is API specified for memory objects ?
I've never used image buffers...anyway, IIRC image buffers are convenient when you need to exploit some sort of spatial locality that characterizes data in them (in fact these type buffers are useful when treating images, hence their name) because this data is accessed through ad-hoc tiled access patterns, which are different from the linear ones used with regular buffers.
That's why you have different functions for the management of different buffer types.
Retrieving data ...