• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1Name
2
3    EXT_framebuffer_multisample_blit_scaled
4
5Name Strings
6
7    GL_EXT_framebuffer_multisample_blit_scaled
8
9Contact
10
11    Gareth Hughes, NVIDIA Corporation (gareth 'at' nvidia.com)
12
13Contributors
14
15    Jeff Bolz, NVIDIA
16    Pat Brown, NVIDIA
17    Alex Eddy, Apple
18    Gareth Hughes, NVIDIA
19    Eric Werness, NVIDIA
20
21Status
22
23    Complete.
24
25Version
26
27    Last Modified Date:         07/05/11
28    Revision:                   8
29
30Number
31
32    409
33
34Dependencies
35
36    ARB_framebuffer_object is required.
37
38    Written based on the wording of the OpenGL 2.1 specification.
39
40
41Overview
42
43    This extension relaxes some of the restrictions associated with
44    multisample resolve operations, specifically to allow a combined
45    resolve and scale operation through a single call to BlitFramebuffer.
46    It also adds two new filter types to control the quality of the
47    combined scaled resolve operation.
48
49    In traditional multisampled framebuffer rendering, color samples
50    must be explicitly resolved via BlitFramebuffer before any other
51    operation on the resulting pixel values can be performed.  This
52    multisample resolve operation must be done using a BlitFramebuffer
53    call where the dimensions of the source and destination rectangles
54    are identical.  If the resulting pixel values need to be copied to a
55    texture with different dimensions, these resolved values can then be
56    scaled with a second call to BlitFramebuffer.
57
58    By requiring two separate calls to BlitFramebuffer, the quality
59    of final image can be maintained to a certain degree.  The samples
60    are first resolved, and then these resolved values can be filtered
61    to produce the final image.  This image quality comes at the price
62    of increased memory usage and lower performance.  However, the
63    scaling blit can still introduce artifacts, particularly if it is
64    done with a simple bilinear filter.
65
66    The new filter types introduced by this extension allow the scaled
67    resolve to be done with a single call to BlitFramebuffer.  Not all
68    samples from the read framebuffer are required to be be used when
69    producing the final pixel values, and there may be a loss in quality
70    when compared to an image produced by a separate resolve and scale.
71    However, the single-pass scaled resolve blit should be faster than
72    the traditional two-pass resolve then scale blits.
73
74
75New Procedures and Functions
76
77    None.
78
79
80New Types
81
82    None.
83
84
85New Tokens
86
87    Accepted by the <filter> parameter of BlitFramebuffer:
88
89      SCALED_RESOLVE_FASTEST_EXT                        0x90BA
90      SCALED_RESOLVE_NICEST_EXT                         0x90BB
91
92
93Additions to Chapter 4 of the OpenGL 2.1 Specification (Per-Fragment
94Operations and the Frame Buffer)
95
96    In section 4.3.3 "Copying Pixels", modify the fifth paragraph
97    describing BlitFramebuffer as follows:
98
99    "If the source and destination rectangle dimensions do not match,
100    the source image is stretched to fit the rectangle.  <filter> must
101    be LINEAR, NEAREST, SCALED_RESOLVE_FASTEST_EXT or
102    SCALED_RESOLVE_NICEST_EXT and specifies the method of interpolation
103    to be applied if the image is stretched.  LINEAR,
104    SCALED_RESOLVE_FASTEST_EXT or SCALED_RESOLVE_NICEST_EXT filtering is
105    allowed only for the color buffer; if ..."
106
107    Modify the following text in section 4.3.3 "Copying Pixels" that was
108    added by ARB_framebuffer_object:
109
110    "If SAMPLE_BUFFERS for the read framebuffer is greater than zero,
111    SAMPLE_BUFFERS for the draw framebuffer is zero and the dimensions
112    of the source and destination rectangles provided to
113    BlitFramebuffer are identical, the samples corresponding to each
114    pixel location in the source are converted to a single sample before
115    being written to the destination."
116
117    Modify the last paragraph in section 4.3.3 "Copying Pixels" that was
118    added by ARB_framebuffer_object:
119
120    "If SAMPLE_BUFFERS for either the read framebuffer or draw
121    framebuffer is greater than zero, no copy is performed and an
122    INVALID_OPERATION error is generated if the dimensions of the source
123    and destination rectangles provided to BlitFramebuffer are not
124    identical and the filter is NEAREST or LINEAR, or if the formats of
125    the read and draw framebuffers are not identical."
126
127    Append to section 4.3.3, after the text that was added by
128    ARB_framebuffer_object:
129
130    "If SAMPLE_BUFFERS for the read framebuffer is greater than zero,
131    SAMPLE_BUFFERS for the draw framebuffer is zero, the dimensions of
132    the source and destination rectangles provided to BlitFramebuffer
133    are not identical, and the filter is SCALED_RESOLVE_FASTEST_EXT or
134    SCALED_RESOLVE_NICEST_EXT, then the source samples are resolved and
135    scaled in an implementation specific manner.  When the filter is
136    SCALED_RESOLVE_FASTEST_EXT, no fewer than four samples from the read
137    framebuffer will be used to construct each destination pixel.  When
138    the filter is SCALED_RESOLVE_NICEST_EXT, the number of samples used
139    to construct each destination pixel will be at least as many as is
140    used when the filter is SCALED_RESOLVE_FASTEST_EXT.
141
142    Futhermore, if the filter provided to BlitFramebuffer is
143    SCALED_RESOLVE_FASTEST_EXT or SCALED_RESOLVE_NICEST_EXT, and if
144    SAMPLE_BUFFERS for the read framebuffer is zero or SAMPLE_BUFFERS
145    for the draw framebuffer is greater than zero then no copy is
146    performed and an INVALID_OPERATION error is generated."
147
148    If OpenGL 3.1 is supported, modify the following text in section
149    4.3.2 "Copying Pixels":
150
151    "Calling BlitFramebuffer will result in an INVALID_OPERATION error if
152    filter is not NEAREST and read buffer contains integer data."
153
154
155Dependencies on ARB_framebuffer_object
156
157    ARB_framebuffer_object is required.
158
159
160Errors
161
162    If either the draw or read framebuffer is framebuffer complete and
163    has a value of SAMPLE_BUFFERS that is greater than zero, then the
164    error INVALID_OPERATION is generated if BlitFramebuffer is called
165    and the specified source and destination dimensions are not
166    identical and the filter is NEAREST or LINEAR.
167
168    If the draw framebuffer is framebuffer complete and has a value of
169    SAMPLE_BUFFERS that is greater than zero, or if the read framebuffer
170    is framebuffer complete and has a value of SAMPLE_BUFFERS that is
171    zero, then the error INVALID_OPERATION is generated if
172    BlitFramebuffer is called and the filter is
173    SCALED_RESOLVE_FASTEST_EXT or SCALED_RESOLVE_NICEST_EXT.
174
175
176NVIDIA Implementation Details
177
178    When SAMPLE_BUFFERS is greater than zero, the samples are laid out
179    in a rectangular grid roughly corresponding to the location of the
180    samples where the aspect ratio per pixel is no worse than two.
181
182    SCALED_RESOLVE_FASTEST_EXT is implemented with a simple bilinear
183    filter of the source samples, regardless of the number of samples in
184    the read framebuffer.
185
186    SCALED_RESOLVE_NICEST_EXT is implemented with an anisotropic filter
187    of the source samples, regardless of the number of samples in the
188    read framebuffer.  The final image quality will be somewhat
189    dependent on the ratio of the dimensions of the draw and read
190    framebuffers, but in all cases will be no worse than a simple
191    bilinear filter.
192
193
194Issues
195
196    (1) What should this extension be called?
197
198        RESOLVED: EXT_framebuffer_multisample_blit_scaled.
199
200        This extension is mostly based on the functionality introduced
201        by EXT_framebuffer_multisample and EXT_framebuffer_blit, and so
202        should include all of these terms.
203
204    (2) Should there be an explicit way to enable the scaled resolve
205        blit, or should this feature be silently enabled by the mere
206        presence of this extension?
207
208        RESOLVED: Explicit enums.
209
210        While it might be simpler to just remove the restriction on the
211        dimensions of the rectangles passed to BlitFramebuffer when
212        SAMPLE_BUFFERS is greater than zero for either the read or draw
213        framebuffer, a new filter type was added to address the
214        potential loss in quality when doing a single-pass scaled
215        resolve blit.
216
217    (3) Should the restriction be removed in all cases, or only when
218        SAMPLE_BUFFERS is greater than zero for the read framebuffer?
219
220        RESOLVED: Only for multisample resolves.
221
222        Given the fact that this extension adds new filter types
223        explicitly designed for a scaled multisample resolve blit, it
224        seems reasonable to limit the use of this new filter type to
225        multisample resolves and not pixel replication when
226        SAMPLE_BUFFERS is greater than zero for the draw framebuffer.
227        As such, the new filter types can only be used with a
228        multisample read framebuffer and a single-sample draw
229        framebuffer.
230
231    (4) Should the restriction be removed when SAMPLE_BUFFERS is greater
232        than zero for both the read and draw framebuffer?
233
234        RESOLVED: NO.
235
236        The purpose of this extension is to improve performance of the
237        multisample resolve operation when the resulting pixel data
238        needs to be copied to a texture with different dimensions.  By
239        allowing the resolve and scale to be completed with a single
240        BlitFramebuffer call, there is no need for an intermediate
241        framebuffer object.  This both reduces the memory footprint and
242        increases performance by reducing the amount of data that needs
243        to be copied.
244
245    (5) Does the process in which sample values are resolved and scaled
246        need to be defined?
247
248        RESOLVED: NO.
249
250        The minimum levels of quality are defined by this extension, but
251        the exact details are left up to the implementation.  In fact,
252        it is likely that a single, potentially random sample for each
253        pixel will be accessed as part of a simple bilinear filter
254        operation.  This will depend on the memory layout for the given
255        number of SAMPLE_BUFFERS, the dimensions of the source and
256        destination rectangles, and so on.
257
258    (6) How good is SCALED_RESOLVE_FASTEST_EXT?
259
260        RESOLVED: No worse than a 4-tap linear filter.
261
262        The implementation of this filter type should be no worse than a
263        simple 4-tap linear filter.  The exact image quality may depend
264        on the memory layout of the multisampled read framebuffer.
265
266    (7) How good is SCALED_RESOLVE_NICEST_EXT?
267
268        RESOLVED: No worse than SCALED_RESOLVE_FASTEST_EXT.
269
270        The implementation of this filter type should be at least as
271        good as than a simple 4-tap linear filter, but does not need to
272        be bit-for-bit identical with the original two-pass resolve and
273        scale.  The exact image quality may depend on the memory layout
274        of the multisampled read framebuffer.
275
276    (8) Can the new filter types be used with integer data?
277
278        RESOLVED: NO.
279
280        It does not make sense to have the new filter types be used with
281        integer data when the OpenGL 3.1 spec does not allow a filter of
282        LINEAR in those cases.
283
284
285Revision History
286
287    Rev.    Date    Author    Changes
288    ----  --------  --------  -----------------------------------------
289    8     07/05/11  ghughes   Update status to complete.
290    7     03/10/11  ghughes   Update contributors.
291    6     03/01/11  ghughes   Updated NVIDIA implementation details.
292    5     03/01/11  ghughes   More clarifications.
293    4     02/28/11  ghughes   Clarified language about filter types.
294    3     08/30/10  ghughes   Updated filter enums, added more issues.
295    2     08/30/10  ghughes   Added new filter types.
296    1     08/27/10  ghughes   Initial revision.
297