PDA

View Full Version : ATi and nVidia working together to make OpenGL 3.0



Korval
03-25-2006, 10:32 AM
According to this (http://www.gamedev.net/columns/events/gdc2006/article.asp?id=233) , ATi and nVidia are about to propose a radical change/non-change to OpenGL.

They want to build a lower-level API and then layer 2.x GL functionality on top of that. This has obvious advantages, as specified in the document.

Personally? I'm all for it. I didn't know that the GL object model took up 3-5% of the driver's time, so I'm happy to see it go.

And for those who need legacy functionality, it can be layered on top.

knackered
03-25-2006, 11:31 AM
Firstly, why was the other thread on this subject closed by a moderator? If you think it's in the wrong place, move it to where you think it should be, don't just slam the door shut, it's too important.
Now, on-topic:
Yes I agree it's a great list of suggestions. Core OpenGL as it stands is no longer a true hardware abstraction, so it needs culling.

skynet
03-25-2006, 12:23 PM
I really hope, this is going to be what GL 2.0 was supposed to become. I´m a bit afraid that the specification process will take too long and we won´t see anything conrete in the next two years... But this time they have the advantage not to be concerned about backwards-compatibility. Hopefully this will result in a modern and efficient API.

"Core OpenGL as it stands is no longer a true hardware abstraction, so it needs culling."

What does that mean?

Roderic (Ingenu)
03-25-2006, 12:36 PM
Originally posted by skynet:
"Core OpenGL as it stands is no longer a true hardware abstraction, so it needs culling."

What does that mean? My understanding is that the OpenGL API is too far from the hardware now that it is all programmable.
It needs be cleaned up, rethought, restructured and simplified.

skynet
03-25-2006, 12:55 PM
Ah, didn´t get the irony in it ;-)

Korval
03-25-2006, 06:14 PM
There is definately quite a bit of cruft in the OpenGL API. An enema is not unreasonable.

Things that were a good idea in 1992 aren't necessarily a good idea in 2006. And I kinda like the fact that the Kronos group will be taking over OpenGL. That way, it's not bound to SGI in any real fashion.


It needs be cleaned up, rethought, restructured and simplified.One thing I really like about their proposal is the fact that it is significantly based on making the OpenGL API easier for IHVs to implement.

For a long time, pretty much since its inception, OpenGL has been designed specifically around what developers want. Now, we're seeing IHVs pushing for an OpenGL that makes their jobs easier. That in turn promotes better OpenGL implementations, which ultimately makes us, the developers, jobs easier. Which in turn makes everyone happy.

zed
03-25-2006, 06:16 PM
Personally? I'm all for it. I didn't know that the GL object model took up 3-5% of the driver's time, so I'm happy to see it go.more than i guessed as well, my worry is this. "Easier to manipulate, but also easier to crash" i can see some beginners having problems.
on the whole though most of the changes look to be improvements.

V-man
03-25-2006, 08:08 PM
I think we have all wanted to be "Lean and Mean", in other words, only stay on the fast track.


My understanding is that the OpenGL API is too far from the hardware now that it is all programmable.
It needs be cleaned up, rethought, restructured and simplified.Yes, and also there are parts that are really old. Weird functions like glRect() and glInterleavedArrays() should be killed off.
Functions like glFrustum, glOrtho, glCliPlane should have floats versions and the double version of functions should be killed off until such hw becomes available.

Mikkel Gjoel
03-25-2006, 09:17 PM
I agree there's a lot of good stuff in there. But: The day display-lists and immediate-mode die, is the day I switch permanently to direct3d. Removing display-lists and adding geometry instancing is a definate step in the wrong direction :( I see some of the items on this list as removal of sound opengl-functionality to ease driver-implementation: If Microsoft have decided you need to implement a feature for direct3d it's easy to add a hook for gl too. If it's not in d3d, you have to do actual work. I fear the best design will not result from a joint effort between ATi/Nvidia as they would see direct financial gain from limiting the differences between d3d/gl: Less differences mean less polarized driver-development.

Smokey
03-25-2006, 10:21 PM
I think the move to The Khronos group taking over OpenGL specification is by the the best move I've seen made in years. Once this technicallity is official, I believe we'll start to see a far more rapid development cycle of the OpenGL specification.

As for OpenGL LM, all I have to say is "I can't wait!" :)

Michael Gold
03-25-2006, 11:28 PM
Originally posted by Mikkel Gjoel:
Removing display-lists and adding geometry instancing is a definate step in the wrong direction :( I am very interested in feedback on these points and would like to understand your concerns.

The goal is not to remove dlists as they exist today but to introduce a new mechanism which limits the scope to the parts that are actually useful and optimizable. For example today a legal dlist may contain: "Vertex(); Vertex(); End();" and may be called as "Begin(); Vertex(); CallList();". There is nothing the driver can do to optimize this, its a simple macro recorder and playback mechanism. Further, COMPILE_AND_EXECUTE is an abomination which differs enough semantically from COMPILE followed by CallList() that the implementation needs to special case it - a lot of complexity and overhead that in practice, nobody really cares about.

As for immediate mode, nobody is proposing to remove it, rather to acknowledge the fact that its highly inefficient and difficult to optimize; its nice for prototyping but bad for performance. If the functionality remains available but layered, is that so bad? It wasnt fast to begin with, and never will be.


I see some of the items on this list as removal of sound opengl-functionality to ease driver-implementation:Again, ease of implementation is only one of the overall goals. We're acknowledging the fact that providing an abstraction which no longer looks like the hardware does no favors for either developers or the implementors. The thicker the layer between the app and the hardware, the more CPU overhead and the more likelihood of driver bugs. Exposing the fast paths is meant to be a win-win.

Remember, back in the old days OpenGL was intended as the thinnest possible abstraction over hardware to allow portable graphics applications; it was never meant to be a utility library. The more hardware has changed, the thicker this abstraction has become. We're trying to get back to basics.

Michael Gold
03-25-2006, 11:35 PM
Originally posted by zed:
more than i guessed as well, my worry is this. "Easier to manipulate, but also easier to crash" i can see some beginners having problems.The proposal also includes a debugging mode built into the implementation which can provide the "idiot proofing" names give you but can also be disabled for maximum performance. Think of it like asserts; you want them to catch errors during development but you don't want the runtime overhead once you ship a release.

Overmind
03-26-2006, 03:54 AM
I see some of the items on this list as removal of sound opengl-functionality to ease driver-implementationAs I understood it, nothing is really on a "removal" list. These things will not be in OpenGL LM, but they will still be in the full profile. The difference is that the driver writers don't have to be concerned with the implementation, because it's implemented on a layer between the application and the driver.

One question comes to mind there:

Who will write this "full OpenGL on top of OpenGL LM" implementation? As I understood it, this would be something that could be done hardware-independant.

Also, I sense the opportunity to get a new "opengl3.dll" on windows (one can still dream :p ).

Roderic (Ingenu)
03-26-2006, 04:15 AM
To add to what I said, I was really waiting for OpenGL 2.0 "Pure", a simplified consolidated OpenGL Layer that unfortunately never came.
It seems to me that OpenGL 3.0 is "just" that.

Also, simplifying the life of IHVs drivers team is something I'm all for, as long as it's not at the expense of the programmers...

For a moment I did wonder whether OpenGL 2.0 ES would become the standard, as it's already a cleaned up subset of OpenGL with most (but not all) required capabilities...

MikeC
03-26-2006, 05:36 AM
Originally posted by Ingenu:
Also, simplifying the life of IHVs drivers team is something I'm all for, as long as it's not at the expense of the programmers... I'm all for it even if it is at the expense of the programmers. Convenience can be layered on top, either by the programmer or through utility libs. Driver bugfixes, by and large, can't.

Two miscellaneous thoughts:

1) What's the current status of the legal agreement that precluded anyone but Microsoft from shipping opengl32.lib/.dll for Windows? If it still holds, and if the price of sidestepping that agreement is a name change, this is probably as good a point to do it as any. I've heard from several OpenGL toe-dippers that having to use GL2 as 1.1+extensions is severely offputting.

2) The column that started all this mentions in the first para that "Unfortunately I was only able to attend the first half". Does anyone know if there was more juicy news in the second half, and if so, could they post details?

Jan
03-26-2006, 05:55 AM
I never understood why it should be legal to use a texture id, that you didn't generate previously. What did they smoke back then to allow such a complicated but completely useless "feature"?

Also, in some cases there is too much flexibility. For example i was always thinking, if there is a most hardware-friendly layout for vertex-arrays. Meaning, if it does matter to the hardware in which order i store my position/color/texcoord/.. data. Maybe it doesn't matter. But if it does, i want OpenGL to encapsulate it, so that i just say "here is the data, store it in the format you like best". Just as textures are stored in the way the hardware likes best.

In some cases flexibility is nice. For example i really wouldn't want to work without immediate mode. It's just so useful to be able to simply render a few quads, even if it's the slowest way possible.

I use display lists only for rendering text. And i think they make life very easy in this case. However, in general i think display lists could be layered.

However, in many cases flexibility makes life more complicated. It's nice to do something the way you like best. But the moment you try to do it most optimal, you have a problem, because you don't know, which is the most optimal way (and for which hardware??). So, in my oppinion, when a feature is performance critical, it should be very strict about how to use it, so that the driver only needs to handle and optimize ONE way, not 10.

I think OpenGL is very user-friendly and easy to learn. At least the basics. With all the extensions, many different ways to achieve the same thing and too much flexibility, the more advanced stuff is actually quite complicated. I think a "Lean and Mean" OpenGL would not only simplify and speed up drivers, but also make it easier for everybody to get to the fun-stuff.

And PLEASE, do it fast! OpenGL is dying a slow death for a long time now. We really need this.

Jan.

PkK
03-26-2006, 06:49 AM
Display lists may be a bit difficult to implement, but I think the very general mechanism offers the potential for future driver optimizations. I think they should stay.

Other things like immediate mode or the fixed vertex and pixel pipelines should be layered on top. They are nice for simple applications and learning OpenGL.

Philipp

Komat
03-26-2006, 07:53 AM
Display lists may be a bit difficult to implement, but I think the very general mechanism offers the potential for future driver optimizations.
While I am not driver writter I would assume that the display lists are big pain in the ass to get correctly not even optimize them and they complicate lot of other code. They are too general for their own good. Because of this complexity they can not be easily represented as copy of command buffer send to the hw so anything ever optimized imho were simple geometry only lists and for this reason people mostly used them to store the geometry only.

