• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1Name
2
3    NV_draw_vulkan_image
4
5Name Strings
6
7    GL_NV_draw_vulkan_image
8
9Contributors
10
11    Jeff Bolz, NVIDIA Corporation
12
13Contact
14
15    Piers Daniell, NVIDIA Corporation (pdaniell 'at' nvidia.com)
16
17Status
18
19    Complete
20
21Version
22
23    Last Modified Date:         2/22/2017
24    NVIDIA Revision:            2
25
26Number
27
28    OpenGL Extension #501
29    OpenGL ES Extension #274
30
31Dependencies
32
33    This extension is written against the OpenGL 4.5 Specification
34    (Compatibility Profile).
35
36    This extension can also be used with OpenGL ES 3.2 or later.
37
38    This extension interacts with Vulkan 1.0 and requires the OpenGL
39    implementation to expose an implementation of Vulkan 1.0.
40
41Overview
42
43    This extension provides a new function, DrawVkImageNV(), allowing
44    applications to draw a screen-aligned rectangle displaying some or all of
45    the contents of a two-dimensional Vulkan VkImage.  Callers specify a
46    Vulkan VkImage handle, an optional OpenGL sampler object, window
47    coordinates of the rectangle to draw, and texture coordinates corresponding
48    to the corners of the rectangle.  For each fragment produced by the
49    rectangle, DrawVkImageNV  interpolates the texture coordinates, performs
50    a texture lookup, and uses the texture result as the fragment color.
51
52    No shaders are used by DrawVkImageNV; the results of the texture lookup
53    are used in lieu of a fragment shader output.  The fragments generated are
54    processed by all per-fragment operations.  In particular,
55    DrawVkImageNV() fully supports blending and multisampling.
56
57    In order to synchronize between Vulkan and OpenGL there are three other
58    functions provided; WaitVkSemaphoreNV(), SignalVkSemaphoreNV() and
59    SignalVkFenceNV().  These allow OpenGL to wait for Vulkan to complete work
60    and also Vulkan to wait for OpenGL to complete work.  Together OpenGL
61    and Vulkan can synchronize on the server without application
62    interation.
63
64    Finally the function GetVkProcAddrNV() is provided to allow the OpenGL
65    context to query the Vulkan entry points directly and avoid having to
66    load them through the typical Vulkan loader.
67
68New Procedures and Functions
69
70    void DrawVkImageNV(GLuint64 vkImage, GLuint sampler,
71                       GLfloat x0, GLfloat y0,
72                       GLfloat x1, GLfloat y1,
73                       GLfloat z,
74                       GLfloat s0, GLfloat t0,
75                       GLfloat s1, GLfloat t1);
76
77    VULKANPROCNV GetVkProcAddrNV(const GLchar *name);
78
79    void WaitVkSemaphoreNV (GLuint64 vkSemaphore);
80
81    void SignalVkSemaphoreNV (GLuint64 vkSemaphore);
82
83    void SignalVkFenceNV (GLuint64 vkFence);
84
85New Types
86
87    The Vulkan base entry point type from which all Vulkan functions pointers
88    can be cast is:
89
90        typedef void (APIENTRY *VULKANPROCNV)(void);
91
92    Note that this function pointer is defined as having the
93    same calling convention as the GL functions.
94
95New Tokens
96
97    None.
98
99Additions to Chapter 1 of the OpenGL 4.5 Specification (Introduction)
100
101    (Insert a new section after Section 1.3.6, OpenCL p. 7)
102
103    1.3.X Vulkan
104
105    Vulkan is a royalty-free, cross-platform explicit API for full-function
106    3D graphics and compute.  Designed for a complete range of platforms from
107    low-power mobile to high-performance desktop.
108
109    OpenGL can interoperate directly with Vulkan to take advantage of Vulkan's
110    explicit low-level access to the GPU for the power and performance
111    efficiencies it can offet.
112
113    An OpenGL application can use the following function to query the Vulkan
114    function entry points from within an OpenGL context:
115
116      VULKANPROCNV GetVkProcAddrNV(const GLchar *name);
117
118    <name> is the name of the Vulkan function, for example "vkCreateInstance"
119    and the return is a point to the Vulkan function address.  This allows
120    OpenGL applications that need to interoperate with Vulkan to query the
121    entry points directly and bypass the typical Vulkan loader.  The OpenGL
122    implementation provides access to the Vulkan implementation through this
123    mechanism.
124
125    The specification and more information about Vulkan can be found at
126    https://www.khronos.org/vulkan/
127
128
129Additions to Chapter 4 of the OpenGL 4.5 Specification (Event Model)
130
131    (Insert a new section after Section 4.1.3, Sync Object Queries p. 42)
132
133    4.1.X Synchronization between OpenGL and Vulkan
134
135    The command:
136
137      void WaitVkSemaphoreNV (GLuint64 vkSemaphore);
138
139    causes the GL server to block until the Vulkan VkSemaphore <vkSemaphore>
140    is signalled.  No GL commands after this command are executed by the server
141    until the semaphore is signaled.  <vkSemaphore> must be a valid Vulkan
142    VkSemaphore non-dispatchable handle otherwise the operation is undefined.
143
144    The command:
145
146      void SignalVkSemaphoreNV (GLuint64 vkSemaphore);
147
148    causes the GL server to signal the Vulkan VkSemaphore <vkSemaphore> when
149    it executes this command.  The semaphore is not signalled by GL until all
150    commands issued before this have completed execution on the GL server.
151    <vkSemaphore> must be a valid Vulkan VkSemaphore non-dispatchable handle
152    otherwise the operation is undefined.
153
154    The command:
155
156      void SignalVkFenceNV (GLuint64 vkFence);
157
158    causes the GL server to signal the Vulkan VkFence <vkFence> object when
159    it executes this command.  The fence is not signalled by the GL until all
160    commands issued before this have completed execution on the GL server.
161    <vkFence> must be a valid Vulkan VkFence non-dispatcable handle otherwise
162    the operation is undefined.
163
164Additions to Chapter 10 of the OpenGL 4.5 Specification (Vertex Specification
165and Drawing Commands)
166
167    Modify Section 10.9, Conditional Rendering, p. 420
168
169    (modify first paragraph to specify that DrawVkImageNV is affected by
170    conditional rendering) ... is false, all rendering commands between
171    BeginConditionalRender and the corresponding EndConditionalRender are
172    discarded.  In this case, Begin, End, ...and DrawVkImageNV (section 18.4.X)
173    have no effect.
174
175
176Additions to Chapter 14 of the OpenGL 4.5 Specification (Fixed-Function
177Primitive Assembly and Rasterization)
178
179    Modify Section 14.1, Discarding Primitives Before Rasterization, p. 527
180
181    (modify the end of the second paragraph) When enabled, RASTERIZER_DISCARD
182    also causes the [[compatibility profile only:  Accum, Bitmap, CopyPixels,
183    DrawPixels,]] Clear, ClearBuffer*, and DrawVkImageNV commands to be
184    ignored.
185
186Additions to Chapter 18 of the OpenGL 4.5 Specification (Drawing, Reading,
187and Copying Pixels)
188
189    (Insert new section after Section 18.4.1, Writing to the Stencil or
190    Depth/Stencil Buffers, p. 621)
191
192    Section 18.4.X, Drawing Textures
193
194    The command:
195
196      void DrawVkImageNV(GLuint64 vkImage, GLuint sampler,
197                         GLfloat x0, GLfloat y0,
198                         GLfloat x1, GLfloat y1,
199                         GLfloat z,
200                         GLfloat s0, GLfloat t0,
201                         GLfloat s1, GLfloat t1);
202
203    is used to draw a screen-aligned rectangle displaying a portion of the
204    contents of the Vulkan image <vkImage>.  The four corners of this
205    screen-aligned rectangle have the floating-point window coordinates
206    (<x0>,<y0>), (<x0>,<y1>), (<x1>,<y1>), and (<x1>,<y0>).  A fragment will
207    be generated for each pixel covered by the rectangle.  Coverage along the
208    edges of the rectangle will be determined according to polygon
209    rasterization rules.  If the framebuffer does not have a multisample
210    buffer, or if MULTISAMPLE is disabled, fragments will be generated
211    according to the polygon rasterization algorithm described in section
212    3.6.1.  Otherwise, fragments will be generated for the rectangle using the
213    multisample polygon rasterization algorithm described in section 3.6.6.
214    In either case, the set of fragments generated is not affected by other
215    state affecting polygon rasterization -- in particular, the CULL_FACE,
216    POLYGON_SMOOTH, and POLYGON_OFFSET_FILL enables and PolygonMode state have
217    no effect.  All fragments generated for the rectangle will have a Z window
218    coordinate of <z>.
219
220    The color associated with each fragment produced will be obtained by using
221    an interpolated source coordinate (s,t) to perform a lookup into <vkImage>
222    The (s,t) source coordinate for each fragment is interpolated over the
223    rectangle in the manner described in section 3.6.1, where the (s,t)
224    coordinates associated with the four corners of the rectangle are:
225
226      (<s0>, <t0>) for the corner at (<x0>, <y0>),
227      (<s1>, <t0>) for the corner at (<x1>, <y0>),
228      (<s1>, <t1>) for the corner at (<x1>, <y1>), and
229      (<s0>, <t1>) for the corner at (<x0>, <y1>).
230
231    The interpolated texture coordinate (s,t) is used to obtain a texture
232    color (Rs,Gs,Bs,As) from the <vkImage> using the process described in
233    section 3.9.  The sampler state used for the texture access will be taken
234    from the texture object <vkImage> if <sampler> is zero, or from the
235    sampler object given by <sampler> otherwise.  The filtered texel <tau> is
236    converted to an (Rb,Gb,Bb,Ab) vector according to table 3.25 and swizzled
237    as described in Section 3.9.16.  [[Core Profile Only:  The section
238    referenced here is present only in the compatibility profile; this
239    language should be changed to reference the relevant language in the core
240    profile.]]
241
242    The fragments produced by the rectangle are not processed by fragment
243    shaders [[Compatibility Profile:  or fixed-function texture, color sum, or
244    fog operations]].  These fragments are processed by all of the
245    per-fragment operations in section 4.1.  For the purposes of the scissor
246    test (section 4.1.2), the enable and scissor rectangle for the first
247    element in the array of scissor test enables and rectangles are used.
248
249    The error INVALID_VALUE is generated by DrawVkImageNV if <sampler> is
250    neither zero nor the name of a sampler object.  The error
251    INVALID_OPERATION is generated if the image type of <vkImage> is not
252    VK_IMAGE_TYPE_2D.
253
254
255Additions to the AGL/GLX/WGL Specifications
256
257    None.
258
259GLX Protocol
260
261    TBD
262
263Errors
264
265    INVALID_VALUE is generated by DrawVkImageNV if <sampler> is neither
266    zero nor the name of a sampler object.
267
268    INVALID_OPERATION is generated by DrawVkImageNV if the target of <vkImage>
269    is not VK_IMAGE_TYPE_2D.
270
271New State
272
273    None.
274
275
276New Implementation Dependent State
277
278    None.
279
280
281Issues
282
283    1) Can Vulkan entry points obtained through the typical Vulkan loader
284       be used to interoperate with OpenGL.
285
286       UNRESOLVED: Vulkan entry points obtained through the Vulkan loader may
287       introduce layers between the application and the Vulkan driver.  These
288       layers may modify the Vulkan non-dispatchable handles returned by the
289       Vulkan driver.  In that case, these handles will not functions correctly
290       when used with OpenGL interop.  It is therefore advised the Vulkan layers
291       are bypassed when doing OpenGL interop by getting them directly from
292       GetVkProcAddrNV().
293
294Revision History
295
296    Rev.    Date    Author    Changes
297    ----  --------  --------  -----------------------------------------
298     1    20160214  pdaniell  Initial draft
299     2    20170222  pdaniell  Registered extension
300