GL Pipeline Newsletter vol 2 is up

For those who don’t actually read the front page, now might be a good time.

In any case, the new API’s coming, slated for summer 2007 (codenamed: Longs Peak). The new API will work on most (if not all) preexisting hardware. Extensions to that new API for G80/DX10 quality hardware will be coming fall 2007 (codenamed: Mt. Evans).

So, I’ve got one question: who comes up with these codenames anyway :smiley: Obviously, a mountain climber (they’re both mountains, for those who may not be aware).

So, everything seems to be in order so far. All those new extensions that nVidia just loosed for their G80 cards have a shelf life of approximately 1 year, so enjoy them while you can.

I do hope the next newsletter comes with a nice example source file. Or something of the like. I just want to see what it will look like (so I can start building wrapper classes :wink: ).

BTW, when is that SDK due out, and will it cover the new API? Oh, and might I make a suggestion with regard to the SDK:

The success of the DX SDK’s documentation doesn’t come from its extensive reference section, or the reams of source code that comes with it. No, it is the overview sections (hyperlinked properly with references where reasonable, of course) that make it possible to really learn DX programming just from the .chm file. Being able to read a document in a somewhat book-like fashion that explains what is going on where is perhaps the biggest benefit of DX’s documentation.

I would suggest that the ARB take heed of this and provide some appropriate in-between documentation between references and examples.

Wow, it looks like “Mt. Evans” is a complete overhaul!

Did I see a mention of HTML for the docs? This is awesome news.

P.S. I love the codenames :slight_smile:

Wow, it looks like “Mt. Evans” is a complete overhaul!
No, Longs Peak is the complete overhaul; Mt. Evans is just the DX10-level features added to that overhaul.

Mt. Evans is just the DX10-level features added to that overhaul.
And as such it’s a complete overhaul.

And as such it’s a complete overhaul.
You mean like how the recent extensions (gpu_shader_4, texture_array, etc) were a complete overhaul of everything that OpenGL was up to that point?

No, it’s an addition, an extension; it invalidates nothing. You use Longs Peak with Mt. Evans, not in place to. Just like you use gpu_shader_4 with glslang, not in place of it.

No, it logically follows that if Long’s Peak is a proper subset of the functionality that Mt. Evans offers (Mt. Evens is a super set of that functionality), and if Long’s Peak is an overhaul, then so is Mt. Evens, simply by virtue of implication.

You’ve got it backwards.

Longs Peak is to Mt. Evans as OpenGL 1.0 is to the EXT_vertex_array specification. Mt. Evans is an extension to Longs Peak, not a superset.

The OpenGL Mt. Evans release will be a continuation of OpenGL Longs Peak, with
a lot of new functionality added.
Hence: extension.

:smiley:

OK, Korval. You win this one. But I’ll be back!

whatever, theyre both pretty unimpressive
http://en.wikipedia.org/wiki/Mt._evans
http://en.wikipedia.org/wiki/Mt._evans
(still betterthan whistler / backcomb but not quite the impact of a everest / k2 / oylimpus mons. american mountains aint to impresive due to the continents great age still better than oz, Kosciusko’s got a footpath all the way to the top!!
btw interesting piece of info, read the other day a mountain in south america was the highest point in the world, something about hawaii )

that SDK due out, and will it cover the new API?
well duh :slight_smile: i agree a chm file is best (though a pdf is also nice) personally im not to excited about a SDK but im sure im in the minority

the new object model does look good
btw to khronos if u need someone write a small demo of a particular feature i dont mind doing it

yodellaaaee

Hi,

I just wanted to add something pertaining to the SDK and I hope that the ARB will respond.

The poll didn’t ask what people wanted in the SDK. Now, I like some others would like to see an implementation of OpenGL and how this would look on an OS. For example, the split between the driver and the OpenGL library, what entry points need to be provided. What an OSes window specific library needs to provide. Maybe even include some docs on this process.

Would this be Mesa or are the 2 new versions going to require different implementations?

I noted on here the other week that somebody was asking about where to start with implementing OpenGL for his own personal OS that he was writing. I think this would be invaluable information.

When creating language bindings to OpenGL it is currently a pain as they have to be created by hand or by copying and converting the C header files. It would be nice to have in 1 place a tool that takes as input some description file (XML/IDL/etc?) that can spit out bindings, including extensions. This tool must have source included so that new language back ends can be added. Yes, I worked on the Ada bindings.

Also, don’t use CHM files for the documentation, they’re just not portable to other operating systems. Not only that, they’re crap :smiley:

Thanks,
Luke A. Guest.

Originally posted by Lucretia:
[b] Hi,

When creating language bindings to OpenGL it is currently a pain as they have to be created by hand or by copying and converting the C header files. It would be nice to have in 1 place a tool that takes as input some description file (XML/IDL/etc?) that can spit out bindings, including extensions.

Also, don’t use CHM files for the documentation, they’re just not portable to other operating systems. Not only that, they’re crap :smiley:

[/b]
I thought the C header file was generated from a input script. (Perl/Python?) http://www.opengl.org/registry/ the gl.spec file.

I like chm files, But I believe the ARB is going to provide the data in multiple formats. (probably base XML format and others generated off that)

Now, I like some others would like to see an implementation of OpenGL and how this would look on an OS. For example, the split between the driver and the OpenGL library, what entry points need to be provided. What an OSes window specific library needs to provide. Maybe even include some docs on this process.
That is not something we should have in an SDK. Having source code for a sample implementation would be useful for a few applications, it should not be part of a general SDK for OpenGL users.

Also, don’t use CHM files for the documentation, they’re just not portable to other operating systems. Not only that, they’re crap
To me, a CHM is the most effective form of documentation. Encapsulated in one file for easy distribution, viewable on any Windows platform, and can be adapted to any format. It isn’t perfect (CHM viewers on non-Windows platforms are limited), but it’s the best documentation format we have.

That being said, multiple formats is always a good way to go. Just no man-pages; give me a DocBook XML file.

whatever, theyre both pretty unimpressive
You can’t judge a mountain by the size of her peaks.

Originally posted by Korval:
[QUOTE]viewable on any Windows platform, and can be adapted to any format. It isn’t perfect (CHM viewers on non-Windows platforms are limited), but it’s the best documentation format we have.

You just proved my point right there, it’s Windows specific, therefore not portable.

HTML and/or PDF’s only please.

Luke.

Originally posted by Lucretia:
HTML and/or PDF’s only please.

I agree. I don’t like chm. You can’t open a link in a new tab.

Originally posted by samantha:
[quote]Originally posted by Lucretia:
HTML and/or PDF’s only please.

I agree. I don’t like chm. You can’t open a link in a new tab.
[/QUOTE]CHM browsers, however, have searching functions, something that multipage HTML can’t have.

You’re not conjoined twins by any chance?
…and can I have your phone number?

Originally posted by penelope:
[quote]Originally posted by samantha:
[quote]Originally posted by Lucretia:
HTML and/or PDF’s only please.

I agree. I don’t like chm. You can’t open a link in a new tab.
[/QUOTE]CHM browsers, however, have searching functions, something that multipage HTML can’t have.
[/QUOTE]1) The searching “ability” even on Windows isn’t very good (hint, try searching within the page - you can’t)

  1. It’s not friggin portable! Not everyone uses Windows!

  2. HTML doesn’t have to be multipage.

  3. There is excellent searching within PDF’s.

Luke.

CHM browsers, however, have searching functions, something that multipage HTML can’t have.
grep -ri “glBegin” *
:smiley:

I don’t get why people are dragging this thread down with comparisons between document formats…? The newsletter clearly states it will use a number of formats…enough said.