Michael Gold
03-26-2006, 08:13 AM
Display lists are not particularly difficult to implement, but they are apparently easy to misuse. They should stay, and will in this proposal, but they may be redesigned to preclude some of the existing pitfalls.

knackered
03-26-2006, 10:56 AM
Display lists are brilliant.
They offer the driver the opportunity to remap the vertex/index data into an implementation dependent optimal format, stitch together tristrips, convert int32's to int16's, re-sort vertices into cache coherent order, calculate bounding volumes for potential better-than-application hardware culling etc.etc.
The NVidia quadro display lister is absolutely brilliant - I can't get near the same performance by trying to optimize the user specified data myself, in the same kind of time frame.
Fair enough, limit its functionality by removing nesting, transforms, material changes or whatever, but leave the geometry stuff, because some IHV seem to do a really good job with it.

Michael Gold
03-26-2006, 12:55 PM
but leave the geometry stuff, because some IHV seem to do a really good job with it.Yes, absolutely. if you look at the gamedev link which summarizes the GDC presentation, under the section which mentions display lists as candidates to move out of the LM profile, is another section which discussions replacements and additions:

Geometry-only display lists (for small static data, for instance) (no GL_COMPILE_AND_EXECUTE, since it's very problematic to implement efficiently)

V-man
03-26-2006, 02:34 PM
Originally posted by MikeC:

1) What's the current status of the legal agreement that precluded anyone but Microsoft from shipping opengl32.lib/.dll for Windows? If it still holds, and if the price of sidestepping that agreement is a name change, this is probably as good a point to do it as any. I've heard from several OpenGL toe-dippers that having to use GL2 as 1.1+extensions is severely offputting.
I didn't see anything about sidestepping.

What would give toe-dippers the impression they are using core GL instead of GL 1.1+extensions?

MikeC
03-26-2006, 04:45 PM
Originally posted by V-man:
What would give toe-dippers the impression they are using core GL instead of GL 1.1+extensions? I may be putting words in their mouth - it was a brief conversation - but I think they expected to be able to just #include a .h, link to a .lib and have up-to-date API features available out of the box.

Korval
03-26-2006, 05:53 PM
I may be putting words in their mouth - it was a brief conversation - but I think they expected to be able to just #include a .h, link to a .lib and have up-to-date API features available out of the box.Well, just have them download a second library and link to a second header. One of the many extension loading libraries out there.

MikeC
03-27-2006, 12:28 AM
Originally posted by Korval:
Well, just have them download a second library and link to a second header. One of the many extension loading libraries out there. Korval, you know that, and I know that, but to beginners it's not obvious a) that they should, b) why they should or c) why there's a choice of umpteen different extension libs for a standardized API.

How many "where can I get OpenGL 1.x/2.0" threads have we seen in Beginners over the years?

Korval
03-27-2006, 01:49 AM
Korval, you know that, and I know that, but to beginners it's not obvious a) that they should, b) why they should or c) why there's a choice of umpteen different extension libs for a standardized API.I understand the problem. But there is no solution to it. Even if you made a new GL 3.0 lib, it'd be outdated with GL 3.1 features.

knackered
03-27-2006, 02:01 AM
<aside>
How the API is physically delivered is a completely different topic, and quite a boring one. Start a new thread if you want to turn your faces blue. I'm assuming 'gold' is from either nvidia or ati, and hence could be used as a mouth piece on the future of the OpenGL API, so shut up about the bloody header/lib thing.....please.

<on-topic>
gold, I did read that about display lists, but just wanted to enphasise that I do actually use display lists for geometry optimization, so please speak up for their continued inclusion.
Apart from that, I think what should definitely be included is a mechanism for querying the best formats/setups for a specific implementation.

tarantula
03-27-2006, 02:29 AM
Why can't the optimized goemetry be stored in geometry buffers, instead of using display lists for that? Geometry buffers seem to be the right abstraction for it.

Brolingstanz
03-27-2006, 03:06 AM
I ordered a large pizza with the works, to celebrate this news. I think OpenGL has its best days ahead.

knackered, enough about the display lists already.

Jan
03-27-2006, 03:17 AM
@tarantula: What exactly do you mean with "Geometry Buffers"? Do you mean it should be put into a VBO behind the scenes?

I don't like the huge amount of work necessary to get to using an extension. However, as long as there are free libraries i can use for this, i don't think it's an issue.

And yes, i also like to have a mechnism to ask the driver how it likes data best.

Also i think, OpenGL, like D3D, should offer a few more basic things, like being able to query the amount of Video RAM or setting VSync (which is still a WGL Extension!).

Jan.

Jan
03-27-2006, 03:19 AM
Originally posted by Leghorn:
I ordered a large pizza with the works, to celebrate this news. I think OpenGL has its best days ahead.I think we all felt that way already when the original 2.0 Spec was released. :mad:

Brolingstanz
03-27-2006, 03:43 AM
With the fiscal and mental might of ati and nvidia behind it, I should think that it's going to actually happen this time ;)

Brolingstanz
03-27-2006, 03:55 AM
Less differences mean less polarized driver-development.True, but I would be careful in suggesting that a better API is an emergent property of disparate driver implementations.

tarantula
03-27-2006, 03:59 AM
Geometry buffer would contain Index Buffer, Vertex Buffer, primitive type etc, a container holding all data necessary for the geoemtry. I was not talking about what happens behind the scenes but what is the interface it exposes, its kinda inelegant to still use the display list to encapsulate geometry!

knackered
03-27-2006, 12:44 PM
well, obviously they wouldn't be called 'display lists', tarantula - full-feature display lists would be emulated in the layered mode. I don't care what they're called, 'geometry buffers', 'soup bowls', 'sausage skins', I don't care. I believe a mechanism for the driver to build an efficient structure from your geometry data is very important, and display lists fill this role nicely at the moment.
Ok, leghorn, I shall put the display list jacket back on the hook.

Overmind
03-28-2006, 09:00 AM
It seems I started a really useless discussion with my little side comment about the new dll, sorry for that, I should have explained better.

My main question seems to have been swallowed:

Who will write this "full OpenGL on top of OpenGL LM" implementation? As I understood it, this would be something that could be done hardware-independant.I mean, if there is really a "layered" implementation, it should be a seperate library, for example like GLU is now. This library can be tested independant of the actual driver implementation.

Assuming the library structure stays as it is now, the responsibility of writing the layered part is still with the driver writer, and we wouldn't even notice if the "layered" part is really layered on top of OpenGL-LM or not. So there is still a lot of room for driver bugs.

On the other hand, if the libraries are split into a "legacy" OpenGL library that implements the same interface as it is now, and a seperate LM-library (implemented by the driver), then the legacy library could be implemented hardware independant on top of the LM-library.

In this scenario, the question "who will write it" comes to mind...

To prevent further discussion in the wrong direction: This has nothing to do with the extension loading mechanism, I'm all for using the extension loading mechanism to update the core version.

I'm not talking about the interface to the programmer, but about the internal organisation of the implementation. The earlier comment was just meant along the lines, if we make a change that is that radical, removing a lot of entry points, we might as well start over with a new library, and then again use extensions to update to 3.1, 3.2, ... But as I said, the real "outside" interface is not important.

Overmind
03-28-2006, 09:09 AM
About the display lists, geometry buffers:

As mentioned by Jan before, a format abstraction similar to what we have with textures now would be exactly what we need.

Just say to the driver "i want this stored for later drawing in whatever format is most convenient for you", exactly like we do it now with textures. I personally never understood why the vertex array interface looks like it is, and not more similar to the texture interface. If it looked similar to the texture interface, we wouldn't even need VBOs, since this detail would be hidden by the driver.

Ok, that's not entirely true. But the functionality of VBOs would be reduced to an async upload mechanism, similar to PBOs.

PkK
03-29-2006, 03:13 AM
>Fair enough, limit its functionality by removing
> nesting, transforms, material changes or
> whatever, but leave the geometry stuff, because
> some IHV seem to do a really good job with it.

But there might be hardware out there that can efficiently do material changes when they're compiled into a display list. I don't think their functionality should be limited. Who knows what tomorrow's hardware could easily do in between other stuff when done the way the hardware wants it (as can be done in a compiled display list).

knackered
03-29-2006, 04:09 AM
that's a good argument for the LM to be supplied by the ICD. Any high-level GL features are always candidates for hardware acceleration.

Overmind
03-29-2006, 04:43 AM
But this would mean the whole layering would be a bad idea...

The point is, most high-level features are not hardware accelerated, so they should be layered on top of some limited set of functionality that is hardware accelerated (called OpenGL LM in this discussion).

When (and if) a hardware accelerated implementation of a layered feature appears, then OpenGL LM should be extended. The layered part should under no circumstances take a shortcut to the hardware.

Otherwise the whole idea about layering would be pointless, since it would be no different than what we have now, namely a single black-box where some features are accelerated and others are emulated, and we can't determine which ones are the fast ones...

Jan
03-29-2006, 05:28 AM
I think the layered stuff should be implemented by one independent group and it should be completely encapsulated from the LM layer.

Otherwise vendors have three options:
1) In fact create a layered API, but sacrificing speed for it.

2) Don't stick to the layering idea and also optimize some high-level stuff, therefore having an advantage above their competitor.

3) Don't really care about the layered API at all, forcing everybody to do their own layering on top of LM.

It just feels as if nVidia would take route 2 and ATI route 3, but that's just speculation.

Anyway, an additional disadvantage would be, that by letting the IHV also do the layered API, the actual problem that we have today (too much work for the driver-writers to do everything right), would not be solved and developers could still not know the quality of the implementation.

If we have ONE layered API and the LM API inside the driver, we would always know the quality of the layered API and errors could be detected and removed easily. If the IHVs also do the layering, we never know, if the problem is in the layered API, in the LM API (in our own code...) and if it makes sense to ditch high-level stuff and get down-dirty just to avoid possible errors in the layered API, thus making the whole layering idea completely pointless in the end.

Jan.

Madoc
03-29-2006, 05:44 AM
Originally posted by V-man:
Functions like glFrustum, glOrtho, glCliPlane should have floats versions and the double version of functions should be killed off until such hw becomes available. Surely glFrustum, glOrtho and the like should not be part of a low-level API? These seem to me like perhaps the most pointless functions in GL. Why should the GL deal with making the projection matrices, can anyone justify hardware optimisation of this?

But perhaps I am missing the point. In my view that is extremely high-level functionality but perhaps that isn't exactly the focus. I would leave such things to a public utility library. Perhaps to be as readily available as the GL headers.

