Objects that may be shared between contexts include buffer objects, program
and shader objects, renderbuffer objects, sampler objects, sync objects, and texture
objects (except for the texture objects named zero).
Objects which contain references to other objects include framebuffer, program
pipeline, query, transform feedback, and vertex array objects. Such objects are
called container objects and are not shared.
Implementations may allow sharing between contexts implementing different
OpenGL versions or different profiles of the same OpenGL version (see appendix
D). However, implementation-dependent behavior may result when aspects
and/or behaviors of such shared objects do not apply to, and/or are not described
by more than one version or profile.
5.1.2 Automatic Unbinding of Deleted Objects
When a buffer, texture, or renderbuffer object is deleted, it is unbound from any
bind points it is bound to in the current context, and detached from any attachments
of container objects that are bound to the current context, as described for Delete-
Buffers, DeleteTextures, and DeleteRenderbuffers. If the object binding was
established with other related state (such as a buffer range in BindBufferRange
or selected level and layer information in FramebufferTexture or BindImage-
Texture), that state is not affected by the automatic unbind. Bind points in other
contexts are not affected.
Attachments to unbound container objects, such as deletion
of a buffer attached to a vertex array object which is not bound to the context,
are not affected and continue to act as references on the deleted object, as described
in the following section.
5.3.1 Determining Completion of Changes to an object
The contents of an object T are considered to have been changed once a commandsuch as described in section 5.3 has completed. Completion of a command 1 may
be determined either by calling Finish, or by calling FenceSync and executing a
WaitSync command on the associated sync object. The second method does not
require a round trip to the GL server and may be more efficient, particularly when
changes to T in one context must be known to have completed before executing
commands dependent on those changes in another context.
5.3.2 Definitions
In the remainder of this section, the following terminology is used:
An object T is directly attached to the current context if it has been bound to
one of the context binding points. Examples include but are not limited to
bound textures, bound framebuffers, bound vertex arrays, and current programs.
T is indirectly attached to the current context if it is attached to another object
C, referred to as a container object, and C is itself directly or indirectly
attached. Examples include but are not limited to renderbuffers or textures
attached to framebuffers; buffers attached to vertex arrays; and shaders attached
to programs.
An object T which is directly attached to the current context may be reattached
by re-binding T at the same bind point. An object T which is indirectly
attached to the current context may be re-attached by re-attaching the
container object C to which T is attached.
Corollary: re-binding C to the current context re-attaches C and its hierarchy
of contained objects.
5.3.3 Rules
The following rules must be obeyed by all GL implementations:
Rule 1 If the contents of an object T are changed in the current context while T is
directly or indirectly attached, then all operations on T will use the new contents
in the current context.
Note: The intent of this rule is to address changes in a single context only. The
multi-context case is handled by the other rules.
Note: “Updates” via rendering or transform feedback are treated consistently
with update via GL commands. Once EndTransformFeedback has been issued,
any subsequent command in the same context that uses the results of the transform
feedback operation will see the results. If a feedback loop is setup between
rendering and transform feedback (see section 13.2.3), results will be undefined.
Rule 2 While a container object C is bound, any changes made to the contents of
C’s attachments in the current context are guaranteed to be seen. To guarantee seeing
changes made in another context to objects attached to C, such changes must be
completed in that other context (see section 5.3.1) prior to C being bound. Changes
made in another context but not determined to have completed as described in section
5.3.1, or after C is bound in the current context, are not guaranteed to be
seen.
Rule 3 Changes to the contents of shared objects are not automatically propagated
between contexts. If the contents of a shared object T are changed in a
context other than the current context, and T is already directly or indirectly attached
to the current context, any operations on the current context involving T via
those attachments are not guaranteed to use its new contents.
Rule 4 If the contents of an object T are changed in a context other than the current
context, T must be attached or re-attached to at least one binding point in the
current context, or at least one attachment point of a currently bound container
object C, in order to guarantee that the new contents of T are visible in the current
context.
Note: “Attached or re-attached” means either attaching an object to a binding
point it wasn’t already attached to, or attaching an object again to a binding point
it was already attached.Example: If a texture image is bound to multiple texture bind points and the
texture is changed in another context, re-binding the texture at any one of the texture
bind points is sufficient to cause the changes to be visible at all texture bind
points.
一句話：先同步/完成，再綁定