PDA

View Full Version : Commentary on the ARB/OpenGL Newsletter



Korval
07-21-2006, 01:14 AM
I'm surprised that nobody's spoken about this (http://www.opengl.org/pipeline) , even though it's been on the main page for days.

In any case, here's my take.

Good:

* The existence of the newsletter itself. I'm very glad to see some form of communication out of the ARB.

* Bill Licea-Kane's section. Now, the information contained in his section on New Texture Functions frightens me to say the least. No, what I like about it is that someone's taking the time out to educate us on something that is an implementation detail so that we can avoid pitfalls in the future. This is all to the good, and I wouldn't mind seeing more in later newsletters/the SDK.

* Doing away with the old-and-busted OpenGL state-based object model. I'm all for that.

Neutral:

* ARB merging with Kronos. They didn't exactly explain what this would do for OpenGL very well. The substantive question, to my mind, that was not answered was, "Does this mean that greater resources will be devoted to OpenGL in the future?" The biggest problem with the ARB, from an outsider's perspective, seems to be just the lack of resources they have. They're a volunteer service; a member can't actually take the time to write an SDK, because each of these people have tasks for their respective companies to perform. Does Kronos have an actual Kronos-only staff that would be responsible for such tasks as the SDK?

Bad:

* The substance of Bill's article. Isn't this the kind of thing that an abstraction should, you know, abstract? Really, is this something that a high-level language should force upon the user? Sure, the user should have texture+derivative texturing functions. But for them to have to specify them explicitly just because of a varying in a conditional? It's not like a varying is a runtime-thing; you knew it was a varying when you compiled the shader. Come on, guys; you can do better than that.

* Doing away with the old-and-busted OpenGL state-based object model. That's going to be one brutally massive extension, if this will extend to all objects everywhere. It may as well be a new API, because that's what it will be.

* Speaking of which, absolutely nothing was said about the most important thing in that GameDev article: the new API. Is it coming? Is it going to be some ES/GL merger? What's going on in this department? The new API is the future of OpenGL; it'd be really nice if you could tell us something more substantial than that article did (like, whether it's still happenning, etc).

Comically Ironic:

* Superbuffers Working Group Update. They're making a new OpenGL object model. And the async guys are going to use it for their async thing. Good for all involved.

It's funny; I seem to recall that we already had a new OpenGL object model. It did everything that the Superbuffers people needed. It was even implemented and well-proven with the ARB-extension verison of glslang.

But the ARB decided to throw it away in favor of the old-and-busted state-based version. Allegedly because maintaining 2 object models would be considered confusing to the user (also funny, considering that's what they're doing now).

Maybe if they hadn't done that, and instead used the new one in all core 2.0 technologies, we wouldn't need to be making a second new object model.

Roderic (Ingenu)
07-21-2006, 02:56 AM
Looks interesting, I missed it so thanks for pointing to it :)

I'd like OpenGL 3.0 to be the OpenGL 2.0 "Pure" 3DLabs described, which is somewhat what OpenGL|ES 2.0 is.
A nice, clean API, even if it breaks compatibility would be welcome, we would still have current OpenGL drivers for 'legacy' apps and a new one for the new version... (which could also get us MS free on windows platform ?)

New Object model is really nice, I keep changing and restoring states in my engine to change a bunch of parameters here and there, quite annoying.
What I'd also like is the removal of Texture States in the Texture Objects, although I understand it can be useful, it's AFAIK not how the hardware works, and not how the other API works, so any abstraction compatibility layer wouldn't take advantage of the OpenGL model... (which isn't that great if you have per shader texture parameters)

ARB_sync is a nice addition.

Interesting infos in the Texture Functions & GLSlang article, but I agree with you Korval, isn't a high level shading language supposed to make our life simpler and abstract that kind of things ?
Isn't that something that can be done in the compiler ?

Jan
07-21-2006, 08:12 AM
Take a look at D3D10. In my oppinion, D3D9 was nice, but OpenGL was better in some points. Now D3D seems to remove all issues, which OpenGL doesn't have and it also seems to be a very nice and well designed API, which really leaps ahead.

