The OGL2.0 specifications emphasize on how the new API needs to be released shortly, while chapter 9.6 of the new shading language tells shaders won’t be available until one or two GPU generations.
Does that mean this “short” release will occur, say, 2 years from now ? :’(
Julien.
The 2.0 API isn’t dependant on the existence of a hardware implementation. We’ll see software implementations much sooner; slow, sure, but still useful for development and non-realtime rendering.
And a GPU “generation” is around 6 months at the moment.
And a GPU “generation” is around 6 months at the moment.
Add delay until such GPUs become mainstream, and you will get closer to deepmind’s 2 years.
It is really sad, i think big part of gl2.0 could be implemented for existing hardware.
I don’t want to wait for unification of interfaces until new generation of HW arrives.
What about “OpenGl 1.99” ?
Part I: Take from gl2.0 all what can be implemented in todays HW
I mean gl2.0’s Object Framework + Memory Managment + Synchronisation.
Take it as they are in gl2.0, with no single change in their syntax.
Instead, implicitly limit their functionality to fit todays hardware :
Part II: Simpler Shaders
gl2.0’s shaders will have to wait until HW can handle them.
So define simple, HW-dependent, assembler languages that could work on todays hardware
(embrace NV_vertex_program/DirectX 8/8.1 style)
But use them with new interface : create/load/compile shaders as it is already defined in gl2.0.
No implicit multipass, no virtualization of hardware.
Vertex Shader: could be the “unified Vertex Program”, the one that is considered to arrive in gl1.4
Fragment Shader: could be DirectX Pixel Shader style assembler language that would handle:
With this all transition to full gl2.0 one day would be so natural…
[This message has been edited by Carmacksutra (edited 02-26-2002).]
[QUOTE]Originally posted by Carmacksutra:
Add delay until such GPUs become mainstream, and you will get closer to deepmind’s 2 years.
But the OP wasn’t about mainstream hardware support, it was about a release date for the API specification. I suspect “mainstream” GL2 support will be closer to 3 years in coming, but so what? People were doing useful work with GL1.x long before any mainstream hardware supported it.
I strongly suspect that high-end hardware will have pretty good GL2 support within a year. And given the length of product cycles, that support should have filtered down by the time GL2-based products start appearing.
Don’t worry. Be happy.
The OpenGL 2.0 white papers are a vision for what graphics hardware should be able to do in the future. It is not an API that tries to fit what todays hardware can do. Given that, there are the obvious questions brought up here. How to get this all implemented in a timely fashion?
This topic will be discussed at the ARB meeting next week. We hope that the ARB will go along with a proposal we have. Obviously this proposal will only address how to phase in the OpenGL 2.0 API, not each company’s own implementation plans of that API. Note that not necessarily everything in the white papers will have to be approved by the ARB labelled as ‘OpenGL 2.0’. There is always OpenGL 2.1.
Yes, IHVs probably will have to provide incremental steps towards full OpenGL 2.0 implementations. If that is going to be in the form of software implementations, extensions, or otherwise is up to the IHV to decide.
Barthold
3Dlabs
A more reasonable approach might be to just take the parts out of 2.0 that can be supported now and introduce them as ARB extensions to 1.3 (or quickly whip up 1.4). Dumbing down 2.0 would just be wrong.
zeckensack,
Perhaps I badly express myself in English;
What you wrote is equivalent to what I called gl 1.9 (the only difference would be existence of “ARB” sufix in names)
I just wanted to say that new shaders are great, but cleaning & unifing the interface is more urgent. And it could be done now.
So it is not dumbing down gl 2.0, but just proposition of more gradual migration to full gl 2.0