Michael Gold
03-29-2006, 10:06 AM
Whether a layer is written by a neutral third party or by the hardware vendor, it needs to exist within the driver or we lose backward compatibility. Breaking existing apps is considered unacceptable.

Layering is conceptual and there is no promise how an implementation may choose to structure the driver code. The fact is, if a neutral third party writes the layer and it runs at 50% of the speed of the native implementation, this won't fly in the market.

Officially deprecating functionality by "layering" it has two benefits which are independent of the actual implementation.

1) It documents the features which new development should be discouraged from using.

2) Its grants us the freedom to write new extensions without being bogged down by consideration of the interaction with legacy functionality.

Whether or not the actual implementation of legacy features is "layered" is transparent to the developer. Much of OpenGL 2.0 is already layered; you just don't see this externally. All we're doing with this proposal is exposing this fact to the developer.

Michael Gold
03-29-2006, 10:15 AM
glOrtho, glFrustum, and material changes are fixed-function concepts. These are already layered on shaders internally. I don't expect these to move into hardware anytime soon.

Display lists do offer the opportunity for drivers to optimize certain kinds of state changes (e.g. material changes). In practice this has not worked out well; consider an implementation which needs to examine five pieces of state in order to set up a particular hardware block. If a display list contains only four of the five, there is no way to optimize this; at display list execution time the driver still needs to do the same work as if the state changes were provided by immediate mode.

A better solution to this problem is state objects, which can encapsulate related sets of state. One example of a state object which exists today is a texture object; but there is room for improvement even in this example. Another example is a shader, which subsumes many pieces of fixed function state.

Mikkel Gjoel
03-29-2006, 12:59 PM
Ok, trying to wrap my head around this:

You would have a core set of functions, and implement all(?) legacy functionality (IMM/DL etc.) in a new layer, using that core? This way extensions would only have to fit the core, and their impact on the specification would be smaller (as the specification itself). I suppose functionality in the legacy-layer could still be accelerated if anyone wanted to do so - e.g. quadrics might be done in hw if a vendor really wanted to.

As a whole, I don't see any problems with this, as long as this layer can not skipped by some vendors - which, I predict, would basically kill OpenGL... it is "lacking"(*) utility-functions enough compared to d3d as it is. It might become difficult though, to use the legacy functions with new extensions - but that is already happening anyway.
(*) no, I do not think those utility-functions belong in a graphics-library...

I believe one of the forces of OpenGL is the availability of extensions and the possibility for vendors to experiment. Making it easier to do so by limiting the work associated with creating a new extension might not only promote using OpenGL for implementing cutting-edge features, but could very well make the extension-specifications more accessible due to their assumes decrease in size (ie. less of that: "On page 16 the following should be added to the spec...").

I do hope this will be the scenario, and that the re-design of the OpenGL will not end up with a managerial decision to cut driver-costs by making it more like D3D.

Korval
03-29-2006, 01:10 PM
Whether a layer is written by a neutral third party or by the hardware vendor, it needs to exist within the driver or we lose backward compatibility. Breaking existing apps is considered unacceptable.Not necessarily.

Essentially, right now what we have is the OpenGL32.lib that binds itself to an ICD driver. What could happen is that they provide an OpenGLv30.dll ICD that itself attaches itself to the OpenGL Lean and Mean implementation provided by the IHV. Each IHV driver would come with the OpenGLv30.dll ICD, but they would have gotten that .dll from a centralized source.

Frogblast
03-30-2006, 12:07 AM
Gold, I have another question about how the layering would work. Obviously, existing apps need to continue to function, un-altered. However, each vendor supports a disparate set of extensions. Each vendor will *have* to write their own layer, in order to avoid losing functionality (which I assume they will do). I don't expect any Generic OGL3 Full layer to support register_combiners, for instance.

Also, to really do the layer without taking a large performance hit, the 'layer' is going to need to have it's tendrils go deep into the LM implementation, losing much of the advantage of simplified drivers.

So, the questions are:

Will OGL 3 LM apps be distinguished by the fact that they just are not using OGL 3 Full functionality, or will they actually be in an environment where layered features are not available (declaring their LM-ness ahead of time by some means)?

I assume the latter will have to be true, if driver developers ever hope to work on a simpler codebase.

Will an OGL3 LM application be source-compatable with OGL3 Full?

Is the intention that post-OGL3 extensions will also be accessible to OGL3 Full applications? i.e, will it be possible to write extensions that can only be used from a LM application? will this be expected behavior from new extensions?

knackered
03-30-2006, 02:58 AM
You just say...all previous generation cards will not support the Lean & Mean layer, they will support the old OpenGL system (GL1.5), and therefore use the existing OpenGL drivers without further support.
Then for all current/next generation cards, legacy extensions such as register combiners will just be emulated using the shader language to maintain software backwards compatibility (which is probably what's done now, as hardware combiners aren't todays technology).
There has to be a cutoff point, where the Lean & Mean mode is only implemented on hardware that it successfully abstracts.

Roderic (Ingenu)
03-30-2006, 04:20 AM
Basically we are moving from a relatively "low level" API, to an "high level" one, which puts more pressure on the drivers team, yet having less entry points, make drivers coding simpler...
Abstraction is often a good thing.

Is that it ?

knackered
03-30-2006, 04:30 AM
No, at the moment OpenGL as it stands has evolved into a high level API because the API has not changed while the hardware has changed, therefore OpenGL function calls require the driver to 'translate' the command and current states into hardware instructions that bear no resemblence to the original application code. This is slow and vulnerable to bugs.
The proposed change is to create (out of the current OpenGL 2.0 extensions) a new lower-level API. The existing OpenGL API would then translate its commands and states into calls to this lower-level API. As a result, we get a nice, clean and fast API which closely echo's what is actually happening in most hardware, but our older OpenGL applications still work fine.

Overmind
03-30-2006, 05:48 AM
But if I correctly understand gold's reply, this whole layering business is a purely conceptual thing.

So we still won't get a nice and clean API, until perhaps OpenGL 80.0 will finally remove all layered functionality of OpenGL 2.0, but still keeps everything from 3.0 to 79.0 around, so it won't be clean either...

Perhaps I was expecting a bit too much, but to me it looks like this is going exactly the same way as the original OpenGL 2.0 proposal.

Jan
03-30-2006, 08:16 AM
Could it be, that they just want to disappoint as again, so that we finally move over to D3D?

Can't they see we need a NEW and CLEAN API???

Madoc
03-30-2006, 09:03 AM
You can't expect support for old apps to be dropped. At least with developments like this we'll be collecting less garbage. As a developer, you'll have the choice to use the new cleaner API.

It's not like D3D isn't faced with similar issues and with OpenGL being the standard on many (emergent) platforms and efforts like this by Nvidia and ATI, in the long-run, I see the death of D3D, not OpenGL. Just the fact that it is "open" says something for its future.

Overmind
03-30-2006, 10:40 AM
Noone expects that support for old apps is dropped.

But after the initial reports, I expected to get a layered backwards compatibility layer on top of a new and clean API. But it seems they just call it layered, but really it will stay the same it is now. Of coures it will be layered, but only as far as it is already layered now, as driver internal implementation detail.

With this we loose two really important benefits:
1) Driver development will not be easier than it is now, since all layered functionality will still have to be implemented by the driver writer.

2) Legacy features will never really disappear over time, and they can never be really dropped. That's a problem because there is no clear distinction between "new" and "old" API. When there is a clear cut, we wouldn't have to ask us if we should drop legacy features. They are just not present in the "new" API, and anyone who likes to use them has to use the "old" API.

Sorry if I sound so disappointed, but I really expected some things being "removed" from the core, and placed into an utility library. In the long run this will be inevitable, so better do it before the API gets *really* ugly.

And before someone complains, yes, this is possible without breaking backwards compatibility.

Sounds like it won't happen (again).

Korval
03-30-2006, 12:29 PM
Could it be, that they just want to disappoint as again, so that we finally move over to D3D?The comparison to D3D seems quite apt.

When a new version of D3D comes out, it comes with a new API. But it also includes the old APIs, as well as a layer that converts those old API functions into the new API (actually, probably going directly to the driver underneath).

This is exactly what they are proposing for OpenGL. Except that it will probably be possible to use some of the layered functions when working with the L&M API.

The key point is this: driver developers won't have to write/maintain the layer.


That's a problem because there is no clear distinction between "new" and "old" API.There isn't? So, you've seen this new API in action and have some real facts for us?

You're getting worked up over conjecture and speculation. We have very little information about the ATi/nVidia proposal, and we have less information about how the ARB will decide to implement it.

Jan
03-30-2006, 01:27 PM
Originally posted by Korval:
The comparison to D3D seems quite apt.
Just to improve my english: What does "apt" stand for?

sqrt[-1]
03-30-2006, 02:05 PM
Originally posted by Jan:

Originally posted by Korval:
The comparison to D3D seems quite apt.
Just to improve my english: What does "apt" stand for? It is short hand for "appropriate".

Michael Gold
03-30-2006, 02:37 PM
Umm, yeah. Guys, don't go nuts with the speculation. While there are some details to be worked out, our goals include:

1) Backward compatibility for OpenGL 1.0 apps
2) Clear direction for app developers which paths are "preferred".
3) Lower maintenance burden for the driver.

I notice that items (1) and (3) are making some of you nervous, as they appear to be contradictory. Its not my intention to publically debate our implementation strategies, but I will say that we have a plan, and I'll ask you to reserve judgement and not turn this thread into something ridiculous.

If you have questions about the functionality in the proposal, and not "how the hell do you plan to do that??", I'm happy to answer.

Overmind
03-30-2006, 03:36 PM
I'm not doubting point 1 and 2, and I'm very glad to hear point 3 has high priority for you, because some of your earlier posts seemed (at least to me) to contradict point 3 (no, I don't think 1 contradicts 3).

Perhaps I interpreted a bit too much into this sencence:

it needs to exist within the driver or we lose backward compatibilityWhat I'm mainly frustrated about is the missing point 4, clean up the API. I know, this seems to contradict point 1, but this is not actually true.

I'm not saying anything proposed here is bad. In fact I think it's a great development, I mean, 3 of the top 4 points on my future developement whishlist is not that bad ;) .

I just think it could be better. And I always get a bit frustrated when I find out that things actually aren't as good as I initially thought, especially when noone can tell me a good argument why it can't be the way I would prefer it to be.

First I don't understand how this conceptual layering can lower burden for the driver writer, when on the other hand the layer needs to exist within the driver. But after the last post, I think I'm going to accept that you have that angle covered if you prefer not to reveal that detail.

