OpenGL 1.5 specs available

[eSa]

Official OpenGL 1.5 specification is available as 2 MB pdf;

http://www.opengl.org/developers/documentation/OpenGL15.html

Now, let's just hope that those implementations are quickly here too...

 

[Rolf N]

It was about time. What took them so long anyway?

I mean, "released on July 29, 2003", yeah, that's about right according to ARB meeting notes :?

 

[Dave Baumann]

52.16's are fully OGL1.5 compliant. Cat3.8's weren't, but (IIRC) they did have the Shader extensions - not checked cat3.9.

 

[Ostsol]

The extension strings for ARB_point_sprite and NV_point_sprite are in the Cat 3.9s. No other new extensions, though, as far as I could tell.

 

[bloodbob]

When you say full complaint do you mean 52.16 have the GLSlang extenstions?

 

[Jallen]

When you say full complaint do you mean 52.16 have the GLSlang extenstions?

The OpenGL shading language is not part of OpenGL 1.5, they are optional ARB extensions.

 

[Ostsol]

The extensions that have been upgraded to core functionality in OpenGL 1.5 are:

ARB_vertex_buffer_object
ARB_occlusion_query
EXT_shadow_funcs

Other than some changed token names, that's it. . . The spec states that the shading languages are merely "important adjuncts to the OpenGL core". My guess is that they will be part of the core in OpenGL 2.0.

 

[bloodbob]

Yeah I know they aren't core but the whole major point of it was to push expose glslang so can start being used I'm guess its not

But whats with the extremely low maxium accuracy on colour values??

The maximum representable magnitude for colors must be at least 2^10.

They say

the maximum representable magnitude for all other floating-point values must be at least 2^32.

but does that count for colour intermedates in calculations?

1024 is a reasonable low clamp for some things.

Edited this out because that has been in OpenGl spec for ages and basicly all previous cards don't match the spec either. <--- *SLAPS HIMSELF* yeah they do cause it doesn't count integer arithemtics

Also unless I'm mistaken FP16 comes now where near accuracy of about 1 in 10^5 and FP24 comes to about that.

We require simply that numbers floating-point parts contain enough bits and that their exponent fields are large enough so that individual results of floating-point operations are accurate to about 1 part in 10^5.

ATIs implementation is a bit iffy there.

 

[Xmas]

But whats with the extremely low maxium accuracy on colour values??

The maximum representable magnitude for colors must be at least 2^10.

They say

the maximum representable magnitude for all other floating-point values must be at least 2^32.

but does that count for colour intermedates in calculations?

1024 is a reasonable low clamp for some things.

It's not accuracy, it's range. And 2^10 as magnitude for colors really is plenty. It's more important to have enough accuracy in the [0, 1] range.

Interesting question about intermediates, I think this would require the compiler to know via some hints which values are to be colors. Not every value that contributes to the final color output is color.

But anyway, I think it's just a matter of time until NVidia presents an NV_half_float2 extension which allows the use of half in GLslang.

Edited this out because that has been in OpenGl spec for ages and basicly all previous cards don't match the spec either.

Also unless I'm mistaken FP16 comes now where near accuracy of about 1 in 10^5 and FP24 comes to about that.

We require simply that numbers floating-point parts contain enough bits and that their exponent fields are large enough so that individual results of floating-point operations are accurate to about 1 part in 10^5.

ATIs implementation is a bit iffy there.

IIRC FP24 is s16e7, which means worst case (except around zero) is 1 part in 65536 (e.g the smallest representable number >1 is 1.0000152587890625 = 1 + 2^-16). This IMO fits the description "about 1 part in 10^5".

 

[bloodbob]

I ment to say range yeah still 1024 isn't all the great a range was my point if you look at the IEEE float type its range it pretty huge and for some effects espically using powers if intermidates are counted in the same category you might be able to get past 1024. Also its interesting that there is no minium exponent but I guess they assumed everyone would go the generic float format where 1/2 the exponent is negative. This could lead to some more interesting float types.

About is subjective thats why I said it was iffy regardless the spefication has been in there for ages.

 

[Mintmaster]

I haven't read the spec, but a maximum magnitude of 2^32 exactly matches the FP16 spec, does it not? However, FP16 does not match the 1 part in 10^5 spec as Xmas said, for which FP24 is a pretty good match.

Which (FP16 or FP32) do you think NVidia will choose? My guess is FP16, but unfortunately that has an error of about 1 in 10^3.

 

[Xmas]

I haven't read the spec, but a maximum magnitude of 2^32 exactly matches the FP16 spec, does it not? However, FP16 does not match the 1 part in 10^5 spec as Xmas said, for which FP24 is a pretty good match.