I still like OpenGL better, because of its philosophy and clarity (theoreticall), but i think i will be switching to D3D10, just because it is much better than OpenGL is now, and experience shows, that it might take years for OpenGL to catch up. And experience also shows, that OpenGL always tries to be backwards-compatible, which usually is a nice thing (for CAD developers), but when it comes to incorporating new technology it can be a real pain in the butt.

I really hope, that there will be OpenGL 3.0, which makes a clean break and becomes competetive again. But i don't really see this happening in the near future and i don't want to play the "how long can you wait"-game again.

Jan.

Michael Gold
07-21-2006, 10:41 AM
Originally posted by Korval:
Doing away with the old-and-busted OpenGL state-based object model. That's going to be one brutally massive extension, if this will extend to all objects everywhere. It may as well be a new API, because that's what it will be.We are talking about OpenGL 3.0, which will introduce a new API while deprecating (but maintaining backward compatibility with) the old. The new API will likely appear in a series of extensions to OpenGL 2.x, as we migrate toward 3.0 and soak-test the new API.


Speaking of which, absolutely nothing was said about the most important thing in that GameDev article: the new API. Is it coming? Is it going to be some ES/GL merger? What's going on in this department? The new API is the future of OpenGL; it'd be really nice if you could tell us something more substantial than that article did (like, whether it's still happenning, etc).
Yes, its coming, its a big project and this is part of it.


It's funny; I seem to recall that we already had a new OpenGL object model. It did everything that the Superbuffers people needed. It was even implemented and well-proven with the ARB-extension verison of glslang.

But the ARB decided to throw it away in favor of the old-and-busted state-based version. Allegedly because maintaining 2 object models would be considered confusing to the user (also funny, considering that's what they're doing now).

Maybe if they hadn't done that, and instead used the new one in all core 2.0 technologies, we wouldn't need to be making a second new object model. The GLSL object model was a relatively incremental change over the legacy model and did not change enough to justify carrying the two models. The GL3 model is dramatically different.

If you're coming to SIGGRAPH, be sure to attend the OpenGL BoF on Wednesday night.

Robert Osfield
07-21-2006, 10:52 AM
Originally posted by Jan:
[QB] Take a look at D3D10. In my oppinion, D3D9 was nice, but OpenGL was better in some points. Now D3D seems to remove all issues, which OpenGL doesn't have and it also seems to be a very nice and well designed API, which really leaps ahead.
/QB]If D3D10 is good, then OpenGL can learn from it.

However, lets not forget D3D10 is only available for Windows Vista, which isn't even out yet. All D3D10 apps will only ever run on Vista, which will only be realistically available on new machines early 2007 onwards. It'll take a number of years before Vista has significant market share, till then its just a tinny niche compared to what OpenGL app can be rolled out on.

From new Kronos stewardship I would like to a real drive towards OpenGL 3.0 and bringing together OpenGL ES and OpenGL. Get prototypes out early, get the OpenGL community involved.

zeoverlord
07-21-2006, 04:14 PM
Originally posted by Robert Osfield:
If D3D10 is good, then OpenGL can learn from it.

However, lets not forget D3D10 is only available for Windows Vista, which isn't even out yet. All D3D10 apps will only ever run on Vista, which will only be realistically available on new machines early 2007 onwards. It'll take a number of years before Vista has significant market share, till then its just a tinny niche compared to what OpenGL app can be rolled out on. I have to agree to this, it will be a couple of years before D3D10 is commonly accepted as a viable platform, but during that time both Nvidia and ATI will have released their D3D10 hardware.
Along with that hardware comes a string of new openGL extentions that will provide most of the SM4/D3D10 functionality (though in a slightly more fragmented way).
So while SM4 for openGL will be mostly a patch job until openGL 3.0, it will still run on that hardware without vista, and that is a whole lot larger user base than D3D10 will ever have.

Korval
07-21-2006, 04:21 PM
The new API will likely appear in a series of extensions to OpenGL 2.x, as we migrate toward 3.0 and soak-test the new API.I don't suppose we'll be seeing those extensions any time soon. However, is there a general timeframe set for their release (early 2007, late 2007, etc)?

I'd love for the next newsletter to have a large article devoted to talking about the new API (hint hint;) ). The GameDev article was sketchy on the specifics, and I'd like to know what has changed/improved/etc since then.


If you're coming to SIGGRAPHI wish...

V-man
07-22-2006, 06:51 AM
Perhaps a roadmap should be created to see how GL will evolve.

D3D is becoming a nightmare. The SDK is limited to certain Windows versions and it's limiting to certain MS compilers. I'm talking about Dx9. What garbage. It has caused headaches for me.

It would be good if there was something for supporting truetype text in GLU. Nah, I don't want to use GLTF or whatever that crap is. It doesn't compile and there is no support.

Michael Gold
07-22-2006, 12:56 PM
The problem with GLU is that glu32.dll is a Windows component and has not been updated since 1997.

We're going to have to provide a replacement for GLU which can actually be updated.

Jan
07-23-2006, 03:27 AM
Originally posted by Robert Osfield:
If D3D10 is good, then OpenGL can learn from it.

However, lets not forget D3D10 is only available for Windows Vista, which isn't even out yet. All D3D10 apps will only ever run on Vista, which will only be realistically available on new machines early 2007 onwards. It'll take a number of years before Vista has significant market share, till then its just a tinny niche compared to what OpenGL app can be rolled out on.[/QB]I totally agree. However, i'm not concerned with platform independency, so i can just say, my app only runs on Vista, which is no option for many other people, of course. And also, i like D3D10 because it's an API i actually HAVE. I have Vista Beta and i have the SDK with documentation. Granted, it's in its early stage and it's software rendering only, but i can actually work with it and with MS pushing it that hard, i know, that it will become standard in a limited time-frame. We all know, that the people behind OpenGL are very skilled and a clompletely redesigned API might be even much better than D3D10, but at the moment that's all speculation. And the time-frame is unknown. I don't think that we will have OpenGL 3.0 in sooner than a year and changing an engine to make GOOD use of an entirely new API takes time. Good drivers also take time.

Well, if OpenGL 3.0 is from the broad concept close to D3D10 (everything virtualized, no FFP, state-objects, texture-arrays, ...) it shouldn't be too difficult to support both, when it's available.

Jan.

Robert Osfield
07-23-2006, 05:41 AM
Originally posted by Jan:
I totally agree. However, i'm not concerned with platform independency, so i can just say, my app only runs on Vista, which is no option for many other people, of course.
Few people have the luxury of writing software for a beta platform, that even once its released will be years before it has significat market share.



Well, if OpenGL 3.0 is from the broad concept close to D3D10 (everything virtualized, no FFP, state-objects, texture-arrays, ...) it shouldn't be too difficult to support both, when it's available.
Jan. Well if OpenGL 3.0 does achieve this then D3D10 becomes enitrely redudent, you only need to target it to get all the feature you want. The bonus of this your are able to develop and deploy on many many more platforms.

Khronus need to sell the very real benefits of OpenGL, and they need to get moving on OpenGL 3.0.

The graphics community also needs to support Khronus in this work, spread the message, help develop and test the emerging API and implementations.

Personally I'd be happy to have some beta API published for OpenGL 3.0 which like D3D10 are largely software based, and perhaps layering over the top of OpenGL 2.0/OpenGL ES2.0. Then get middleware developers like myself testing the API out and help debug it/refine it. At the same time as this we need IHV's to step up and implement the back ends to get everything working natively in hardware.

Unfortunately I won't make it to SIGGRAPH this year, but I look forward to hearing of progress. More news letters, and more direct engangement of the OpenGL 3.0 developers would be very welcome.

And to Khronous members, support US and we'll support you :-)

Robert.

plasmonster
07-23-2006, 11:06 AM
Thanks for the link. I usually make a b-spline for the forums and miss the latest news on the main page.