What I'd really like to have an explanation for is: Why does the layered functionality need to exist within the driver to ensure backward compatibility? Applications don't use the driver, applications use the dll, so why isn't it possible to just put another level of indirection in between for every application that uses the old dll, and make a "clean" new dll for new applications?

I'm no windows developer, perhaps there's some stupid limitation on this particular platform why this can't be done, but on linux this would be trivial to implement.


There isn't? So, you've seen this new API in action and have some real facts for us?No, I've not seen this new API, but I've seen some posts here:

Layering is conceptual and there is no promise how an implementation may choose to structure the driver code.
Whether or not the actual implementation of legacy features is "layered" is transparent to the developer.And I assume gold has seen this new API (or at least knows what it's going to look like roughly). If I misinterpreted these posts, please tell me ;)

Michael Gold
03-30-2006, 03:57 PM
Cleaning up the API is also a goal. That is implicit in (2).

As for the layer existing inside the driver; consider that even the introduction of a new DLL would not change the fact that existing apps link with opengl32.dll and opengl32.dll calls into the "driver". If its not there, we're not backward compatible.

If there is an overwhelming desire to have a new DLL which provides a "OpenGL 3.0" interface, this can be implemented as a wrapper. Any of you could write this, and in fact that would be preferable, since we have plenty of work to do on the internals. :rolleyes:

Eric Lengyel
03-30-2006, 05:07 PM
Originally posted by knackered:
No, at the moment OpenGL as it stands has evolved into a high level API because the API has not changed while the hardware has changed, therefore OpenGL function calls require the driver to 'translate' the command and current states into hardware instructions that bear no resemblence to the original application code. This is slow and vulnerable to bugs.This is actually less true than you might expect, especially on Nvidia hardware. For example, when using the following functions, Nvidia hardware accepts the same exact enumerant values that you pass in from your C code, and there's a one-to-one correspondence between OpenGL state and hardware registers.

glAlphaFunc
glBlendFunc, glBlendFuncSeparate
glBlendEquation, glBlendEquationSeparate
glStencilFunc, glStencilFuncSeparate
glStencilOp, glStencilOpSeparate
glShadeModel
glLogicOp
glFogi(GL_FOG_MODE, *)
glDepthFunc
glBegin
glPolygonMode
glCullFace
glFrontFace

Almost all of the enables/disables also have corresponding registers that take 1 or 0. Other registers just take packed values derived from GL function parameters. The native vertex and fragment program instructions are nearly identical to what you see in the extension specifications.

And there's more than these examples. I'd say the OpenGL driver is still pretty close to the metal today.

V-man
03-30-2006, 07:36 PM
Object ID is a pointer instead of an uintWasn't the old GLHandle for shader objects like this?


No more orphainingWhat does it mean?


Binding texture object IDs to samplers (skip texture image unit)This would be faster than binding the texture unit? What happens to

glActiveTexture(...)
glBindTexture(....)

Does it get ignored? Does it go into high level layer?


What features to consider layering:

* Depth test
* Stencil test
* Blend
I don't undestand this part. You are talking about
glEnable and glDisable? Or glDepthFunc, glStencilFunc and glBlendFunc?

What would be the LM way to setup these?

Note: quotes from http://www.gamedev.net/columns/events/gdc2006/article.asp?id=233

sqrt[-1]
03-30-2006, 07:37 PM
Here is kinda what I though might be going on (implementation wise)


Application
|
|

opengl32.dll
|
|

<Driver ICD>
|
|
|
/ \
/ \
/ \
/ \
/ \
<Core OpenGL 3> <----- <layer OpenGL legacy>So to legacy apps there is no difference in the interface. A new "standard" ICD will directly call the core driver where appropiate or call the legacy layer which will process and then call the core functions.

In theory if the ICD and legacy layer can have a standard implementation, all a hardware vendor has to do is implement <Core OpenGL 3>.

Perhaps there might be a "direct" way for new apps to link to opengl3.0 core directly?
If not, I have often though of doing as gold suggested and creating a sub-set of GLEW that only included the fast and modern functions. (GLEW-Game?)

Michael Gold
03-30-2006, 10:01 PM
Originally posted by V-man:

Object ID is a pointer instead of an uintWasn't the old GLHandle for shader objects like this?
GLhandle is a uint, so it cannot be used as a pointer on a 64-bit OS

No more orphainingWhat does it mean?for example: you delete a texture in one thread while it is bound to another thread. since it is bound in the other thread the object is not actually deleted, but since you called Delete the name is no longer associated with the object. The object is "orphaned", and actually deleted after the last reference is removed.

Binding texture object IDs to samplers (skip texture image unit)This would be faster than binding the texture unit? What happens to

glActiveTexture(...)
glBindTexture(....)

Does it get ignored? Does it go into high level layer?ActiveTexture and BindTexture are gone in the new object model. They are layered for compatibility.

What features to consider layering:

* Depth test
* Stencil test
* Blend
I don't undestand this part. You are talking about
glEnable and glDisable? Or glDepthFunc, glStencilFunc and glBlendFunc?
This is a speculative future sample shader, where framebuffer operations are programmable. Just as texenv is replaced by fragment programs and T&L is replaced by vertex shaders.

Frogblast
03-31-2006, 12:22 AM
Given the terrible confusion here, perhaps we should stop using the word layer, and pick a word that doesn't imply how the driver is structured (OpenGL 3 LM "Profile"?).

Anyhow, since my biggest question seems to have been glossed over, I'll try re-posting it once:

What makes an app OGL3 LM rather than OGL3 Full? Would the app simply refrain from using Full-only features, or would an app explicitly choose to create a LM-only context? (or something else entirely?). Or is there not a consensus on this yet?

Michael Gold
03-31-2006, 02:23 AM
I'm not sure there is a concensus yet - we've been more focused on functionality than mechanism. Given that there are no plans to explicitly disallow mixing new and legacy features, the former seems easiest.

LM may be more of a guideline than a hard limit on what can be used by an application. It represents the recommended paths, those which are more likely to be full performance, and those which will receive the most attention going forward, both in terms of extensions and performance. I would say maintenance also but I don't wish to imply that the legacy functionality will fall into disrepair; but in theory, once we have robust layered implementations of the legacy, we may never touch that code again.

Jan
03-31-2006, 03:02 AM
I understand that there might be the need for completely backwards compatibility.

And therefore it is certainly a good idea to still provide this.

BUT, i'd like to have a CLEAN cut between the new OpenGL (LM) and the old one. I would love to have a completely cleaned up and redesigned API that does not bother about legacy features.

I don't care about "old" OpenGL, but for those who do, there should be this layer, that provides the functionality by interfacing to the LM API.

This might incur a speed penalty. But think about it this way: All new Apps will directly interface with LM. All old apps were written for computers that are slower as when LM came out. So, if a layered API incurs a 10% to 20% speed-hit, but the computers are twice as fast anyway, then why bother?

I don't think that "guidelines" what to use and what not to use are very useful. Just a few weeks ago someone suggested in this forum to try out register combiners.
I don't need "guidelines", i already follow my own guidelines, by simply not using legacy extensions (for this you first have to know what's legacy).

I mean what would we need to have a pure OpenGL LM? We all need a new header and a lib and also a way to tell the driver, that we want to exclusively use LM and no old stuff. All old apps will work as is, but they will be rerouted inside the driver. No?

Jan.

knackered
03-31-2006, 04:56 AM
Anyone noticed that LM could mean 'Layered Mode' or 'Lean&Mean', both contradictory? I'd rename 'Lean&Mean' mode to 'Clean Mode' (CM) in these discussions....I remember the old d3d 'retained mode' and 'immediate mode', which confused the hell out of an OpenGL programmer.

I'm trying to imagine problems with mixing CM and LM calls. It could get very confusing when states are ignored in CM.

Michael Gold
03-31-2006, 05:16 AM
Jan - I hear you. But this is not the priority right now. Please remember: this is only a proposal today, and we are focused on functionality, not mechanism. As previously stated, its easy to restrict the interface via a shim or some other means. Lets not put the cart before the horse. Can we agree this is solveable and move on?

Knackered - LM is meant to be descriptive, not an official interface name. Again, this is a proposal.

You think design by committee is bad? Try design by internet forum. Can we stay focused please? I'm starting to regret ever posting here.

Does anyone want to talk about actual functionality, rather than window dressing? If not, I am done with this thread.

Cheers,

-- Michael

knackered
03-31-2006, 05:45 AM
I'd like to know what the next step is, what's a realistic time-scale for it, michael? Is there a proposed specification now?

Jan
03-31-2006, 06:13 AM
Yes, i know this is only a proposal and i know that what i am asking for is only one aspect and that you are concerned with much more than this.

This problem is solveable and actually i am tired of going round in circles, too.

It's just that many people feel like me (at least i have the impression), but that we were disappointed before and therefore now fear to get disappointed again.

Anyway, this forum should be a place were you can gather opinions, but the committee has to decide in the end. I think with ARB_fbo the committee has proven (again), that OpenGL is indeed in good hands.

Jan.

Hampel
03-31-2006, 07:24 AM
@michael: would this reduced function set or API be something like the OpenGL ES 2.0 specification with more or less all fixed function pipeline stuff removed? Or will it be a more radical change in the API (since you spoke of changes w.r.t. the texture object mechanism, for example)?

Overmind
03-31-2006, 08:02 AM
I've got one question about the textures being directly bound to uniforms.

Does that mean that the currently bound textures will be part of the program state? So if I change the current program, I implicitly change the bound textures.

Or are you making a new object for this kind of thing? Let's call it material object for lack of a better name. This would consist of a current program plus uniform values (including textures). Perhaps add a bit more state into it, and it would be a good replacement for state changing display lists...

Michael Gold
03-31-2006, 10:24 AM
knackered - We'd like to move on this ASAP. I'd like to roll out the new pieces as extensions to 2.x, and officially deprecate legacy stuff in 3.x. We haven't set a schedule but we want it yesterday. We're definitely motivated.

Jan - Thanks for the vote of confidence. :) I hope we don't disappoint you this time.

Hampel - Even ES 2.0 doesn't have all fixed function removed; but if you mean vertex and fragment, yes that's what we are considering. As you note, we are proposing a revamped object model too, so its a more radical change. I'm no oracle but I expect the delta between GL3 and ES3 to be a lot smaller than between GL2 and ES2.

Overmind - There will be no "currently bound texture" in the new model but if I understand your question, yes once you have set up your sampler bindings, changing the program pulls in the associated textures. The details of this are being discussed so it might be along the lines you suggest, we'll have to wait and see. The goal is to reduce the number of individual state changes which must be performed every single frame just to render the same scene as the previous frame. We can do better.

