From 2fb58f16eeec8ef3ec2a25e246477aab64e38a7d Mon Sep 17 00:00:00 2001 From: marha Date: Sun, 10 Apr 2011 18:43:19 +0000 Subject: mesa git update --- mesalib/docs/MESA_texture_signed_rgba.spec | 428 ++++++++++++++--------------- 1 file changed, 214 insertions(+), 214 deletions(-) (limited to 'mesalib/docs/MESA_texture_signed_rgba.spec') diff --git a/mesalib/docs/MESA_texture_signed_rgba.spec b/mesalib/docs/MESA_texture_signed_rgba.spec index 49c8e9e5d..bcc4d4203 100644 --- a/mesalib/docs/MESA_texture_signed_rgba.spec +++ b/mesalib/docs/MESA_texture_signed_rgba.spec @@ -1,214 +1,214 @@ -Name - - MESA_texture_signed_rgba - -Name Strings - - GL_MESA_texture_signed_rgba - -Contact - - - -Notice - - - -IP Status - - No known IP issues - -Status - - - -Version - - 0.3, 2009-03-24 - -Number - - Not assigned ? - -Dependencies - - Written based on the wording of the OpenGL 2.0 specification. - - This extension trivially interacts with ARB_texture_float. - This extension shares some language with ARB_texture_compression_rgtc - but does not depend on it. - -Overview - - OpenGL prior to 3.1 does not support any signed texture formats. - ARB_texture_compression_rgtc introduces some compressed red and - red_green signed formats but no uncompressed ones, which might - still be useful. NV_texture_shader adds signed texture formats, - but also a lot of functionality which has been superceded by fragment - shaders. - It is usually possible to get the same functionality - using a unsigned format by doing scale and bias in a shader, but this - is undesirable since modern hardware has direct support for this. - This extension adds a signed 4-channel texture format by backporting - the relevant features from OpenGL 3.1, as a means to support this in - OpenGL implementations only supporting older versions. - -Issues - - 1) What should this extension be called? - - RESOLVED: MESA_texture_signed_rgba seems reasonable. - The rgba part is there because only 4 channel format is supported. - - - 2) Should the full set of signed formats (alpha, luminance, rgb, etc.) - be supported? - - RESOLVED: NO. To keep this extension simple, only add the most - universal format, rgba. alpha/luminance can't be trivially supported - since OpenGL 3.1 does not support them any longer, and there is some - implied dependency on ARB_texture_rg for red/red_green formats so - avoid all this. Likewise, only 8 bits per channel is supported. - - - 3) Should this extension use new enums for the texture formats? - - RESOLVED: NO. Same enums as those used in OpenGL 3.1. - - - 4) How are signed integer values mapped to floating-point values? - - RESOLVED: Same as described in issue 5) of - ARB_texture_compression_rgtc (quote): - A signed 8-bit two's complement value X is computed to - a floating-point value Xf with the formula: - - { X / 127.0, X > -128 - Xf = { - { -1.0, X == -128 - - This conversion means -1, 0, and +1 are all exactly representable, - however -128 and -127 both map to -1.0. Mapping -128 to -1.0 - avoids the numerical awkwardness of have a representable value - slightly more negative than -1.0. - - This conversion is intentionally NOT the "byte" conversion listed - in Table 2.9 for component conversions. That conversion says: - - Xf = (2*X + 1) / 255.0 - - The Table 2.9 conversion is incapable of exactly representing - zero. - - (Difference to ARB_texture_compression_rgtc): - This is the same mapping as OpenGL 3.1 uses. - This is also different to what NV_texture_shader used. - The above mapping should be considered the reference, but there - is some leeway so other mappings are allowed for implementations which - cannot do this. Particulary the mapping given in NV_texture_shader or - the standard OpenGL byte/float mapping is considered acceptable too, as - might be a mapping which represents -1.0 by -128, 0.0 by 0 and 1.0 by - 127 (that is, uses different scale factors for negative and positive - numbers). - Also, it is ok to store incoming GL_BYTE user data as-is, without - converting to GL_FLOAT (using the standard OpenGL float/byte mapping) - and converting back (using the mapping described here). - Other than those subtle issues there are no other non-standard - conversions used, so when using for instance CopyTexImage2D with - a framebuffer clamped to [0,1] all converted numbers will be in the range - [0, 127] (and not scaled and biased). - - - 5) How will signed components resulting from RGBA8_SNORM texture - fetches interact with fragment coloring? - - RESOLVED: Same as described in issue 6) of - ARB_texture_compression_rgtc (quote): - The specification language for this extension is silent - about clamping behavior leaving this to the core specification - and other extensions. The clamping or lack of clamping is left - to the core specification and other extensions. - - For assembly program extensions supporting texture fetches - (ARB_fragment_program, NV_fragment_program, NV_vertex_program3, - etc.) or the OpenGL Shading Language, these signed formats will - appear as expected with unclamped signed components as a result - of a texture fetch instruction. - - If ARB_color_buffer_float is supported, its clamping controls - will apply. - - NV_texture_shader extension, if supported, adds support for - fixed-point textures with signed components and relaxed the - fixed-function texture environment clamping appropriately. If the - NV_texture_shader extension is supported, its specified behavior - for the texture environment applies where intermediate values - are clamped to [-1,1] unless stated otherwise as in the case - of explicitly clamped to [0,1] for GL_COMBINE. or clamping the - linear interpolation weight to [0,1] for GL_DECAL and GL_BLEND. - - Otherwise, the conventional core texture environment clamps - incoming, intermediate, and output color components to [0,1]. - - This implies that the conventional texture environment - functionality of unextended OpenGL 1.5 or OpenGL 2.0 without - using GLSL (and with none of the extensions referred to above) - is unable to make proper use of the signed texture formats added - by this extension because the conventional texture environment - requires texture source colors to be clamped to [0,1]. Texture - filtering of these signed formats would be still signed, but - negative values generated post-filtering would be clamped to - zero by the core texture environment functionality. The - expectation is clearly that this extension would be co-implemented - with one of the previously referred to extensions or used with - GLSL for the new signed formats to be useful. - - - 6) Should the RGBA_SNORM tokens also be accepted by CopyTexImage - functions? - - RESOLVED: YES. - - - 7) What to do with GetTexParameter if ARB_texture_float is supported, - in particular what datatype should this return for TEXTURE_RED_TYPE_ARB, - TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB, TEXTURE_ALPHA_TYPE_ARB? - - RESOLVED: ARB_texture_float states type is either NONE, - UNSIGNED_NORMALIZED_ARB, or FLOAT. This extension adds a new enum, - SIGNED_NORMALIZED, which will be returned accordingly. This is the - same behaviour as in OpenGL 3.1. - - -New Tokens - - - Accepted by the parameter of - TexImage1D, TexImage2D, TexImage3D, CopyTexImage1D, and CopyTexImage2D: - - RGBA_SNORM 0x8F93 - RGBA8_SNORM 0x8F97 - - Returned by the parameter of GetTexLevelParameter: - - SIGNED_NORMALIZED 0x8F9C - - -Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization): - - -- Section 3.8.1, Texture Image Specification - - Add to Table 3.16 (page 154): Sized internal formats - - Sized Base R G B A L I D - Internal Format Internal Format bits bits bits bits bits bits bits - --------------- --------------- ---- ---- ---- ---- ---- ---- ---- - RGBA8_SNORM RGBA 8 8 8 8 0 0 0 - - -Dependencies on ARB_texture_float extension: - - If ARB_texture_float is supported, GetTexParameter queries with - of TEXTURE_RED_TYPE_ARB, TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB or - TEXTURE_ALPHA_TYPE_ARB return SIGNED_NORMALIZED if - the base internal format is RGBA_SNORM. +Name + + MESA_texture_signed_rgba + +Name Strings + + GL_MESA_texture_signed_rgba + +Contact + + + +Notice + + + +IP Status + + No known IP issues + +Status + + + +Version + + 0.3, 2009-03-24 + +Number + + Not assigned ? + +Dependencies + + Written based on the wording of the OpenGL 2.0 specification. + + This extension trivially interacts with ARB_texture_float. + This extension shares some language with ARB_texture_compression_rgtc + but does not depend on it. + +Overview + + OpenGL prior to 3.1 does not support any signed texture formats. + ARB_texture_compression_rgtc introduces some compressed red and + red_green signed formats but no uncompressed ones, which might + still be useful. NV_texture_shader adds signed texture formats, + but also a lot of functionality which has been superseded by fragment + shaders. + It is usually possible to get the same functionality + using a unsigned format by doing scale and bias in a shader, but this + is undesirable since modern hardware has direct support for this. + This extension adds a signed 4-channel texture format by backporting + the relevant features from OpenGL 3.1, as a means to support this in + OpenGL implementations only supporting older versions. + +Issues + + 1) What should this extension be called? + + RESOLVED: MESA_texture_signed_rgba seems reasonable. + The rgba part is there because only 4 channel format is supported. + + + 2) Should the full set of signed formats (alpha, luminance, rgb, etc.) + be supported? + + RESOLVED: NO. To keep this extension simple, only add the most + universal format, rgba. alpha/luminance can't be trivially supported + since OpenGL 3.1 does not support them any longer, and there is some + implied dependency on ARB_texture_rg for red/red_green formats so + avoid all this. Likewise, only 8 bits per channel is supported. + + + 3) Should this extension use new enums for the texture formats? + + RESOLVED: NO. Same enums as those used in OpenGL 3.1. + + + 4) How are signed integer values mapped to floating-point values? + + RESOLVED: Same as described in issue 5) of + ARB_texture_compression_rgtc (quote): + A signed 8-bit two's complement value X is computed to + a floating-point value Xf with the formula: + + { X / 127.0, X > -128 + Xf = { + { -1.0, X == -128 + + This conversion means -1, 0, and +1 are all exactly representable, + however -128 and -127 both map to -1.0. Mapping -128 to -1.0 + avoids the numerical awkwardness of have a representable value + slightly more negative than -1.0. + + This conversion is intentionally NOT the "byte" conversion listed + in Table 2.9 for component conversions. That conversion says: + + Xf = (2*X + 1) / 255.0 + + The Table 2.9 conversion is incapable of exactly representing + zero. + + (Difference to ARB_texture_compression_rgtc): + This is the same mapping as OpenGL 3.1 uses. + This is also different to what NV_texture_shader used. + The above mapping should be considered the reference, but there + is some leeway so other mappings are allowed for implementations which + cannot do this. Particularly the mapping given in NV_texture_shader or + the standard OpenGL byte/float mapping is considered acceptable too, as + might be a mapping which represents -1.0 by -128, 0.0 by 0 and 1.0 by + 127 (that is, uses different scale factors for negative and positive + numbers). + Also, it is ok to store incoming GL_BYTE user data as-is, without + converting to GL_FLOAT (using the standard OpenGL float/byte mapping) + and converting back (using the mapping described here). + Other than those subtle issues there are no other non-standard + conversions used, so when using for instance CopyTexImage2D with + a framebuffer clamped to [0,1] all converted numbers will be in the range + [0, 127] (and not scaled and biased). + + + 5) How will signed components resulting from RGBA8_SNORM texture + fetches interact with fragment coloring? + + RESOLVED: Same as described in issue 6) of + ARB_texture_compression_rgtc (quote): + The specification language for this extension is silent + about clamping behavior leaving this to the core specification + and other extensions. The clamping or lack of clamping is left + to the core specification and other extensions. + + For assembly program extensions supporting texture fetches + (ARB_fragment_program, NV_fragment_program, NV_vertex_program3, + etc.) or the OpenGL Shading Language, these signed formats will + appear as expected with unclamped signed components as a result + of a texture fetch instruction. + + If ARB_color_buffer_float is supported, its clamping controls + will apply. + + NV_texture_shader extension, if supported, adds support for + fixed-point textures with signed components and relaxed the + fixed-function texture environment clamping appropriately. If the + NV_texture_shader extension is supported, its specified behavior + for the texture environment applies where intermediate values + are clamped to [-1,1] unless stated otherwise as in the case + of explicitly clamped to [0,1] for GL_COMBINE. or clamping the + linear interpolation weight to [0,1] for GL_DECAL and GL_BLEND. + + Otherwise, the conventional core texture environment clamps + incoming, intermediate, and output color components to [0,1]. + + This implies that the conventional texture environment + functionality of unextended OpenGL 1.5 or OpenGL 2.0 without + using GLSL (and with none of the extensions referred to above) + is unable to make proper use of the signed texture formats added + by this extension because the conventional texture environment + requires texture source colors to be clamped to [0,1]. Texture + filtering of these signed formats would be still signed, but + negative values generated post-filtering would be clamped to + zero by the core texture environment functionality. The + expectation is clearly that this extension would be co-implemented + with one of the previously referred to extensions or used with + GLSL for the new signed formats to be useful. + + + 6) Should the RGBA_SNORM tokens also be accepted by CopyTexImage + functions? + + RESOLVED: YES. + + + 7) What to do with GetTexParameter if ARB_texture_float is supported, + in particular what datatype should this return for TEXTURE_RED_TYPE_ARB, + TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB, TEXTURE_ALPHA_TYPE_ARB? + + RESOLVED: ARB_texture_float states type is either NONE, + UNSIGNED_NORMALIZED_ARB, or FLOAT. This extension adds a new enum, + SIGNED_NORMALIZED, which will be returned accordingly. This is the + same behaviour as in OpenGL 3.1. + + +New Tokens + + + Accepted by the parameter of + TexImage1D, TexImage2D, TexImage3D, CopyTexImage1D, and CopyTexImage2D: + + RGBA_SNORM 0x8F93 + RGBA8_SNORM 0x8F97 + + Returned by the parameter of GetTexLevelParameter: + + SIGNED_NORMALIZED 0x8F9C + + +Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization): + + -- Section 3.8.1, Texture Image Specification + + Add to Table 3.16 (page 154): Sized internal formats + + Sized Base R G B A L I D + Internal Format Internal Format bits bits bits bits bits bits bits + --------------- --------------- ---- ---- ---- ---- ---- ---- ---- + RGBA8_SNORM RGBA 8 8 8 8 0 0 0 + + +Dependencies on ARB_texture_float extension: + + If ARB_texture_float is supported, GetTexParameter queries with + of TEXTURE_RED_TYPE_ARB, TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB or + TEXTURE_ALPHA_TYPE_ARB return SIGNED_NORMALIZED if + the base internal format is RGBA_SNORM. -- cgit v1.2.3