CLENQUEUEACQUIREGLOB(3clc)
π CLENQUEUEACQUIREGLOB π
okay bestie, welcome to the OpenCL Manual corner of the group chat, this one lives in section 3clc and it's literally the glow-up where your GL objects get handed over to OpenCL. sit down, hydrate, let's go π«Ά
β¨ NAME β¨
clEnqueueAcquireGLObjects β it snatches up OpenCL memory objects that were made from OpenGL objects, like, "mine now, thank u π
"
cl_int clEnqueueAcquireGLObjects(cl_command_queue command_queue,
cl_uint num_objects,
const cl_mem *mem_objects,
cl_uint num_events_in_wait_list,
const cl_event *event_wait_list,
cl_event *event);
π PARAMETERS π
command_queueβ a valid command-queue, no cap. every single device used to create the OpenCL context tied tocommand_queuehas to support acquiring shared CL/GL objects, and this is enforced at context creation time, so it's giving "caught in 4k, no sneaking past this" πnum_objectsβ how many memory objects you're acquiring inmem_objects. the headcount, basically.mem_objectsβ a pointer to a list of CL memory objects that correspond to GL objects. the roster of besties being handed over πevent_wait_list,num_events_in_wait_listβ these specify events that need to complete before this particular command can be executed. ifevent_wait_listisNULL, then this particular command does not wait on any event to complete. ifevent_wait_listisNULL,num_events_in_wait_listmust be0. ifevent_wait_listis notNULL, the list of events pointed to byevent_wait_listmust be valid andnum_events_in_wait_listmust be greater than0. the events specified inevent_wait_listact as synchronization points. lowkey they're the bouncers at the door πͺeventβ returns an event object that identifies this command and can be used to query or queue a wait for the command to complete.eventcan beNULL, in which case it will not be possible for the application to query the status of this command or queue a wait for this command to complete. if theevent_wait_listand theeventarguments are notNULL, theeventargument should not refer to an element of theevent_wait_listarray.
ok so here's the tea π΅ if thecl_khr_gl_sharing(3clc)extension is supported, and an OpenGL context is bound to the current thread, then any OpenGL commands which: - affect or access the contents of a memory object listed in themem_objectslist, and - were issued on that OpenGL context prior to the call toclEnqueueAcquireGLObjects.REwill complete before execution of any OpenCL commands following theclEnqueueAcquireGLObjectswhich affect or access any of those memory objects. if a non-NULLevent object is returned, it will report completion only after completion of such OpenGL commands. periodt β¨
πΈ DESCRIPTION πΈ
these objects need to be acquired before they can be used by any OpenCL commands queued to a command-queue. that's the whole vibe check right there.
the OpenGL objects are acquired by the OpenCL context associated with command_queue, and can therefore be used by all command-queues associated with the OpenCL context. it's not a private story, it's a group chat β everyone in that context gets access π
π¦ NOTES π¦
in order to ensure data integrity, the application is responsible for synchronizing access to shared CL/GL objects by their respective APIs. failure to provide such synchronization may result in race conditions and other undefined behavior including non-portability between implementations. not cute, not slay, do not do this π
prior to calling clEnqueueAcquireGLObjects, the application must ensure that any pending GL operations which access the objects specified in mem_objects have completed. this may be accomplished portably by issuing and waiting for completion of a glFinish command on all GL contexts with pending references to these objects. implementations may offer more efficient synchronization methods β for example on some platforms calling glFlush may be sufficient, or synchronization may be implicit within a thread, or there may be vendor-specific extensions that enable placing a fence in the GL command stream and waiting for completion of that fence in the CL command queue. but note that no synchronization methods other than glFinish are portable between OpenGL implementations at this time. so glFinish is the only one that travels well βοΈ
similarly, after calling clEnqueueReleaseGLObjects, the application is responsible for ensuring that any pending OpenCL operations which access the objects specified in mem_objects have completed prior to executing subsequent GL commands which reference these objects. this may be accomplished portably by calling clWaitForEvents(3clc) with the event object returned by clEnqueueReleaseGLObjects, or by calling clFinish(3clc). as above, some implementations may offer more efficient methods. the energy is very "you two have to actually talk to each other" π¬
the application is responsible for maintaining the proper order of operations if the CL and GL contexts are in separate threads. main character energy means knowing the order of operations, bestie.
if a GL context is bound to a thread other than the one in which clEnqueueReleaseGLObjects is called, changes to any of the objects in mem_objects may not be visible to that context without additional steps being taken by the application. for an OpenGL 3.1 (or later) context, the requirements are described in Appendix D ("Shared Objects and Multiple Contexts") of the OpenGL 3.1 Specification. for prior versions of OpenGL, the requirements are implementation-dependent. π
attempting to access the data store of an OpenGL object after it has been acquired by OpenCL and before it has been released will result in undefined behavior. similarly, attempting to access a shared CL/GL object from OpenCL before it has been acquired by the OpenCL command queue, or after it has been released, will result in undefined behavior. π do not. i am begging.
if the cl_khr_gl_event(3clc) extension is supported, then the OpenCL implementation will ensure that any such pending OpenGL operations are complete for an OpenGL context bound to the same thread as the OpenCL context. this is referred to as implicit synchronization. iconic behavior, honestly π
π₯ ERRORS π₯
returns CL_SUCCESS if the function is executed successfully. if num_objects is 0 and mem_objects is NULL the function does nothing and returns CL_SUCCESS. otherwise, it returns one of the following errors:
CL_INVALID_VALUEβ ifnum_objectsis zero andmem_objectsis not aNULLvalue or ifnum_objects>0andmem_objectsisNULL.CL_INVALID_MEM_OBJECTβ if memory objects inmem_objectsare not valid OpenCL memory objects.CL_INVALID_COMMAND_QUEUEβ ifcommand_queueis not a valid command-queue.CL_INVALID_CONTEXTβ if context associated withcommand_queuewas not created from an OpenGL context.CL_INVALID_GL_OBJECTβ if memory objects inmem_objectshave not been created from a GL object(s).CL_INVALID_EVENT_WAIT_LISTβ ifevent_wait_listisNULLandnum_events_in_wait_list>0, orevent_wait_listis notNULLandnum_events_in_wait_listis0, or if event objects inevent_wait_listare not valid events.CL_OUT_OF_RESOURCESβ if there is a failure to allocate resources required by the OpenCL implementation on the device.CL_OUT_OF_HOST_MEMORYβ if there is a failure to allocate resources required by the OpenCL implementation on the host.
β SPECIFICATION β
OpenCL Specification[1]
π SEE ALSO π
cl_khr_gl_sharing(3clc), clEnqueueReleaseGLObjects(3clc), cl_khr_gl_event(3clc)
π AUTHORS π
The Khronos Group
π COPYRIGHT π
Copyright Β© 2007-2011 The Khronos Group Inc.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and/or associated documentation files (the "Materials"), to deal in the Materials without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Materials, and to permit persons to whom the Materials are furnished to do so, subject to the condition that this copyright notice and permission notice shall be included in all copies or substantial portions of the Materials.
π NOTES π
- OpenCL Specification page 56, section 9.7.6 - Sharing memory objects that map to GL objects...
and that's the whole page, bestie!! this one's from The Khronos Group, dated 01/14/2021, and it's filed under the OpenCL Manual as CLENQUEUEACQUIREGLOB(3clc) β go acquire those objects, you absolute legend, i'm obsessed π«Άβ¨π
π¦ where this page comes from
- ubuntu jammy: opencl-1.2-man-doc 1.0~svn33624-5 Β· other
- ubuntu noble: opencl-1.2-man-doc 1.0~svn33624-5 Β· other
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms