Back to the OpenGL extension cross reference

GL_NV_multisample_filter_hint


Name


    NV_multisample_filter_hint

Name Strings


    GL_NV_multisample_filter_hint

Contact


    Mark J. Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com)

Notice


    Copyright NVIDIA Corporation, 2001.

IP Status


    NVIDIA Proprietary.

Status


    Shipping, May 2001

Version


    NVIDIA Date: May 16, 2001
$Date: 2002/04/03 $ $Revision: #3 $
$Id: //sw/main/docs/OpenGL/specs/GL_NV_multisample_filter_hint.txt#3 $

Number


    259

Dependencies


    Written based on the OpenGL 1.2.1 specification.

Requires ARB_multisample.

Overview


    OpenGL multisampling typically assumes that the samples of a given
pixel are weighted uniformly and averaged to compute the pixel's
resolved color. This extension provides a hint that permits
implementations to provide an alternative method of resolving the
color of multisampled pixels.

As an example of such an alternative method, NVIDIA's GeForce3 GPU
provides a technique known as Quincunx filtering. This technique
is used in two-sample multisampling, but it blends the pixel's two
samples and three additional samples from adjacent pixels. The sample
pattern is analogous to the 5 pattern on a die. The quality of this
technique is widely regarded as comparable to 4 sample multisampling.

Issues


    Is the glHint mechanism the right mechanism to expose this functionality?

RESOLUTION: Yes. Multisample filtering quality is subject to
the kinds of variations that the glHint was intended to control.

Arguably, the glHint mechanism only provides two definite settings:
GL_FASTEST and GL_NICEST while there may be many different
techniques for controlling multisample filtering quality.
We expect hardware to support only one or two techniques rather
than a multitude of nearly indistinguishable sampling techniques.

When does changing the multisampling filter hint take effect?

RESOLUTION: It may not be until the next swap buffers or glClear
operation that the multisample hint actually takes effect.
This may be implementation dependent.

What is the meaning of GL_DONT_CARE for the multisample hint?

RESOLUTION: By default, NVIDIA expects to treat GL_DONT_CARE
the same as GL_FASTEST. However, the meaning of GL_DONT_CARE
for this hint may be subject to a registry (or environment) setting,
possibly settable through a control panel.

Does GL_NICEST require Quincunx filtering?

RESOLUTION: No. NVIDIA's GeForce3 Quincunx filtering is one
possible technique that may be used to implement the GL_NICEST
setting, but future GPUs may use other techniques.

Can the meaning of the multisample hint vary depending on the number
of samples of the drawable?

RESOLUTION: Yes.

The following describes how GeForce3 uses the multisample hint:

When using 2-sample multisampling with GeForce3, the multisample
filter hint affects multisample filtering as follows: GL_NICEST uses
5-tap Quincunx multisample filtering while GL_FASTEST uses standard
even-weighted 2-tap multisample filtering of the pixel's 2 samples.

When using 4-sample multisampling with GeForce3, the multisample
filter hint affects multisample filtering as follows: GL_NICEST
uses 9-tap 3x3 multisample filtering while GL_FASTEST uses standard
even-weighted 4-tap multisample filtering of the pixel's 4 samples.

What is the difference between a "tap" and a "sample"?

In the context of multisample filtering, a sample is
a subpixel frame buffer sample containing color, depth, and
stencil information. A tap is a source of data for filtering.
Typically, samples are filtered by evenly weighting all the samples
belonging to a pixel. In this case, the number of taps for the
filter is equal to the number of samples for the pixel. In other
filtering schemes, the number of taps and samples may not be equal
(and potentially not evenly weighted as well). For example,
GeForce3's quincunx filtering uses 5 taps even though each pixel
has only 2 multisample samples. Three of the five taps source
samples outside the pixel's footprint of two samples.

Should the multisample filtering technique be determined by the
visual/PFD rather than OpenGL rendering context state?

RESOLUTION: No. The number of multisample samples per pixel that
a window has is a property of the visual/PFD, but the filtering
technique does not have to be defined up-front at when the pixel
format is set.

While not quite consistent with the way ARB_multisample is specified,
NVIDIA uses the SwapBuffers operation as a trigger for downsampling
multisample sample buffers (other operations such as glReadPixels
also trigger downsampling). But a SwapBuffers operation can be
requested without a current OpenGL rendering context. What happens
when a SwapBuffers operation is performed with no current OpenGL
rendering context?

RESOLUTION: The multisample filter hint is treated as GL_DONT_CARE
in this case. Applications that want the multisample filter hint
to apply to their BufferSwap operation should perform the BufferSwap
operation while bound to an OpenGL rendering context.

New Procedures and Functions


    None

New Tokens


    Accepted by the <target> parameter of Hint and by the <pname>
parameter of GetBooleanv, GetIntegerv, GetFloatv, and GetDoublev:

MULTISAMPLE_FILTER_HINT_NV 0x8534

Additions to Chapter 2 of the GL Specification (OpenGL Operation)


    None

Additions to Chapter 3 of the GL Specification (Rasterization)


    None

Additions to Chapter 4 of the GL Specification (Per-Fragment Operations and the Framebuffer)


    None

Additions to Chapter 5 of the GL Specification (Special Functions)


 --  Section 5.6 "Hints"

Replace the description of hint targets in the first paragraph with:

"target may be one of PERSPECTIVE_HINT, indicating the desired
quality of parameter interpolation; POINT_SMOOTH_HINT, indicating the
desired sampling quality of points; LINE_SMOOTH_HINT, indicating the
desired sampling quality of lines; POLYGON_SMOOTH_HINT, indicating
the desired sampling quality of polygons; FOG_HINT, indicating
whether fog calculations are done per pixel or per vertex; and
MULTISAMPLE_FILTER_HINT, indicating the desired quality of multisample
filtering. The MULTISAMPLE_FILTER_HINT is ignored if the frame buffer
has no multisample samples. When NICEST (or possibly DONT_CARE)
multisample filtering is requested and the frame buffer supports
multisampling, the multisample filter pattern may involve samples
outside the pixel's sample set. The exact NICEST (or possibly
DONT_CARE) multisample filtering technique used is implementation
dependent and may vary with the number of multisample samples
supported."

Additions to Chapter 6 of the GL Specification (State and State Requests)


    None

Additions to the GLX, WGL, and AGL Specification


    Add the following to the description of what happens at SwapBuffers
time.

"When a SwapBuffers operation is performed by a thread without
a current OpenGL rendering context and the target drawable to be
swapped is multisampled, any multisample filtering operation that
occurs should be done as if the GL_MULTISAMPLE_FILTER_HINT value is
set to GL_DONT_CARE."

GLX Protocol


    None

Errors


    None

New State


(table 6.23, p213) add the following entry:

Get Value Type Get Command Initial Value Description Sec Attribute
---------------------------- ---- ----------- ------------- ----------- ------ --------------
MULTISAMPLE_FILTER_HINT_NV Z3 GetIntegerv DONT_CARE Multisample filter 5.6 hint
quality hint

Revision History


    None

Implementation Support


   List of OpenGL implementations supporting the GL_NV_multisample_filter_hint extension

Original File


   Original text file for the GL_NV_multisample_filter_hint extension


Page generated on Sun Nov 20 18:39:40 2005