marco_dup1
03-31-2006, 10:27 AM
What about binding? In FBO extension you use the old texture object model. For every change in the framebuffer I need to bind them? I like the shader object model much more there you can set parameters without binding. Maybe two kind of parameter functions? One with and one without handels where the functions without handels are layered.

Overmind
03-31-2006, 12:53 PM
gold, yes, you understood my question correctly. With "currently bound texture" I meant of course "currently used for drawing".

But as I think about it further, the whole "state object" thing seems a lot more complex than what I tried to describe in my last post.

Binding something just to change it's state doesn't really make much sense. This should be replaced by state changing functions with an additional "object" parameter.

But ultimately, something has to be bound so GL knows how to render things.

One possibility would be this thing being a single object that contains the whole GL state. Then you could make the whole binding idea obsolete and add another parameter to the draw calls.

But I'm not so sure if that's a good idea. Sometimes you only want to change part of the state, and the driver should be able to optimize this.

A typical application might for example bind a program object, bind textures and light parameters to uniforms and render. Then it changes the light parameters and renders again, and so on. Then it changes the texture ..., and finally it changes the program object.

Or it might do the same thing, but change first textures, then light parameters... You know what I mean, it's the whole "how do I sort my geometry" thing.

In light of this scenario, I'm really curious how the future state changing interface will look, because ideally, it should be obvious to the programmer how efficient or inefficient a particular render order is, based on looking at the API.

Anyway, that's not really a question, as I realize that you propably haven't sorted things like this out. I'm just thinking out loud, and perhaps someone here has some ideas on the topic...

Korval
03-31-2006, 01:43 PM
But ultimately, something has to be bound so GL knows how to render things.Not really.

Presumably, under Clean 3.0, your glDraw* command includes a "shader" parameter. And to that shader are bound (among other things) the textures that the shader uses.

If they're moving away from a strictly state-based model (glBind* followed by state commands, etc) and going towards an object-based model, then you'll find a lot of Clean 3.0 functions taking objects as parameters rather than binding to something. That glDraw* function might even take the framebuffer object that it should render to as a parameter, though that isn't necessarily the right thing to do.

Overmind
03-31-2006, 02:22 PM
Exactly that's what I'm talking about. Does it make sense to make everything an object, or should be keep some states? I'm tending towards keeping no states and solving everything with objects. I'm not 100% sure if that's the best approach for the implementors, but it would be cool for us developers ;) .

And the more important question: How should these objects be structured? Which objects are bound to which others? Obvious examples would be textures bound to shaders (via uniforms), or textures/renderbuffers bound to framebuffer attachments. But I'm not entirely sure what to do with buffer objects, and I'm sure we would need a few more objects for some other states...

The next thing would be, will there be seperate parameters for different objects in the draw calls, or is there a new object that represents e.g. a framebuffer-shader combination? Perhaps not neccesarily framebuffer-shader, but I'm sure there are more things needed for a draw call than a framebuffer, a shader and some sort of geometry representation (although i can't think of an example, but I'm sure I miss something).

A problem with the "encapsulate everything" approach would be the szenario I described in my previous post, where many parameters need to be changed independantly, so it doesn't pay off to make a new object because it won't be reused often.

The problem with the opposite approach would be a lot of parameters for a draw call.

So perhaps a in-between solution would be preferable. Identify which states only change together (or at least where the hardware would like them to change together), and encapsulate them into an object. States that change frequently and independant from each other should become parameters of the draw call.

Korval
03-31-2006, 07:14 PM
A problem with the "encapsulate everything" approach would be the szenario I described in my previous post, where many parameters need to be changed independantly, so it doesn't pay off to make a new object because it won't be reused often.Presumably, shader objects would now include things like interpolation mode (smooth vs. not), blend mode, logic ops, etc, as those make sense to be directly bound to the concept of a shader.

Multisampling would be as it is now: an intrisic part of the framebuffer.

I suppose you would need a geometry object to store the list of VBOs, attributes to which those VBOs are bound, and the index buffer. The geometry object could even be "overloaded" to a degree: you could build a geometry object from buffer objects, or through the geometry display list stuff.

However, as far as fundamental objects for drawing stuff is concerned, I think that covers everything. The shader represents all of the state information to set up the pipeline to rasterize something. The FBO determines where the results go. And the geometry object decides what the input to the shader process is.

There is one low level concern: changing a shader object would be changing all possible shader state. This means that a simple change to the framebuffer blend mode would provoke all kinds of re-uploading and so forth. Granted, it is not often (read: ever) that you change blend mode without changing the shader itself, so it may not be an actual issue in practice. But it bears considering.

Another point of interest: a shader object would need to store a reference to the compiled&linked program rather than being that compiled&linked program. The reasoning for this is that you frequently do reuse shader programs, but you may use them in different ways as far as other state is concerned. You wouldn't want the system to have duplicate shader programs lying around just because you want to have different textures with the same shader.

Indeed, it may be that the set of uniforms that the shader program uses is no longer part of the program object's state, but instead something that gets stored in the shader object (different from compiled but unlinked shaders).

I think we need to stop talking about this; it makes me want it too much ;)

BTW, it has been suggested by some that windows-system framebuffer concepts be done away with entirely, and instead all you do is render to an FBO and then tell the system to display the buffer in the particular display location (FRONT_LEFT, FRONT_RIGHT, etc). Is that something you guys are considering?

Michael Gold
04-01-2006, 01:29 AM
It sounds like you've got the basic idea. The discussion is thought provoking; we don't pretend to have all the answers (yet) and its useful to hear how others see it fitting together.

The notion of replacing the window framebuffer with an FBO has definitely come up, and EXT_framebuffer_blit is one way this might be accomplished. A single buffered window with no ancillary buffers would be a good target for such a "swapbuffer" blit, but stereo and flipping would require a new API.

Overmind
04-01-2006, 02:13 AM
BTW, it has been suggested by some that windows-system framebuffer concepts be done away with entirely, and instead all you do is render to an FBO and then tell the system to display the buffer in the particular display location (FRONT_LEFT, FRONT_RIGHT, etc). Is that something you guys are considering?I like this idea, it would solve the current inconsistency between FBO rendering and window rendering. It would also enable us to "share" a common depth buffer.

Although the idea I came up with would do the opposite, bind window buffers to FBO attachment points. I didn't post it until now because I have no idea how this is implemented in hardware and if such a thing is even possible without a copy...

Jan
04-01-2006, 04:39 AM
I do like the idea to render to an FBO and not having an actualy framebuffer anymore. Modern renderers will do most of the work by RTT anyway, but as a last step all the calculations still need to be copied to the real framebuffer.

I don't think that the blending state and shaders will always be changed together (or most frequently). Every multipass approach will actually render the first pass without blending, to fill all areas (and thus not needing to glClear the color buffer AND not needing to blend) and in the following passes the same shader will be used to accumulate the results.

This is not only done for lighting, but also when combining other stuff, like different layers in a terrain-rendering step.

Therefore, simply changing the blend-mode should not be considered to be as heavy-weight as changing a shader anyway. What i want to say is simply: If a state-change CAN be lightweight, it SHOULD be leightweight, even if it MIGHT usually be coupled with a heavyweight state-change.

I also think, that textures should not be bound to shaders too strictly. It's certainly true, that when i change a shader, i usually also change the textures. But usually when i switch to another shader, i won't want to use the same textures, as i used, when i used the shader the last time. So it's a waste, if the shader remembers, which textures i used last time, if i change them anyway. Also, i think a shader should only encapsulate REAL states. I mean, which texture was bound is not a simple state, because that texture could have been deleted.

And additionally, if i put all states into a state-object, what happens if i actually render something. Now the driver first has to examine which states in the provided state-object are different to the state the hardware is set to. If that are many states, then the driver-overhead just for everytime checking is also not minimal.

By the way, if i look into glEnable etc. at the moment there seem to be many many states. If LM/CM actually removes the fixed function stuff, i guess there will be only "few" states left. But there are still states, which i don't know, if they are considered to stay. For example line-stippling and "antialiasing". Most hardware has never supported this and therefore no one uses it. Is this supposed to stay in the API?

Jan.

Corrail
04-01-2006, 06:04 AM
Originally posted by Jan:
I also think, that textures should not be bound to shaders too strictly. It's certainly true, that when i change a shader, i usually also change the textures. But usually when i switch to another shader, i won't want to use the same textures, as i used, when i used the shader the last time. So it's a waste, if the shader remembers, which textures i used last time, if i change them anyway. Also, i think a shader should only encapsulate REAL states. I mean, which texture was bound is not a simple state, because that texture could have been deleted.This could be solved by using Uniform State Objects (I think someone called them Material Objects somewhere in this thread). Such a Uniform State Object is bound to a specific shader program and stores all Uniform state and Textures.
But this is just an idea/suggestion for the GL3.

Overmind
04-01-2006, 06:12 AM
The more I think about it, the more confused I get about it...

I, as a programmer, compile my shaders, link them to programs, and then construct a lot of uniform state objects for each possible shader-texture combination.

The problem I see with this is: Now I can call my draw function with these uniform state objects as parameter. Obviously I will sort my geometry by uniform state object, but actually I should also sort my uniform state objects by program object. Or should I better sort them by textures?

If I sort them by program object, should I sort the shaders further? If so, should I sort them first by geometry, vertex, fragment or blend shader, because all of them could be reused by different programs...

I'd really like an API that makes these issues very clear to the programmer.

But perhaps it doesn't really matter, and it's really the same for the hardware if I change just the blend mode, the blend mode and a texture or the whole shader? Perhaps someone with a bit more insight into the hardware could answer this...

EDIT: Just saw the post of Corrail, and modified my terminology to match his.

marco_dup1
04-01-2006, 08:07 AM
Originally posted by Jan:


I also think, that textures should not be bound to shaders too strictly. It's certainly true, that when i change a shader, i usually also change the textures. But usually when i switch to another shader, i won't want to use the same textures, as i used, when i used the shader the last time. So it's a waste, if the shader remembers, which textures i used last time, if i change them anyway. Also, i think a shader should only encapsulate REAL states. I mean, which texture was bound is not a simple state, because that texture could have been deleted.
Do you change the texture image all the time or also the parameters? If you have texture shaders which filter the shader etc. and bound them to the fragment shader object when you have to change the texture image. I believe that the texture shader object will change much fewer times than the texture image.

Jan
04-01-2006, 09:45 AM
@marco: I'm sorry, but you lost me there. With texture image you mean a simple texture, no? What exactly do you mean with "texture shader which filter the shader"?