Which (FP16 or FP32) do you think NVidia will choose? My guess is FP16, but unfortunately that has an error of about 1 in 10^3.

You forgot that the exponent can be negative, therefore it's biased with -15 or similar. So the largest representable value should be between 2^14 and 2^18.

I don't think NVidia has much of a choice, only in a few cases. The spec is rather confusing, but I expect it to come down to FP32 in all but very special cases. But as I already mentioned, NVidia could provide a "workaround" in the form of an extension that allows the use of half in GLslang.

 

[mrbill]

IIRC FP24 is s16e7, which means worst case (except around zero) is 1 part in 65536 (e.g the smallest representable number >1 is 1.0000152587890625 = 1 + 2^-16). This IMO fits the description "about 1 part in 10^5".

And not just your opinion. 16 fractional bits is enough for "about 1 part in 10E5". I'll quote from a few recent ARB extensions discussing the matter in the issues section.

[P]recision will vary across platforms. The minimum precision requirements (1 part in 10^5 or roughly (emphasis mine) 17 bits) are spelled out in section 2.1.1.

log2(100,000) is 16.61, or roughly 17 bits.

Current implementations are able to meet the minimum requirements specified in the core GL, thanks to its sufficiently loose wording "... so that the individual results of floating-point operations are accurate to ABOUT 1 part in 10^5." (Emphasis added.)

BTW, ARB_vertex_program, ARB_fragment_program, ARB_vertex_shader and ARB_fragment_shader all edit 2.1.1 to promote texture coordinates to the same precision and magnitude requirements for positions and normals.

There was a lot of discussion and a bit of historical digging into the origin of the phrase "about 1 part in 10E5." Since log2(100,000) is 16.61, and since computers like to deal with whole bits, "about 1 part in 10E5" is at least 16 fractional bits (round down) while "at least 1 part in 10E5" would be at least 17 fractional bits (round up).

-mr. bill

 

[Deathlike2]

Dave, are the CAT 3.9s OpenGL 1.5 compliant?... If not, they are 1.4 compliant?

As a side question... is the OpenGL Extension Viewer any good?

http://www.realtech-vr.com/glview/

 

[Waltar]

The extensions that have been upgraded to core functionality in OpenGL 1.5 are:

ARB_vertex_buffer_object
ARB_occlusion_query
EXT_shadow_funcs

Other than some changed token names, that's it. . . The spec states that the shading languages are merely "important adjuncts to the OpenGL core". My guess is that they will be part of the core in OpenGL 2.0.

I think you might be wrong.

 

[Ostsol]

The extensions that have been upgraded to core functionality in OpenGL 1.5 are:

ARB_vertex_buffer_object
ARB_occlusion_query
EXT_shadow_funcs

Other than some changed token names, that's it. . . The spec states that the shading languages are merely "important adjuncts to the OpenGL core". My guess is that they will be part of the core in OpenGL 2.0.

I think you might be wrong.

Take a look at the spec. It gives a list of all the extensions that have been promoted to core functionality.

OpenGL 1.1
<ul>EXT_vertex_array
EXT_polygon_offset
EXT_blend_logic_op
EXT_texture
EXT_copy_texture
EXT_subtexture
EXT_texture_object
[/list]
OpenGL 1.2
<ul>EXT_texture_3d
EXT_bgra
EXT_packed_pixels
EXT_separate_sepcular_color
SGIS_clamp_to_edge
SGIS_texture_lod
EXT_draw_range_elements
EXT_color_table
EXT_color_subtable
EXT_convolution
HP_convolution_border_modes
SGI_color_matrix
EXT_histogram
EXT_blend_color
EXT_blend_minmax
EXT_blend_subtract
[/list]
OpenGL 1.3
<ul>ARB_texture_compression
ARB_texture_cube_map
ARB_multisample
ARB_multitexture
ARB_texture_env_add
ARB_texture_env_combine
ARB_texture_env_dot3
ARB_texture_border_clamp
ARB_transpose_matrix
[/list]
OpenGL 1.4
<ul>SGIS_generate_mipmap
NV_blend_square
ARB_depth_texture
ARB_shadow
EXT_fog_coord
EXT_multi_draw_arrays
ARB_point_parameters
EXT_secondary_color
EXT_blend_func_separate
EXT_stencil_wrap
ARB_texture_env_crossbar
ARB_texture_mirrored_repeat
ARB_window_pos
[/list]
OpenGL 1.5
<ul>ARB_vertex_buffer_object
ARB_occlusion_query
EXT_shadow_funcs
[/list]