Tomlinson, Gordon wrote:
Time to start the re-write...
Src:
http://www.khronos.org/news/press/releases/khronos_releases_opengl_30_specifications_to_support_latest_generations_of/
See Spec @ http://www.opengl.org/registry/doc/glspec30.20080811.pdf
I saw this interesting comment from the ARB chairman on Slashdot
("OpenGL 3.0 Released, Developers furious")
Paul
<quote>
What happened to Longs Peak?
In January 2008 the ARB decided to change directions. At that point it
had become clear that doing Longs Peak, although a great effort, wasn't
going to happen. We ran into details that we couldn't resolve cleanly in
a timely manner. For example, state objects. The idea there is that of
all state is immutable. But when we were deciding where to put some of
the sample ops state, we ran into issues. If the alpha test is
immutable, is the alpha ref value also? If we do so, what does this mean
to a developer? How many (100s?) of objects does a developer need to
manage? Should we split sample ops state into more than one object?
Those kind of issues were taking a lot of time to decide.
Furthermore, the "opt in" method in Longs Peak to move an existing
application forward has its pros and cons. The model of creating another
context to write Longs Peak code in is very clean. It'll work great for
anyone who doesn't have a large code base that they want to move forward
incrementally. I suspect that that is most of the developers that are
active in this forum. However, there are a class of developers for which
this would have been a, potentially very large, burden. This clearly is
a controversial topic, and has its share of proponents and opponents.
While we were discussing this, the clock didn't stop ticking. The OpenGL
API *has to* provide access to the latest graphics hardware features.
OpenGL wasn't doing that anymore in a timely manner. OpenGL was behind
in features. All graphics hardware vendors have been shipping hardware
with many more features available than OpenGL was exposing. Yes, vendor
specific extensions were and are available to fill the gap, but that is
not the same as having a core API including those new features. An API
that does not expose hardware capabilities is a dead API.
Thus, prioritization was needed, and we made several decisons.
1) We set a goal of exposing hardware functionality of the latest
generations of hardware by this Siggraph. Hence, the OpenGL 3.0 and GLSL
1.30 API you guys all seem to love ;\)
2) We decided on a formal mechanism to remove functionality from the
API. We fully realize that the existing API has been around for a long
time, has cruft and is inconsistent with its treatment of objects (how
many object models are in the OpenGL 3.0 spec? You count). In its
shortest form, removing functionality is a two-step process. First,
functionality will be marked "deprecated" in the specification. A long
list of functionality is already marked deprecated in the OpenGL 3.0
spec. Second, a future revision of the core spec will actually remove
the deprecated functionality. After that, the ARB has options. It can
decide to do a third step, and fold some of the removed functionality
into a profile. Profiles are optional to implement (more below) and its
functionality might still be very important to a sub-set of the OpenGL
market. Note that we also decided that new functionality does not have
to, and will likely not work with, deprecated functionality. That will
make the spec easier to write, read and understand, and drivers easier
to implement.
3) We decided to provide a way to create a forward-compatible context.
That is an OpenGL 3.0 context with all deprecated features removed.
Giving you, as a developer, a preview of what a next version of OpenGL
might look like. Drivers can take advantage of this, and might be able
to optimize certain code paths in the forward-compatible context only.
This is described in the WGL_ARB_create_context extension spec.
4) We decided to have a formal way of defining profiles. During the
Longs Peak design phase, we ran into disagreement over what features to
remove from the API. Longs Peak removed quite a lot of features as you
might remember. Not coincidentally, most of those features are marked
deprecated in OpenGL 3.0. The disagreements happened because of
different market needs. For some markets a feature is essential, and
removing it will cause issues, whereas for another market it is not. We
discovered we couldn't do one API to serve all. A profile encapsulates
functionality needed to meet the needs of a particular market.
Conformant OpenGL products may implement one or more profiles. A profile
is by definition a subset of the whole core specification. The core
OpenGL specification will contain all functionality, including what is
in a profile, in a coherently designed whole. Profiles simply enable
products for certain markets to not ship functionality that is not
relevant to those markets in a well defined way. Only the ARB may define
profiles, individual vendors may not (this in contrast to extensions).
5) We will keep working on object model issues. Yes, this work has been
put on the back burner to get OpenGL 3.0 done, but we have picked that
work up again. One of the early results of this is that we will work on
folding object model improvements into the core in a more incremental
manner.
6) We decided to provide functionality, where possible, as extensions to
OpenGL 2.1. Any OpenGL 3.0 feature that does not require OpenGL 3.0
hardware is also available in extension form to OpenGL 2.1. The idea
here is that new functionality on older hardware enables software
vendors to provide upgrades to their existing users.
7) We decided that OpenGL is not going to evolve into a general GPU
compute API. In the last two years or so compute using a GPU and a CPU
has taken off, in fact is exploding. Khronos has recognized this and is
on a fast track to define and release OpenCL, the open standard for
compute programming. OpenGL and OpenCL will be able to share data, like
buffer objects, in an efficient manner.
There are many good ideas in Longs Peak. They are not lost. We would be
stupid to ignore it. We spent almost two years on it, and a lot of good
stuff was designed. There is a desire to work on object model issues in
the ARB, and we recently started doing that again. Did you know that you
have no guarantee that if you change properties of a texture or render
buffer attached to a framebuffer object that the framebuffer object will
actually notice? It has to notice it, otherwise your next rendering
command will not work. Each vendor's implementation deals with this case
a bit differently. If you throw in multiple contexts in the mix, this
becomes an even more interesting issue. The ARB wants to do object model
improvements right the first time. We can't afford to do it wrong. At
the same time, the ARB will work on exposing new hardware functionality
in a timely manner.
I want to ask you to take a deep breath, let this all sink in a bit, and
then open up the OpenGL 3.0 and GLSL 1.30 specifications we just posted
that have all new stuff clearly marked. Hopefully you'll agree with me
that there's quite a lot of new stuff to be excited about.
http://www.opengl.org/registry/doc/glspec30.20080811.withchanges.pdf
[opengl.org]
http://www.opengl.org/registry/doc/GLSLangSpec.Full.1.30.08.withchanges.pdf
[opengl.org]
This is certainly not the end of the OpenGL API. OpenGL will evolve and
will become better with every new revision. I welcome constructive feedback.
Regards,
Barthold Lichtenbelt
OpenGL ARB Working Group chair
</quote>
Khronos Releases OpenGL 3.0 Specifications to Support Latest
Generations of Programmable Graphics Hardware
/Strong industry support for state-of-the-art OpenGL 3.0 API and GLSL
1.30 shading language specifications on all major platforms; OpenGL
evolutionary model to accelerate development of standard;
Interoperability with OpenCL being defined/
*For more information:*
Elizabeth Riegel, Managing Director, Khronos Group
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
From outside US: +1 415 869 8627
/Strong industry support for state-of-the-art OpenGL 3.0 API and GLSL
1.30 shading language specifications on all major platforms; OpenGL
evolutionary model to accelerate development of standard;
Interoperability with OpenCL being defined /
*11th August, 2008 – SIGGRAPH, Los Angeles, CA *The Khronos™ Group
announced today it has released the OpenGL® 3.0 specification with
strong industry support to bring significant new functionality to the
open, cross-platform standard for 3D graphics acceleration. OpenGL 3.0
includes GLSL™ 1.30, a new version of the OpenGL shading language, and
provides comprehensive access to the functionality of the latest
generations of programmable graphics hardware. The OpenGL working
group has also defined a set of OpenGL 3.0 extensions that expose
potential new functionality for the next version of OpenGL that is
targeted for release in less than 12 months, and a set of extensions
for OpenGL 2.1 to enable much of the new OpenGL functionality on older
hardware. Additionally, OpenGL 3.0 introduces an evolutionary model to
assist in streamlining the specification and to enable rapid
development of the standard to address diverse markets. Finally, the
OpenGL working group has announced that it is working closely with the
emerging OpenCL standard to create a revolutionary pairing of compute
and graphics programming capabilities. The new OpenGL 3.0
specifications are freely available at www.khronos.org/opengl
<http://www.khronos.org/opengl/>.
The OpenGL 3.0 specification enables developers to leverage
state-of-the-art graphics hardware, including many of the graphics
accelerators shipped in the last two years both on Windows XP and
Windows Vista as well as Mac OS and Linux. According to Dr. Jon Peddie
of Jon Peddie Research, a leading graphics market analyst based in
California, the installed base of graphics hardware that will support
OpenGL 3.0 exceeds 60 million units. AMD, Intel and NVIDIA have made
major contributions to the design of OpenGL 3.0 and today all three
companies announced their intent to provide full implementations
within their product families. Additionally, the OpenGL working group
includes the active participation of leading developers such as
Blizzard Entertainment and TransGaming that have played a vital role
in ensuring that the specification meets the genuine needs of the
software community.
“We are very pleased to see the release of OpenGL 3.0, which includes
numerous features and extensions that will help us and other ISVs
bring amazing gaming content to OpenGL-based platforms,” commented
Gavriel State, founder & CTO of TransGaming, Inc.
OpenGL 3.0 introduces dozens of new features including:
* Vertex Array Objects to encapsulate vertex array state for
easier programming and increased throughput;
* non-blocking access to Vertex Buffer Objects with the ability to
update and flush a sub-range for enhanced performance;
* full framebuffer object functionality including multi-sample
buffers, blitting to and from framebuffer objects, rendering to
one and two-channel data, and flexible mixing of buffer sizes
and formats when rendering to a framebuffer object;
* 32-bit floating-point textures and render buffers for increased
precision and dynamic range in visual and computational operations;
* conditional rendering based on occlusion queries for increased
performance;
* compact half-float vertex and pixel data to save memory and
bandwidth;
* transform feedback to capture geometry data after vertex
transformations into a buffer object to drive additional compute
and rendering passes;
* four new texture compression schemes for one and two channel
textures providing a factor of 2-to-1 storage savings over
uncompressed data;
* rendering and blending into sRGB framebuffers to enable faithful
color reproduction for OpenGL applications without adjusting the
monitor's gamma correction;
* texture arrays to provide efficient indexed access into a set of
textures;
* 32-bit floating-point depth buffer support.
The new version of the OpenGL Shading Language, GLSL 1.30, provides
front-to-back native integer operations including full integer-based
texturing, integer input and outputs for vertex and fragment shaders
and a full set of integer bitwise operators. It also improves
compatibility with OpenGL ES, adds new interpolation modes, includes
new forms of explicit control over texturing operations, provides
additional built-in functions for manipulating floating-point numbers
and introduces switch statements for enhanced flow control within
shader programs.
The OpenGL working group has also released a set of extensions to
OpenGL 3.0 that can be immediately used by developers and, after
industry feedback, will potentially be included in the next generation
of OpenGL targeted for release in less than 12 months. These
extensions include geometry shaders, further instancing support, and
texture buffer objects.
Khronos today also released a number of extensions to OpenGL 2.1 which
enables some of the new features in OpenGL 3.0 to be used on older
generations of hardware. These extensions include enhanced VBOs, full
framebuffer object functionality, half float vertices, compressed
textures, vertex array objects and sRGB framebuffers.
Additionally, OpenGL 3.0 defines an evolutionary process for OpenGL
that will accelerate market-driven updates to the specification. The
new OpenGL API supports the future creation of profiles to enable
products to support specific market needs while not burdening every
implementation with unnecessary costs. To avoid fragmentation, the
core OpenGL specification will contain all defined functionality in an
architecturally coherent whole, with profiles tightly specifying
segment-relevant subsets. OpenGL 3.0 also introduces a deprecation
model to enable the API to be streamlined while providing full
visibility to the application developer community, enabling the API to
be optimized for current and future 3D graphics architectures.
Finally, the OpenGL working group is working closely with the newly
announced OpenCL working group at Khronos to define full
interoperability between the two open standards. OpenCL is an emerging
royalty-free standard focused on programming the emerging intersection
of GPU and multi-core CPU compute through a C-based language
forheterogeneous data and task parallel computing. The two APIs
together will provide a powerful open standards-based visual computing
platform with OpenCL’s general purpose compute capabilities intimately
combined with the full power of OpenGL.
“OpenGL 3.0 is a significant evolutionary step that integrates new
functionality to ensure that OpenGL is a truly state-of-the-art
graphics API while supporting a broad swathe of existing hardware,”
said Barthold Lichtenbelt, chair of the OpenGL working group at
Khronos. “Just as importantly, OpenGL 3.0 sets the stage for a
revolution to come – we now have the roadmap machinery and momentum in
place to rapidly and reliably develop OpenGL - and are working closely
with OpenCL to ensure that OpenGL plays a pivotal role in the ongoing
revolution in programmable visual computing.”
More details on OpenGL 3.0 will be discussed at the OpenGL “Birds of a
Feather” meeting at SIGGRAPH in Los Angeles at 6PM on Wednesday August
13th at the Wilshire Grand Hotel. More details at
http://www.khronos.org/news/events/detail/siggraph_2008_los_angeles_california/.
*About OpenGL*
The OpenGL specification enables developers to incorporate a broad set
of programmable 3D and 2D graphics rendering and visualization
functions, and provides unfettered access to graphics hardware
acceleration. Since its introduction by SGI in 1992, OpenGL has become
the industry’s most widely used and supported programming interface
and is available on all major computer platforms, including Windows,
Linux and Mac OS. Controlled by the Khronos Group since 2006, and with
broad industry support, OpenGL is a vendor-neutral, multiplatform
graphics standard that is uniquely positioned to leverage and drive
the continuing evolution of graphics hardware.
*About The Khronos Group*
The Khronos Group is an industry consortium creating open standards to
enable the authoring and acceleration of graphics and dynamic media on
a wide variety of platforms and devices. Khronos standards include
OpenGL, OpenGL ES, OpenMAX™, OpenVG™, OpenKODE™, and COLLADA™. All
Khronos members are able to contribute to the development of Khronos
specifications, are empowered to vote at various stages before public
deployment, and can accelerate the delivery of their cutting-edge
media platforms and applications through early access to specification
drafts and conformance tests. More information is available at
www.khronos.org <http://www.khronos.org/>.
/Gordon/
__________________________________________________________
/Gordon Tomlinson
//Email / : gtomlinson @ overwatch.textron.com/
/
__________________________________________________________
//(C)//:/ (+1) 571-265-2612*
*(W)//:/ //(+1) 703-437-7651//
"Self defence is not a function of learning tricks
but is a function of how quickly and intensely one
can arouse one's instinct for survival"
- */Master Tambo Tetsura/*
------------------------------------------------------------------------
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