When i change a shader, i bind a new glsl program (vertex + fragment shader) and additionally set uniforms AND bind several textures to different texture units.

Then i render geometry and in between sometimes i change (usually all) textures, but leave the glsl program active, but do usually change some uniforms.

Sometimes i also change a state like the blending mode, but that's not so common.

So, where do "texture shaders" come in? Sorry, i'm a bit confused :)

Jan.

Corrail
04-01-2006, 10:00 AM
If I understood it correctly then there will be a shader which lets you control the sample operation of a texture.

Dirk
04-01-2006, 12:01 PM
Here are my $.02:

Geometry Simplification:

Looks good. As long as the layered display lists give good performance (doesn't have to be perfect, but pretty close). If that's only true for geometry-only dlists that's fine, but I think it would be a bad idea to only get good performance out of VBO-based dlists. It's really one of the strengths of OpenGL to be able to just throw a couple polygons at it using immediate mode and use dlists to get decent speed.

Object model:

Contrary to pretty much anybody else apparently :) I liked the old model. For applications that have internal identifications of the all the OpenGL-based objects anyway being able to use those simplified some things (e.g. not having to keep track of an extra id, being able to use the same id across multiple threads etc.).

That said, even I have movied away from it because it doesn't play well with other people's code. So that's my main reason to not worry about it any more, and I really don't have a lot of other arguments for it.

Immutable Objects:

Not sure where this simplifies the driver, as there still needs to be a memory manager that can handle the fragmentation, which seems to be the main problem to me. I can see it being complicated when changing only parts of existing objects, so if it only means having to replace the whole object, but being able to reuse an existing id/GLobject, that would be fine.

No current state (binding) any more:

I don't like it very much, it reminds me too much of the old X model where one of the common questions was how to make sure you had access to the Display* and the GC absolutely everywhere, which can be a big pain in deep class hierarchies.

I'm not sure what the big advantage of not having a current bound object is. Seems to me all it is is a thread-local variable that points to the current state object that is being used/manipulated instead of feeding into into each call. Unless there is something big that I don't see I'd like to keep the binding alive.

Sampler / parameter objects:

I never understood the need for the sampler types in GLSL. Why not use just an int to identify the texture unit that is being used, and allow that to be a uniform or a constant? If that's what's this change is, I'm all for it.

Error handling:

Not sure if the callback addition is really necessary. It will make binding to other languages than C/C++ harder, and honestly I don't think anybody seriously debugs OpenGL applications without a logger/tracer anyway. Programmatic error handling (at least for me) is primarily a fallback to help me identify the location where users run into errors, and even for those I'm starting to tend to ask them to run their program through a tracer for bugreports. More error codes and a human-readbale info/error log might be a nice addition, but nothing I would cry about not having.

State Objects:

Thinking about what state is left after removing the FF pipeline, it seems like there is not a lot. :eek: So a single full state object might be doable, I'm just not sure whether switching between those would really be the most efficient way.

What I could see (and what I'm doing in my system anyway) would be a two-level hierarchy of state objects, where there is a full state object that contains a number of state chunks, which are individual objects that can be shared between states. State chunks encompass a bunch of individual states that are usually changed together. Just an idea.


All in all I agree that an overhaul to remove cruft is a good thing. This one seems pretty radical (IMHO), which may or may not be a good thing, but if it revives OpenGL I'm all for it. So when can we have the first set of extensions? :D

Corrail
04-01-2006, 12:01 PM
ATI has the GDC06 presentation online
http://www.ati.com/developer/gdc/2006/GDC06-OpenGL_Tutorial_Day-Hart-OpenGL_03_Performance.pdf

[EDIT] this presentation has nothing to do with OpenGL 3 :(

Overmind
04-01-2006, 12:12 PM
Sampler / parameter objects:

I never understood the need for the sampler types in GLSL. Why not use just an int to identify the texture unit that is being used, and allow that to be a uniform or a constant? If that's what's this change is, I'm all for it.
It's exactly the other way round. There will be no texture unit, and you bind the texture object directly to the sampler uniform.

Think about it as the sampler uniform directly having the texture stored in it, instead of an integer identifying the texture unit where the texture is bound.

marco_dup1
04-01-2006, 02:54 PM
Originally posted by Jan:
@marco: I'm sorry, but you lost me there. With texture image you mean a simple texture, no? What exactly do you mean with "texture shader which filter the shader"?

When i change a shader, i bind a new glsl program (vertex + fragment shader) and additionally set uniforms AND bind several textures to different texture units.

Then i render geometry and in between sometimes i change (usually all) textures, but leave the glsl program active, but do usually change some uniforms.

Sometimes i also change a state like the blending mode, but that's not so common.

So, where do "texture shaders" come in? Sorry, i'm a bit confused :)

Texture shaders are sample programs. Today you use the texture parameter function to set the filtering. Let a program do this stuff.

tamlin
04-01-2006, 07:38 PM
I for one welcome a more object-oriented approach.

I have a few thought's I'd like to share though.

Are the objects themselves to have enough state information that I can save ("serialize") them, to possibly even save this state to disk and at next startup "short-circuit" much of the time consuming startup (creating many texture names today comes to mind, not to mention all the extra calls needed to upload all mipmap levels) by simply "uploading" this (implementation-dependent?) bit-bucket of states to an object? Having the "names" be plain pointers seems to suggest I could simply save the contents of the memory to a file, and then (assumming that memory is free) reload the contents to the exact memory positions.

If that's so, what if the memory address isn't available at next load? Adding something to the buffer saying "I used to live at X", so the "upload" function(ality) can remap all required?


Have you considered multi-monitor scenarios? Using multiple gfx cards? Even from multiple vendors? This is an area I feel must be "fixed", as (if limiting this to the Windows platform) DX simply isn't an option for many professional applications, but multi-mon output can be a requirement.

Korval
04-02-2006, 12:12 AM
I don't like it very much, it reminds me too much of the old X model where one of the common questions was how to make sure you had access to the Display* and the GC absolutely everywhere, which can be a big pain in deep class hierarchies.Then do what the driver is obviously doing: storing the object in a global variable that you can access for various places. It is no uglier code-wise than encasing that global variable behind a .dll boundry.


Are the objects themselves to have enough state information that I can save ("serialize") themI can't speak for the ARB, but I'm pretty sure you can forget this. You may have a "pointer" to some memory, but you don't have a pointer to an object. Indeed, the pointer could point to anything. You don't know what's on the other end of that pointer, so there's no way to "serialize" it into a block of bits.

And I seriously doubt that the ARB is going to have a glSerializeObject and glUnSerializeObject pair of functions. The uses are too few, and the requirements on IHVs are too many. Plus, the time spent creating objects and filling in basic data is trivial at best, particular compared to the time spent uploading textures, and compiling shaders. The ARB might consider an implementation dependent shader serialization function, but only because compiling shaders is time consuming. Making objects isn't time consuming.

speedy
04-02-2006, 08:17 AM
Looks like ATI & NVIDIA could create a fresh SourceForge.net project for the OpenGL layering library, commit the code, and let the user community pound on the bugs directly. :D

Hampel
04-03-2006, 06:52 AM
Here is one presentation from the GDC from NVidia about D3D 10:

ftp://download.nvidia.com/developer/presentations/2006/gdc/2006-GDC-DX10-Prepping-Your-Engine.pdf

I think there are some nice ideas behind the cleaned up D3D API. How would OpenGL 3.0 compare against that?

ZbuffeR
04-03-2006, 10:02 AM
about this nvidia doc on D3D 10:

- LOL for the CoverageToAlphaEnable, is that really new in DirectX ?

- about the geometry shader, they don't tell how to use it, and what is actually possible to do with it. Anyone has more details ?

- the ID3DX10ThreadPump for async load of resources looks interesting.

- can someone explain what they mean with "predicated rendering" ? and how would that help with LOD ?

Zeross
04-03-2006, 10:40 AM
Originally posted by ZbuffeR:
- can someone explain what they mean with "predicated rendering" ? and how would that help with LOD ? [/QB]It's exactly as described in the slide : first you can render a coarse approximation of your geometry, and then render the detailed version only if the coarse version was visible.

It's exactly like occlusion query excepted that instead of polling the results on the CPU, everything is done on the GPU : the results of the query is inserted in the command queue. If the result is not available at the time of the drawing command then the GPU considers the result to be true and execute the command anyway.

Foxbat
04-03-2006, 07:38 PM
Originally posted by Overmind:

BTW, it has been suggested by some that windows-system framebuffer concepts be done away with entirely, and instead all you do is render to an FBO and then tell the system to display the buffer in the particular display location (FRONT_LEFT, FRONT_RIGHT, etc). Is that something you guys are considering?I like this idea, it would solve the current inconsistency between FBO rendering and window rendering. It would also enable us to "share" a common depth buffer.Just wanted to put in another big thumbs up for this. Sharing the Z buffer is key. Also allows ditching the over/underlay mechanisms.

Ok, I know the hardware isn't there - yet - but vertex programs that can take a single primitive and break it up into multiple primitives is important.

Although the idea I came up with would do the opposite, bind window buffers to FBO attachment points. I didn't post it until now because I have no idea how this is implemented in hardware and if such a thing is even possible without a copy...

Korval
04-03-2006, 08:49 PM
Although the idea I came up with would do the opposite, bind window buffers to FBO attachment points.I don't like that. It seems to me to impose restrictions on what the IHV can do. Plus, without the stretch-blit call, it makes it pretty difficult to do antialiasing without rendering to your own buffer. It's better to just drop the entire concept of rendering directly to their buffers totally.

Cab
04-04-2006, 01:11 AM
Originally posted by Zeross:

Originally posted by ZbuffeR:
- can someone explain what they mean with "predicated rendering" ? and how would that help with LOD ? It's exactly as described in the slide : first you can render a coarse approximation of your geometry, and then render the detailed version only if the coarse version was visible.

It's exactly like occlusion query excepted that instead of polling the results on the CPU, everything is done on the GPU : the results of the query is inserted in the command queue. If the result is not available at the time of the drawing command then the GPU considers the result to be true and execute the command anyway. [/QB]I remember when I was younger (2002) :) and write a proposal for OpenGL about this in the 'Suggestions for the next release of OpenGL' forum:
http://www.opengl.org/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic;f=7;t=000343

l_belev
07-25-2006, 05:43 AM
when you decide the fate of the display lists and think of some replacement please bear in mind that storing geometry isnt their only possible good use. example for another such is storing states (in a simmilar way to the d3d state blocks). so if u are going to deprecate/whatever the display lists please provide other means for doing these things if possible.

andras
07-25-2006, 07:18 AM
The more programmable the pipeline becomes, the less states you'll need.

Humus
07-25-2006, 10:59 AM
Something like DX10 style state blocks is probably what we want in the future that sets a particular complete state rather than update a list of states like a display list would do.

Overmind
07-27-2006, 04:05 AM
That's assuming we still have states after introducing the new object model :p

tamlin
07-31-2006, 10:46 AM
Overmid, you seemingly know how to get people worried! :-)

Korval
07-31-2006, 11:57 AM
Overmid, you seemingly know how to get people worried! :-)Why would that be a worry? If GL 3.0 is all object-based, there's no need for states.