The newsletter is really nice--hope to see many more. I was struck by the section on the Ecosystem Working Group, and its charter to, among other things, oversee development of an OpenGL SDK.

I'm really looking forward to seeing the new API. As a big fan of occasional reinvention, this is all very exciting!

Korval
07-23-2006, 11:53 AM
Few people have the luxury of writing software for a beta platform, that even once its released will be years before it has significat market share.I wouldn't say that it will take years before it has a significant market share; that won't take more than a few months. However, because DX10 is Vista only, a DX10 app is Vista only. It will take years before Vista is in such a dominant market position that game developers (that aren't owned my Microsoft) can afford to make their games Vista only.

3k0j
07-23-2006, 05:39 PM
Originally posted by Jan:
Well, if OpenGL 3.0 is from the broad concept close to D3D10 (everything virtualized, no FFP, state-objects, texture-arrays, ...) it shouldn't be too difficult to support both, when it's available.what's 'virtualized' in D3D10?

zed
07-23-2006, 06:27 PM
i typed "winxp marketshare" into google + get the following
http://www.w3schools.com/browsers/browsers_stats.asp
( now i dont know how accurate these figures reflect game players, prolly to high win2000 number )
fwiw winxp launched 25 oct 2001 and had ~30% march 2003.
i doubt we'll be seeing any big d3d10 games (except as korval points out ms ones eg halo2) until 2008 at the earliest
i believe the xb360 d3d >= 9.0c but less than d3d10

Jan
07-24-2006, 01:59 AM
Originally posted by 3k0j:
what's 'virtualized' in D3D10? The whole memory handling. That means all resources, ie. textures, vertex-buffers, framebuffers, and so on. There are no "lost surfaces" anymore (a problem that GL never had), render-to-texture/vertexbuffer is as easy as it should be, the fixed-function pipe is gone, there are no texture-units, you bind your textures to a "shader-semantic" (by name) and you can use arrays of textures (which one would today do by putting them into a 3D texture or a texture-atlas to freely access several textures on one texture-unit - of course this has lots of disadvantages).

Jan.

Jan
07-24-2006, 02:04 AM
Even if D3D10 is no option for you, it's an interessting read, because it's a preview of what's possible in the near future.
Therefore, if you want to know more, download the latest DirectX SDK, you don't need Vista to read the documentation about D3D10.

Robert Osfield
07-24-2006, 03:31 AM
Originally posted by Korval:
I wouldn't say that it will take years before it has a significant market share; that won't take more than a few months.
How big is significant? 10%? If we assuming that that w3schools stats for WinXP as a base then this will likely take six months.



However, because DX10 is Vista only, a DX10 app is Vista only. It will take years before Vista is in such a dominant market position that game developers (that aren't owned my Microsoft) can afford to make their games Vista only. This is a great opportunity of OpenGL 3.0, rather than target DX9 and DX10 in you app, just use OpenGL and you'll be able to run everywhere with just one API, it'll be able to blitz the market share that DX10 can address in no time at all.

Personally I'd encourage Khronous to push ahead with a clean OpenGL 3.0 prototype, and don't worry about backwards compatibility, time to market is more important, its D3D10 that you are competing against.

Backward compatability if it can truely be layered can be done as an open source add on to OpenGL3.0. Could MESA be picked up and ported to sit on top of the OpenGL 3.0 prototype? Could another open source project be spawned to do this?

There is also the other side, extensions to OpenGL 2.x that encompass some of the new functionality in hardware, these too need to happen in parallel to OpenGL 3.0 effort, focussing on existing OpenGL apps that would like to add a little extra functionality without major restructing.

Then a couple of years down the line when the OpenGL 3.0 is a stable API and implementation, and the open source layer on top is mature existing OpenGL 2.x apps will just be able to port across with little effort.

Another aspect to consider is the growth of languages like Python, Ruby and Lua for rapid app developement. Perhaps if one supports the development of languages wrappers early on in the life of OpenGL 3.0 you'll be able to ride the wave of these development communities as they take software engineering off in new directions.

We need a bit of hussle and excitment around OpenGL, its already one of the coolest API's on the planet, and able to awsome things on so many platforms. Lets see a unified OpenGL ES and OpenGL, lets see OpenGL 3.0 prototypes out early, and thriving development communities built around it.

Robert.

Korval
07-24-2006, 10:56 AM
Another aspect to consider is the growth of languages like Python, Ruby and Lua for rapid app developement. Perhaps if one supports the development of languages wrappers early on in the life of OpenGL 3.0 you'll be able to ride the wave of these development communities as they take software engineering off in new directions.OpenGL, and probably not even the SDK, should even consider touching these. You want RAD 3D, make an official .NET OpenGL implementation (or get the Mono guys to do it for you). But delving into scripting languages is not something that the ARB/Kronos should be bothered with.

Robert Osfield
07-24-2006, 01:07 PM
Originally posted by Korval:
OpenGL, and probably not even the SDK, should even consider touching these. You want RAD 3D, make an official .NET OpenGL implementation (or get the Mono guys to do it for you). But delving into scripting languages is not something that the ARB/Kronos should be bothered with. Creating wrappers is pretty easy with OpenGL being plain C. It takes a couple of lines of Swig interface code to build language bindings for all the main languages.

This needn't be done by Khronos members, but it needn't be a big distraction. The SDK effort itself could/should involve the wider community too.

ffish
07-24-2006, 11:07 PM
I'd imagine it'd be pretty simple to create Python bindings for OpenGL extensions with boost::python too. It definitely made embedding and extending our app relatively easy.

Overmind
07-25-2006, 01:30 AM
IMHO it should be the responsibility of the scripting language itself to provide GL bindings.

As you said, providing bindings for a single language is no problem. So it should be no problem for the developers of scripting language XY to provide GL bindings if they want their language to be usable for 3D graphics.

On the other hand, the ARB (or Khronos) would have a lot of work providing and maintaining bindings for many different scripting languages.

Robert Osfield
07-25-2006, 04:10 AM
Originally posted by Overmind:
IMHO it should be the responsibility of the scripting language itself to provide GL bindings.

As you said, providing bindings for a single language is no problem. So it should be no problem for the developers of scripting language XY to provide GL bindings if they want their language to be usable for 3D graphics.

On the other hand, the ARB (or Khronos) would have a lot of work providing and maintaining bindings for many different scripting languages. Its always good to push the responsibility to someone else... The developers of the various languages have plenty work themselves without taking on wrapping all APIs out there.

Khronus member too have plenty of work to do just on their core API's and implementations.

So who should be responsible? Well if Khronus wants an SDK that supports the developer eco system then supporting non C lanaguages is one place to start. However, I don't believe the SDK should be sole responsibility of the Khronus members, we the OpenGL developer community should help out. Developing the SDK as an open source project would fit this bill.

One benefit of using other languages in the mix is testing, its real easy to write and maintain test scripts.

Note, I say this as a once die hard C++ advocate.

Overmind
07-26-2006, 02:08 AM
If you take for example Python, you'll see that it provides a lot of bindings for native c libraries. They are supplied either by the core Python package, or by some independant project, but not by the c library itself. Why should it be different for OpenGL?

Of course it would be convenient to just put the load on Khronos, but I'd rather see them invest their time in more important things, and leave the trivial things to someone else. If the Python commutity wants OpenGL, let the Python commutity provide bindings.

Btw. there are actually Python GL bindings, and I'm sure there are a lot of GL bindings for other scripting languages. I really don't see the need for an "official" binding supported by OpenGL, bindings supported by the respective language are more than enough.

tarantula
07-26-2006, 04:11 AM
For those of us not being able to come to siggraph, it would be nice to have a webcast of the OpenGL BOF.

Robert Osfield
07-26-2006, 06:02 AM
Originally posted by Overmind:
If you take for example Python, you'll see that it provides a lot of bindings for native c libraries. They are supplied either by the core Python package, or by some independant project, but not by the c library itself. Why should it be different for OpenGL?I for one would like to alpha releases of OpenGL3.0 out early, following the release early release often that works well for Open Source projects.

For outside projects it would difficult to track this, and one shouldn't expect them. However, if one automates the support it, as its easy to do, then its not a great burden to run an script to build the binding and then publish them, this could be done by Khronus or those closesly following the OpenGL3.0 development.

I believe the SDK should encompass this, perhaps even have the scripts for building the wrappers. Again the SDK shouldn't just be Khronous members developing, it should encourage wider contributions, its should be an open source project.

If Khronous wants to promote OpenGL and their other API's then it needs to work in the end user terms, it should serve and work closely with the developer community. C and C++ developers are now in the minority, one has to sell to users of the other langauges too.

I am willing to pitch in and help out with an OpenGL SDK and to test out OpenGL 3.0, I'm sure others would be more than willing to. I don't have a huge amount of free play left in my schudule but with important things you just have to go the extra mile. With my own project, the OpenSceneGraph, being a pure OpenGL based library, the success of the OpenSceneGraph in the future depends upon the success of OpenGL.

Robert.

Korval
07-26-2006, 09:07 PM
The GLSL object model was a relatively incremental change over the legacy model and did not change enough to justify carrying the two models. The GL3 model is dramatically different.Something I meant to ask about this. Exactly what is it about the old glslang object model that is different from the GL 3.0 model? What does the new one do that the old one couldn't?

The GameDev (http://www.gamedev.net/columns/events/gdc2006/article.asp?id=233) article mentioned these four points:



* Object ID is a pointer instead of an uint (typedef void* GLobject)
* Object IDs are always generated by implementation
* Object manipulators take an explicit parameter (no more binding)
* Objects are immutable
All of these were served by the old glslang object model.

Overmind
07-27-2006, 03:58 AM
I think the key points here are:
1) Everything will be in an object, not a mix between state based and object based.
2) The draw commands will have an object parameter, too. There will be no "current" object for drawing.

Korval
07-27-2006, 10:22 AM
1) Everything will be in an object, not a mix between state based and object based.
2) The draw commands will have an object parameter, too. There will be no "current" object for drawing.That doesn't explain the need for a new model; that's more about how the API uses the object model. You could just as easily use GLHandleARB objects for such APIs as this new GLObject. Indeed, you could use the old texture-object model with such an API (not that I'm suggesting that it would be a good idea). The two concepts are separate from one another.

Michael Gold
07-27-2006, 12:07 PM
Originally posted by Korval:
The GameDev (http://www.gamedev.net/columns/events/gdc2006/article.asp?id=233) article mentioned these four points:



* Object ID is a pointer instead of an uint (typedef void* GLobject)
* Object IDs are always generated by implementation
* Object manipulators take an explicit parameter (no more binding)
* Objects are immutable
All of these were served by the old glslang object model. Your claim is inaccurate.

GLSL "handles" are uint, which means they cannot be opaque pointers (think 64-bit).

GLSL objects may be modified arbitrarily. A key property of the new object model is immutability.

The GLSL object model did nothing to modify the sharing mechanism.

Korval
07-27-2006, 12:19 PM
GLSL "handles" are uint, which means they cannot be opaque pointers (think 64-bit).They were? I could have sworn they were void*'s. Or maybe I was just thinking that they should have been...

Oh well.

Speaking of 64-bit, how is OpenGL going to handle that? I mean, GLInts are ints, which are defined by ANSI C to be the native word size, but defined by Microsoft to be 32-bits (for good reason, mind you). Is OpenGL 3 or some new GL header or something going to have some way of specifying a 32-bit integer?


GLSL objects may be modified arbitrarily. A key property of the new object model is immutability.What does it mean for the objects to be immutable?


The GLSL object model did nothing to modify the sharing mechanism.Fair enough. Does the new object model make some effort to differentiate between shareable objects and non-shareable objects without having to look up which is which (like having unshared objects be of type GLUnsharedObject rather than GLObject)?

Michael Gold
07-27-2006, 02:21 PM
Originally posted by Korval:
Speaking of 64-bit, how is OpenGL going to handle that? I mean, GLInts are ints, which are defined by ANSI C to be the native word size, but defined by Microsoft to be 32-bits (for good reason, mind you). Is OpenGL 3 or some new GL header or something going to have some way of specifying a 32-bit integer?
Table 2.2 of the OpenGL 2.0 specification defines GLint as a minimum of 32 bits. An implementation is free to use a larger native size, but in practice I imagine most vendors will define types to match the specified precision. Microsoft's gl.h defines GLint as int, so as long as the compiler considers int 32-bit, that's what it will be on Windows.

GLint is likely to remain 32-bit for the forseeable future.

By the way, the EXT_timer_query extension introduces new types: GLint64EXT and GLuint64EXT. These are guaranteed to be 64-bit minimum.


What does it mean for the objects to be immutable?It means the structural properties of the object may not be modified after creation. For example, the current mode allows you to redefine the dimensions of an existing texture object by calling TexImage or CopyTexImage. There is no good reason to allow this and its a burden on the implementation, so we're going to disallow this in the new model.


Fair enough. Does the new object model make some effort to differentiate between shareable objects and non-shareable objects without having to look up which is which (like having unshared objects be of type GLUnsharedObject rather than GLObject)? No - sharability is a per-object property. You cannot distinguish between a share and non-shared object without querying this property, or remembering that you set it in the first place. No objects are shared by default, you must specify this immutable property when you create the object.

Chris Lux
07-27-2006, 02:59 PM
hi,
at first i have to say how much i like the new newsletter idea. i hope it holds be the quarterly timescale.

even if there was nothing totally new in there it is good to see that OpenGL is alive and many things are worked on.

to the concern with the new object model. sure it will be a big extension, but i have to bring my thoughts again about doing a split development of the api. a 'pure' OpenGL 3.0 LM profile development with the OpenGL 3.0 standard profile (OpenGL 2.x) development in parellel. maybe skip out the parts that would be to hard to make backwards compatible. this way it could be made sure that no compatibility reasons skrew up the new API.

so now keep up the good work OpenGL ... ARB... or Khronos ... ;)

Korval
07-27-2006, 05:11 PM
No objects are shared by default, you must specify this immutable property when you create the object.I see. The GameDev article said that large objects (textures, buffer objects, etc) would be shared but small objects wouldn't. I'm glad to see you just decided to let us decide at creation time if they would be shared.

Is there an expected performance penalty or memory overhead to shared objects? Like shared object (because the user asked them to be shared) have mutex's on them that allow them to be safely used in multithreading cases, so you should only share when you mean it.

Michael Gold
07-27-2006, 05:37 PM
Originally posted by Korval:
Is there an expected performance penalty or memory overhead to shared objects? Like shared object (because the user asked them to be shared) have mutex's on them that allow them to be safely used in multithreading cases, so you should only share when you mean it. This is an implementation detail but there are at least two possible costs to sharing objects:
- Mutex overhead
- Keeping object state in sync if sharing requires multiple internal copies

The need to share objects is relatively infrequent but everyone has to pay for the fact that objects could be shared. We like this model where the sharing granularity is per-object because it gives you the flexibility you require while allowing us to avoid the overhead when no sharing is required.

knackered
07-28-2006, 11:06 AM
I'd like to see some sample programs written in this proposed API.

Michael Gold
07-28-2006, 03:20 PM
Patience, Grasshopper. :)

Frogblast
07-28-2006, 10:46 PM
gold, is the spec going to attempt to define the exact behavior of shared objecs (beyond the idea that 'they can be shared'). My understanding is that the existing spec mostly leaves this open to the implementation.

Specific behavior questions, assuming that ctx1 edited a shared object, and ctx2 wants to use it:

- What synchronization is required on ctx1? I assume the common answer is glFinish, although this isn't true on all platforms today.

- What operations, if any, may be required on ctx2 for the changes to become visible?

- Will it be unsafe to modify an object in ctx1 while simultaneously using it from another context (beyond the specific order of execution being undefined). i.e., will the implementation have to internally synchronize on every read/write, or can this be considered a potentially fatal App Error, to preserve performance?