intel-hard/intel-hard-graphics
2
0 Fork 0
mirror of https://github.com/elwrcl/intel-hard-graphics.git synced 2026-10-31 19:08:03 +03:00
Code Issues Packages Projects Releases Wiki Activity

init

Browse Source
This commit is contained in:
elwrcl committed 2026-06-06 13:25:15 +03:00
1 parent 04d4dc8b09
commit 818cab85dc
12511 files changed
+6156641
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

docs/_extra/specs/MESA_texture_signed_rgba.spec
+214
View File
@@ -0,0 +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 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 <internalformat> parameter of
TexImage1D, TexImage2D, TexImage3D, CopyTexImage1D, and CopyTexImage2D:
RGBA_SNORM 0x8F93
RGBA8_SNORM 0x8F97
Returned by the <params> 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 <value>
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.