Overmind
07-31-2006, 01:13 PM
Yes, if you encapsulate everything that's needed to render into some objects, you just have to give the objects as parameters to the draw calls (for example glDraw(geometry_object, material_object, framebuffer_object); ).

The geometry object would contain the vertex and index array, the material object contains shaders, uniform values (including textures), blend mode and so on. Together with the framebuffer object that's everything that's needed to draw something.

No need for any "current" texture, array, framebuffer, whatever.

V-man
08-01-2006, 08:40 AM
Is it possible to have the same GLSL compiler for all cards. Like, the GLSL compiler makes a kind of object code and the driver takes this and optimizes starting from the object code. Is that what the offline compiler will do?

Christian Schüler
08-03-2006, 03:47 AM
In response to the prospect of having a programmable blending unit one day:

I'd like to make a strong case for a 2-way colored multiply-add style blending function. This way, all sorts of extinction- and/or atmospheric effects could be done in 1 pass.

- pixelshader emits 2 outputs, say COLOR0 and COLOR1
- blending function: color0 + dest * color1

For almost all applications, that's all you're ever going to need.


In the current model, you'd first need to multiply the framebuffer with color1 and in a second pass add color0 to it. Not sure if current hardware would actually be capable of doing it in 1 pass the way I described, but I hope you guys can see the sense in it.

Cyril
08-13-2006, 04:54 AM
Hello,
Did you see ATI presentation of DPVM and their CTM layer at Siggraph ?

http://www.ati.com/developer/siggraph06/dpvm_e.pdf
http://www.ati.com/developer/siggraph06/dpvm_sketch_siggraph.pdf

Doesn't this look like close to OpenGL LM ?
And if OpenGL becomes just a GPGPU application among others, on top of a standard low level acces to stream processors like this ? ;-)

V-man
08-13-2006, 07:03 AM
There is no OpenGL LM, but even if there was it wouldn't be this low level.
Sounds to me you don't need to create a window to use DPVM. It's a backdoor to the GPU and is extremely low level. You have to make and send the binary version of your shader, and send commands with submitCommandBuffer()

I hope it gets released because even I would like to tinker with it.

Cyril
08-13-2006, 07:54 AM
Yes I know there is no OpenGL LM, I was juste talking about the idea.

But the idea of OpenGL LM is to provide very close to hardware functionnalities abstraction isn't it ? And, if I well understoud, then layer core OpenGL higher level 3D API on top of this abstraction.
So why a kind of DPVM wouldn't be this low level ?

Why couldnt we let hardware manufacturers provide only this standard low level acces into their drivers, and let (why not) the ARB/KHRONOS develop higher level 3D specifics OpenGL API ?

ATI is known to be short in software, and particulary OpenGL support. I would not be surprised if this was the long term idea in the head of ATI managers, allowing to let software specialists, and why not the open source community, provide better softwares for their hardware.

GPGPU is a growing domain, GPU becomes more and more generics stream computers, and today the war for physics acceleration in video games is engaged. Whay can't we expand the concept of OpenGL ML, that was thinked for OpenGL and so only for 3D acceleration, to generic stream architectures abstraction ?

Could not this be the oportunity for Khronos to play a role providing standard hardware abstraction specification, useful for OpenGL, but also for every others stream based applications, like physics or video acceleration (cf. ATI/AMD plans) ?

holdeWaldfee
08-13-2006, 10:57 AM
Originally posted by Cyril:
GPGPU is a growing domain, GPU becomes more and more generics stream computers, and today the war for physics acceleration in video games is engaged. Whay can't we expand the concept of OpenGL ML, that was thinked for OpenGL and so only for 3D acceleration, to generic stream architectures abstraction ?NO, NO, NO and NO.

(sorry for being OT)

This GPGPU stuff is plain nonsense in my eyes.
Either it's a GPU or a CPU!
What we need is a faster GPU and not an additional CPU.

Even current possible program complexity is light-years away from adequate performance support.
What still mainly matters is plain SPEED.

If you want to do physics: use the CPU!
SSE/FP performance on Core2 and K8L is enough to feed next gen high-end graphics hardware.

V-man
08-13-2006, 02:22 PM
Originally posted by Cyril:
But the idea of OpenGL LM is to provide very close to hardware functionnalities abstraction isn't it ? And, if I well understoud, then layer core OpenGL higher level 3D API on top of this abstraction.
So why a kind of DPVM wouldn't be this low level ?
If this GL LM becomes real, then only morons will use the old style GL. GL LM could be used to make games, CAD and visual, etc
Old software will run on the compatibility layer which calls into GL LM


Originally posted by Cyril:
Why couldnt we let hardware manufacturers provide only this standard low level acces into their drivers, and let (why not) the ARB/KHRONOS develop higher level 3D specifics OpenGL API ?
You mean you want Khronos to code GL LM?
Khronos doesn't create drivers, not even for GL ES. They might create a reference software driver.

Korval
08-13-2006, 02:34 PM
Why couldnt we let hardware manufacturers provide only this standard low level acces into their drivers, and let (why not) the ARB/KHRONOS develop higher level 3D specifics OpenGL API ?Because that's not how it works.

Do you expect that nVidia's going to use the same binary shader format as ATi? Of course not; there'd have to be an abstraction, thus allowing them to convert the shared shader format into their own format. At which point, it suddenly becomes possible for a higher-level language, with a good compiler, to beat the performance of a simple translater.

The idea of GL 3.0 L&M is that it is just low-level enough to be "guarenteed" fast, but high-level enough so that it provides IHVs the opportunity to optimize for their hardware. This is where a graphics API should be.

Mars_999
08-16-2006, 10:37 PM
I haven't read the whole 3 pages but, I am going to ask this, since I am coding all my GL code for GL2.0 I am assuming when 3.0 comes out I will be able execute my 2.0 code without any problems? Meaning when my engine is done the end user will have no issues running it on 3.0 hardware. Thanks for answering my redundant question.

sqrt[-1]
08-17-2006, 01:39 AM
Yes your GL2.0 code should have not problem running on GL3.0 hardware.

The only difference should be that your GL2.0 calls get translated to GL3.0 calls behind the scenes. (Drivers already do this layering to support fixed function)

Cyril
08-17-2006, 04:26 AM
Originally posted by Korval:

Do you expect that nVidia's going to use the same binary shader format as ATi? Of course not; there'd have to be an abstraction, thus allowing them to convert the shared shader format into their own format. At which point, it suddenly becomes possible for a higher-level language, with a good compiler, to beat the performance of a simple translater.

The idea of GL 3.0 L&M is that it is just low-level enough to be "guarenteed" fast, but high-level enough so that it provides IHVs the opportunity to optimize for their hardware. This is where a graphics API should be. I agree with you that a graphics API, with actual hardware architectures, should be high level enough to allow IHVs to optimize their implementations.
But what about in 3 or 5 years, don't you think graphic hardware would have becomes so generic that it would be nothing to optimize at graphic level ?
I am not an expert in hardware architectures but we see ATI unifying their shaders, adding programmability to primitive assembly state and letting the same unified processor doing the job. So what will stay not programmable? May be the rasterization, I don’t know how it is managed to be efficiently computed in a parallel way ...
I don't know but don't you thing in quite short term GPU will loose their hardware pipeline and becomes simple massively parallel, high performance computing devices ? Like the clearspeed board (http://www.clearspeed.com/downloads/Architecture%20Whitepaper.pdf) as instance.

And DPVM only talk about command and memory control, it is what we need for 3D pipeline implementation. It don’t expect IHVs to use the same "shaders" binary format, it let sending a binary to the board. Binary that could be compiled from higher level language.

This way to full genericity is only my feeling, maybe am I wrong, maybe it is a naive vision, maybe hardware have to be specialized to stay efficient, but IHVs seems to go in that way.

Korval
08-17-2006, 12:44 PM
I don't know but don't you thing in quite short term GPU will loose their hardware pipeline and becomes simple massively parallel, high performance computing devices ?I don't really care what the hardware looks like. The graphics API OpenGL will still abstract to it, which is all I really ask of APIs.

That the device happens to be more generic than OpenGL exposes is utterly and completely irrelevant to me. As long as the API works, gives me access to the appropriate features of the hardware for doing graphics work, and abstracts all hardware in a performant manor, I don't care.

If the graphics card contained a PS3 Cell CPU instead of a GPU that was doing "software" scan conversion through its 8 functional units, OpenGL would still abstract it. And I would neither know nor be required to care about the difference (except where performance and features are an issue). Maybe it compiles the shader into SPU code of some form; I neither know nor care.


but IHVs seems to go in that way.No, ATi may be going that way. Maybe nVidia's going a different way; they certainly don't seem to care much for reuse of shader processing assets, for example.

Meanwhile, I don't want to have to have special paths for ATi and nVidia hardware. Indeed, if I have to do, then OpenGL has failed to do its job.

HellKnight
08-27-2006, 03:21 PM
What I'd like to see is a general interface for "linking" the output of a vertex/fragment program to the input (represented as an argument for example) of another program in the same shader.
Of course there's the possibilty to do it yourself, and there are efforts in this direction AFAIK, but having the driver do it may deliver better/optimized low-level code.
I'm thinking of having some sort of "base" shader, while layering effects on top, depending on desired quality/performance.

Do you think providing such functionality would in fact lead to faster shaders or is this task better left to an external library?

Korval
08-27-2006, 04:52 PM
What I'd like to see is a general interface for "linking" the output of a vertex/fragment program to the input (represented as an argument for example) of another program in the same shader.Your use of terminology makes no sense.

Programs are composed of shaders. And a linked program is a single, immutable entity (or will be in the new model).

If you reverse your terminology (switch your use of the terms "program" and "shader"), it still makes no sense because you already have that.

The "output" of a shader is whatever you want it to be. If you want function A in shader A to write to variable A, so be it. If you want function B in shader B to read from variable A, you can do that. All you must do is what you do for C++: declare the variable in the same way with the same name in each compiled shader. Then, when you link the program, everybody's happy.

HellKnight
08-28-2006, 01:33 AM
Sorry for the terminology mess.


The "output" of a shader is whatever you want it to be. If you want function A in shader A to write to variable A, so be it. If you want function B in shader B to read from variable A, you can do that. All you must do is what you do for C++: declare the variable in the same way with the same name in each compiled shader. Then, when you link the program, everybody's happy.
Yes, assuming that shader A is a vertex shader and shader B a fragment shader.

I was talking about more shaders of the same type which can work on theirs own; however, instead of having the output of any function X be the output of the fragment shader B (which would normally be the case), "pipe" it to the input of the main function in shader C, for example, and so on.
Basically dynamically linking shaders of the same type together. Linking program A to program B would mean piping the output of the vertex and fragment shaders of program A to the input of the respective shaders of program B.

I hope this makes more sense now.

mjkrol
08-28-2006, 09:28 AM
Originally posted by HellKnight:
I was talking about more shaders of the same type which can work on theirs own; however, instead of having the output of any function X be the output of the fragment shader B (which would normally be the case), "pipe" it to the input of the main function in shader C, for example, and so on.
Basically dynamically linking shaders of the same type together. Linking program A to program B would mean piping the output of the vertex and fragment shaders of program A to the input of the respective shaders of program B.
If the hardware had such functionality - dynamically piping shaders of the same type - I expect we would have it exposed in GLSL or extensions to GLSL. However, having this piping exposed and not having it in hardware means that the driver actually has to do the work you are supposed to do.
Instead, do it smart on your side. Wrap every shader that you want to be "piped" into a single function that takes some input and returns a color. Then, if you have a pipe with 3 shaders: A->B->C, you can write a code (for CPU) that generates the connections in main():

struct pipe {
vec4 FragColor;
float FragDepth;
};

void main () {
// prepare
pipe p;
p.FragColor = gl_Color;
p.FragDepth = gl_FragDepth;

// traverse
p = A (p, some interpolants);
p = B (p, some interpolants);
p = C (p, some interpolants);

// write
gl_FragColor = p.FragColor;
gl_FragDepth = p.FragDepth;
}

HellKnight
08-28-2006, 10:59 AM
This is of course the "standard" solution so far, but I was assuming that the driver may be able to further optimize the produced, linked code.
For example, if you set COLOR.r to 1 in A but set it to 0 in C you wouldn't need the first operation.

I don't know, maybe it's useless indeed, I was just "thinking aloud".

Korval
08-28-2006, 11:15 AM
Yes, assuming that shader A is a vertex shader and shader B a fragment shader.No, you didn't listen. Shader A and Shader B can be of any type. Even the same type. In fact, what I just said doesn't work if they're of different types.

Think C++:

A.cpp:

float fSomeVar;

void funcA
{
fSomeVar = 5;
}B.cpp:

float fSomeVar;
void funcA();

void main()
{
fSomeVar = 6;
printf("%f\n", fSomeVar);
funcA();
printf("%f\n", fSomeVar);
}Executing the program prints:


6
5They share fSomeVar. Glslang allows for this too, as each compiled shader operates as though it were a C++ object file. You can link multiple compiled shaders (of the same type) to form a fully linked program. And they can cross-talk via standard C++-style methods.

HellKnight
08-28-2006, 11:29 AM
Then my post was useless indeed :)

Golgoth
08-28-2006, 09:04 PM
quote:
--------------------------------------------------------------------------------
Originally posted by Cyril:
GPGPU is a growing domain, GPU becomes more and more generics stream computers, and today the war for physics acceleration in video games is engaged. Whay can't we expand the concept of OpenGL ML, that was thinked for OpenGL and so only for 3D acceleration, to generic stream architectures abstraction ?
--------------------------------------------------------------------------------

NO, NO, NO and NO.

(sorry for being OT)

This GPGPU stuff is plain nonsense in my eyes.
Either it's a GPU or a CPU!
What we need is a faster GPU and not an additional CPU.
I do agree to some extend with Cyril… “GPU becomes more and more generics stream computers” it has to go that way and my guess is it surely will… physic has ultimately no place there indeed but the line is getting blurred on do and don’t with the gpu because of how it is actually designed. for instance, getting more power under the hood for complex texture lookup when processing relief mapping in glsl FS… will be a definite plus… even for… if, else, else if and bool operations… I think it is more interesting (design wise) to use conditions in shaders then fragmenting them with “OPTION Strings” or whatever we calling it…

tfpsly
08-29-2006, 09:37 AM
Originally posted by Korval:

Yes, assuming that shader A is a vertex shader and shader B a fragment shader.No, you didn't listen. Shader A and Shader B can be of any type. Even the same type. In fact, what I just said doesn't work if they're of different types.What you want is the equivalent of D3D's shader linker. Which is a bit usefull, but which has several bugs.

An example of use is when you merge several subprograms in a vertex shader :
the first part being either anime mesh+transform code or just transform code, the second part will prepare the lighting method you want to use (for phong, toon... in world space or tangent space), the third part may add whatever effect you want and so on...

Of course this can be emulated by including several subpart of shaders and by having some function name convention for each part.

HellKnight
08-29-2006, 09:53 AM
Originally posted by tfpsly:
What you want is the equivalent of D3D's shader linker. Which is a bit usefull, but which has several bugs.
[/QB]I think it may be VERY useful now and in the near future. There are a billion ways to light a given surface, but some are more common than others. Why not form some "mini-shaders" written in a consisten way and then use those to create a material in a "building blocks" manner?
Take relief mapping for example. F.e. you can adjust the binary/linear acciracy (steps), whether it is self shadowed or not, etc. Instead of writing a whole shader for each possible combination of those parameters, write a basic one, then the shadowing shader and so on, and combine them in the way you like.
Then assume you'd like to assign some sort of "rain" shader applied to that very same surface. You'd need to rewrite all those relief shader versions with that rain effect too, and so on.

And imagine how the situation will look with those next-gen games with thousands and thousands of materials.
Clearly a great waste of time and effort.

Of course one could make an "offline" tool to assist combining and building all those possible combinations, but it's more elegant to having the engine handle it IMO.

knackered
08-29-2006, 10:15 AM
GLSL already has a link stage, for heavens sake. Hellknight you're talking about what I have already implemented in my renderer, it's nothing new or wizzy.

Golgoth
08-29-2006, 05:23 PM
Hi all!


GLSL already has a link stage, for heavens sake. Hellknight you're talking about what I have already implemented in my renderer, it's nothing new or wizzy. I m trying to figure this out for awhile now… HellKnight mentioned a gray area within glsl… at least for me… it may be off topic do go any further on this but I m still confused about it and it seams to have no “how to” documentation on this… so ll take the chance.

afaik… we can “link” only one main{} of either vertex or fragment shader to a glsl program… to add a function to your main fragment shader for instance, you ll end up “attaching” a shader to the same program… (linking is not necessary).

myShader.frag
Vec4 myFunction();
void main(void)
{
Vec4 color = vec4(0.0);
color += myFunction();
gl_FragColor = color;
}

myFunction.frag
Vec4 myFunction(void)
{
// do something.
Return vec4(something);
}

myFunctionDummy.frag
Vec4 myFunction(void)
{
Return vec4(0.0);
}It is as far as I could get for now… my first idea was to attach or not the myFunction.frag or myFunctionDummy.frag depending on the render states needed… I feel that this is a retarded concept from my part but I cant figure anything else so far… what did I missed here?

Dirk
08-29-2006, 06:25 PM
Originally posted by knackered:
GLSL already has a link stage, for heavens sake. Hellknight you're talking about what I have already implemented in my renderer, it's nothing new or wizzy. Care to elaborate (in a new thread, preferably, as this is getting a little OT)? I'd be interested what he components are that you have, and how you connect them.

Thanks

Dirk

Korval
08-29-2006, 08:01 PM
There was a thread around here a month or so ago discussiong megashaders and options for building shaders from subsections. I detailed everything you would ever need to know about accomplishing this task in there.

However, since I already did your job as a programmer, I'm not going to do a forum search and link you there. This will now be your job.

In fact, as I recall, Golgoth, it was your thread where this was posted!

Golgoth
08-29-2006, 10:20 PM
In fact, as I recall, Golgoth, it was your thread where this was posted!yes, that is true Korval, here it is dirk: here (http://www.opengl.org/discussion_boards/ubb/ultimatebb.php?ubb=get_topic;f=3;t=014546;p=1)

like I ve mentioned, there is something I ve missed or there is a black hole regarding this issue. Your concept works fine when using the same function for lighting types for instance… this is useful for “variations” of a function.... but what if you declare a function in your main but it turns out you wont be using it... at all... the shader wont compile if you do not define the function that as been declared... I just feel that the whole mosaic concept could use a design revamp and/or maybe Opengl LM could be inspire by something closer to cg for that matter… just a thought.

knackered
08-30-2006, 03:05 AM
Originally posted by dirk:
Care to elaborate (in a new thread, preferably, as this is getting a little OT)? I'd be interested what he components are that you have, and how you connect them.

Thanks

Dirk Actually no I wouldn't care to elaborate. Just spend 5 minutes thinking about it and there's your solution.
Preferably in a new thread, indeed....tut!

HellKnight
08-30-2006, 03:22 AM
Two of the possible solutions have been presented in this thread anyway (using a global var or constructing the main() function yourself, invoking your shader functions) so it shouldn't be too hard to implement it I guess.

Dirk
09-05-2006, 12:52 PM
Originally posted by Golgoth:
yes, that is true Korval, here it is dirk: here (http://www.opengl.org/discussion_boards/ubb/ultimatebb.php?ubb=get_topic;f=3;t=014546;p=1)
Thanks for the link! I think there is a lot more to shaders these days, since they do a lot more than just calculating lighting, but the thread gave me some interesting impulses.

Thanks

Dirk

tfpsly
09-06-2006, 07:03 AM
Originally posted by HellKnight:
Two of the possible solutions have been presented in this thread anyway (using a global var or constructing the main() function yourself, invoking your shader functions) so it shouldn't be too hard to implement it I guess. Or even simpler : put your main function in the megashader file, and include it in your shader file, preceded by several defines :
#define USE_PHONG_LIGHTING 1
#define USE_TOON_LIGHTING 0
#define USE_NORMAL_MAPPING 1
and the likes.

That how I'm able to preview my megashader from Maya, where these "defines" appears as variables that the artists will alter inside the Maya GUI, and that I would export as defines.