PDA

View Full Version : OpenGL 3 Updates



Pages : 1 [2] 3 4 5 6 7

wien
12-06-2007, 12:29 PM
[quote=Kazade]The "short" summary in Wikipedia about C++0x makes me wonder, whether they just decide to put a feature in there, or whether they are sure it is easily implementable.
I couldn't find the video, but Bjarne Stroustrup said in a presentation of C++0x a while back that he knew of implementations of every proposed feature in that list except a few. No vendor has them all implemented of course, but I wouldn't worry too much about them being "unimplementable". They seem to be on top of things.

Xmas
12-06-2007, 06:09 PM
So even if GC doesn't hit C++0x, they're looking for it to hit C++13 or C++15.
I certainly hope C++ is dead by then.

But regarding GL3, to paraphrase Miyamoto: A delayed API is eventually good, a bad API is bad forever.

Suncho
12-07-2007, 12:47 AM
A better option would be to use format objects, but allow them to be specified incrementally, so that the addition of one particular aspect can be detected as the point of failure.

I had the same thought. Is there any reason why this wouldn't work or wouldn't be a good idea?

Brolingstanz
12-07-2007, 04:32 AM
I am in desperate need of a new newsletter :( .

I'm right there with you, HexCat.

I need a newsletter fix and I need it fast.

Igor Levicki
12-10-2007, 06:02 PM
Any chance to add an API to the 3.0 spec which will enable us to copy 2D texture into 3D texture slices (on-device copy)?

As for C++0x they are brain dead, they said they won't include aligned new[] operator because wait for it, wait for it... malloc() doesn't support alignment! I mean how stupid does that sound? "Gee, 40 years old C doesn't have something so we shouldn't have it too." Bureaucrats.

Korval
12-10-2007, 10:44 PM
Any chance to add an API to the 3.0 spec which will enable us to copy 2D texture into 3D texture slices (on-device copy)?

You mean like:

glBlitFramebufferEXT (http://www.opengl.org/registry/specs/EXT/framebuffer_blit.txt)?

Jan
12-11-2007, 06:17 AM
But AFAIK most implementations of malloc align on 16 byte boundaries. They NEED to align on 8 byte boundaries, because the biggest variable-type on 32 Bit machines (double) is 8 bytes wide and needs to be aligned.

When i did my own memory-manager some time ago i detected, that at least malloc under Visual Studio always aligns to 16 byte boundaries.

Jan.

Nicolai de Haan Brøgger
12-14-2007, 05:50 AM
Hi everyone. I looking for a new graphics card (8800 GT or GTS) but does anyone have information about if drivers to OpenGL 3 will be released for those cards? As far as I can read from the pipeline newsletters, the API changes for Mt. Evans only include hardwar features already present in DX10 and so should be possible to support on that hardware? Maybe it's best to wait until the specifications have been released to be sure...

Zengar
12-14-2007, 07:08 AM
It was stated lots of times that Gl3.0 will be aviable for GFFX and better. GL3.0 != Mount Evans

Hampel
12-14-2007, 08:20 AM
and I thing: GL3.0 > Xmas... :-(

Seth Hoffert
12-14-2007, 01:08 PM
GL3.0 > life

Roderic (Ingenu)
12-15-2007, 04:16 AM
A little bird told me Q1 2008.
(Told me so mid november)

pudman
12-15-2007, 10:36 AM
What would be the reason that bird doesn't just tell all of us?

dor00
12-15-2007, 11:35 AM
Ok, what I don't understand is why is so silence about that subject, I mean, peoples who can give us more info are so quite...

Brolingstanz
12-17-2007, 05:27 AM
Does anyone know how the various render states are to be partitioned into objects, or is that still up for grabs?

(D3d10 basically splits them up into Rasterizer, Depth/Stencil and Blend.)

Or does it make more sense, at a lower level, to have a single render state vector (object) that the app manages itself?

Just curious if there's a consensus on this yet.

Korval
12-17-2007, 12:48 PM
Does anyone know how the various render states are to be partitioned into objects, or is that still up for grabs?

It's probably still up for debate, but the last actual information suggested that there would be rasterizer state objects and post-fragment state objects (encapsulating depth, stencil, blend, etc).

HenriH
12-17-2007, 01:16 PM
Is there any idea how this would be implemented in Windows? Do we still have to use that old ChoosePixelFormat, SetPixelFormat, wglCreateContext etc.? I really hate the fact that I must use wglGetProcAddress to get into post GL 1.1 API, or use third party library like GLEW. And besides, WGL is old! Is there any way to get around with this defect, so we could someday have a full featured OpenGL 3.0 header file and up-to-date WGL?

Cheers,
Henri H

Brolingstanz
12-17-2007, 02:09 PM
The extension mechanism works like gangbusters.

There are things far worse than loading a few extension procs, I'll be bound.

HenriH
12-17-2007, 04:20 PM
Well, I seriously dislike the fact that I need to dynamically load most of the core API. Compare this to D3D where you can just include one header file and you have it all. But I guess there is nothing to do about this, since it's Microsoft who controls opengl32.dll on Windows.

Zengar
12-17-2007, 08:28 PM
HenriH, just use GLEW or similar.

Overmind
12-18-2007, 04:40 AM
Compare this to D3D where you can just include one header file and you have it all.

Compare this to D3D where you have to use a completely new API for each generation of hardware :P

There are people out there who care about backwards compatibility, at least one generation back. With the D3D method, it's an all or nothing approach. If you want older hardware, you have to use the older API. If you want newer features, you have to use the newer API. If you want both, you have to write two renderers. If you want to use hardware that's between versions (not all features of DX10, but some of them), you're simply out of luck.

The extension mechanism is not about MS controlling the DLL on windows (Hint: there is an extension mechanism on Linux). It's about being able to code fallbacks without getting "entry point not found" errors on old systems.

Timothy Farrar
12-18-2007, 07:36 AM
Well, I seriously dislike the fact that I need to dynamically load most of the core API. Compare this to D3D where you can just include one header file and you have it all. But I guess there is nothing to do about this, since it's Microsoft who controls opengl32.dll on Windows.

Now you wouldn't want GL to require kernel calls would you (bad batch performance)....

santyhamer
01-03-2008, 05:55 PM
ok.. the good news are that OpenGL 3 spec gonna be released this year then?

Simon Arbon
01-03-2008, 06:15 PM
The good news is that pipeline 006 is due out, (Q4 2007)
so they will be able to give us an update in pipeline 005,
release OpenGL3,
and then use oo6 to tell us all about the release. :D

dor00
01-03-2008, 07:25 PM
Happy new year people!!

I check daily the forum, I hope the release will be soon:)

/peace

Jan
01-04-2008, 07:15 AM
Yes, a Happy New Year!

Would be nice to get some information about OpenGL's status.

Jan.

Demirug
01-04-2008, 08:01 AM
Compare this to D3D where you have to use a completely new API for each generation of hardware :P

There are people out there who care about backwards compatibility, at least one generation back. With the D3D method, it's an all or nothing approach.

Yes. Direct3D doesn’t support an official extensions mechanism. Some drivers do it anyway with so called “API-Hacks”. But this is a somewhat ugly thing.

You criticize Direct3D for not being backward compatible for older hardware. This is right for Direct3D 10 and I have criticized this, too. But former Direct3D version work with older hardware. The runtimes can even work with older drivers. The Windows XP Direct3D 9 runtime needs a Direct3D 7 driver to work. If we look at the future the Direct3D 10.1 runtime will work with Direct3D 10 drivers. There is no official statement about Direct3D 11 yet but IMHO Microsoft will go back to the old road and make it work with Direct3D 10 compatible hardware.


If you want older hardware, you have to use the older API. If you want newer features, you have to use the newer API. If you want both, you have to write two renderers.

Not sure how you implement API independency. We don’t use two renderer only small layers above the native APIs to unify the interface. The renderer then work against this interface.


Now you wouldn't want GL to require kernel calls would you (bad batch performance)....

OpenGL requires kernel calls, too. The differences on Windows XP it that Direct3D runtime may produce more calls as the main decision point is in the kernel driver. For OpenGL most decisions can be done in the user mode driver. Windows Vista uses the same model now for Direct3D, too.

Yes using the old Windows 95 driver model for Windows 2K/XP was a bad decision even if it may sounds right at this time.

HenriH
01-08-2008, 04:47 PM
There are people out there who care about backwards compatibility, at least one generation back. With the D3D method, it's an all or nothing approach. If you want older hardware, you have to use the older API. If you want newer features, you have to use the newer API. If you want both, you have to write two renderers. If you want to use hardware that's between versions (not all features of DX10, but some of them), you're simply out of luck.


If you really want to support legacy hardware, you still need to write two renderers (or at least renderer backends) even for OpenGL. Consider for example, how Carmack implemented multiple renderer backends for his Doom 3 engine. One for prior GL2, one for generic GL2, one for ATI and another for nVidia cards.

Korval
01-08-2008, 06:18 PM
If you really want to support legacy hardware, you still need to write two renderers (or at least renderer backends) even for OpenGL. Consider for example, how Carmack implemented multiple renderer backends for his Doom 3 engine.

Not anymore. At least, not these days.

Remember: Doom3 was released at the beginning of the transition from configurable fixed-function to actual programmability. So writing entirely different backends for rendering was a requirement. Legacy hardware meant "GeForce2's, 3's, and 4's".

Nowadays, legacy hardware is R300's and NV40's; GeForce4's and Radeon 8xxx's are basically non-existent. These are GL 3.0-capable hardware. That's why the ARB is willing to set a minimum functionality for GL 3.0 (I guarantee that before they set that minimum, they asked developers what hardware it should be).

Nowadays, supporting legacy hardware means writing different shaders (and the meshes to go with them, of course). There is less need for having actually different rendering code, so long as your code can select shaders based on something detectable like functionality, etc.

The big problem now is just driver bugs/non-functionality. That's where 90% of the specialized rendering code comes from in a modern engine.

sylware
01-09-2008, 03:30 AM
What's up with opengl 3?
Will it go through a public review before being frozen for good?

Brolingstanz
01-09-2008, 02:33 PM
What's up with opengl 3?
Will it go through a public review before being frozen for good?

By public I'm guessing you mean private? :-)

Cgor_Cyrosly
01-13-2008, 09:12 AM
OpenGL3 approximately how long?One month , two Month or still not
determined?
That tests people's patience!

HenriH
01-14-2008, 08:46 PM
Any news from any other sources? Nvidia?

Zengar
01-14-2008, 11:02 PM
What does Nvidia has to do with it? They can't say anything till the spec is out, there is such thing as NDA... I hate to say it, but we just have to be patient, as there is absolutely nothing we can do right now. If the "meetng three times a week" were really true, the spec shoupd have been finished a long time ago, so something had to go wrong...

Roderic (Ingenu)
01-15-2008, 01:09 AM
I expect it Q1 2008 with drivers.

The calm before the storm...

We all know it's coming, but I agree it's becoming annoying to have to wait in silence with only the echo of our own voices...
(And to me OpenGL 3.0 is *only* the 3DLabs OpenGL 2.0 "Pure" proposal from so long ago... about time it becomes available :p)

Cgor_Cyrosly
01-15-2008, 06:18 PM
If we can just become the staff of NV or ATI that as we can know in advance the technology to realize GL3.0 :tired:

Cgor_Cyrosly
01-15-2008, 06:28 PM
Hope that not as has the "fahrenheit" as halfway mortality

Korval
01-15-2008, 07:07 PM
Hope that not as has the "fahrenheit" as halfway mortality

Nothing was every really known about Fahrenheit. A lot more is known about GL 3.0 even now than was ever made available about Fahrenheit.

What's strange is this: When they were a month late, they actually told us what was going on. They told us why they were late and what they were doing. And they gave us more information about what GL 3 was shaping up to be (minimum requirements and such).

But now, the most we get are vague posts from ARB members to the tune of, "Should be in the next 2 months." We were also promised that "More details will follow soon in an upcoming OpenGL Pipeline newsletter," but that was almost 3 months ago.

It's not so much the delay itself that's annoying, but the complete lack of information. Not necessarily about why the delay has happened, but just the current state of things. The last few Newsletters have painted a pretty reasonable picture of what GL 3's API will look like. Is this information still valid, or have there been substantial changes? And so forth.

tranders
01-15-2008, 08:42 PM
Nothing was every really known about Fahrenheit. A lot more is known about GL 3.0 even now than was ever made available about Fahrenheit.
Actually there was quite a bit known about Fahrenheit. Microsoft even shipped XSG 1.0 with quite a bit of documentation and sample code -- I even have the disks and manuals to prove it but there was documentation. Granted it came with a note saying that no further support or development would take place.

Fahrenheit was a prime example of lack of cooperation between partners for fear of losing a competitive advantage. The hope is that GL3 is not stalling for similar reasons.

sylware
01-16-2008, 02:46 AM
Well... maybe we should let down nameless announcement.
Can somebody reach a real physical person in charge to get us more information?

plasmonster
01-16-2008, 02:38 PM
I take the delay as a good omen, a portent of great things afoot! :)

pudman
01-16-2008, 02:53 PM
I take the delay as a good omen, a portent of great things afoot! :)

Normally when you don't hear from someone in a long time (longer than expected or past when they said they would contact you) you call the police and start looking for a body. :D

PaladinOfKaos
01-17-2008, 09:45 AM
This is starting to look really bad for the ARB... they're about four months behind their projected schedule for LP, and that's off the latest announced delays. The silence doesn't help, either... OpenGL really needs LP and ME, and delays are killing the credibility of those standards.

At this point there are really only three conclusions I can come to: there was something horribly wrong with the standard, one (or more) of the ARB members is (are) stalling the standard for their own reasons, or there's some sort of red tape or power struggle going on with the Khronos Group. None of those bodes well for the standard coming out any time soon, and the last two could cause serious problems for a long time to come, even if LP makes it out.

Rob Barris
01-17-2008, 04:45 PM
The working group has been meeting 4-5 times a week for the last couple of months. There are indeed some changes afoot and it would be my hope that we can share more specifics soon.

The face to face meeting of Khronos member companies is coming up next week in Portland, Oregon; raising the "cone of silence" is a top priority because we know the community is eager to learn more about the next GL revision.

It's not my place to provide any more details at this point other than to share my optimism that some deep seated conflicts are finally being resolved between the contributors on a number of levels, a trend I hope to see continue.

Roderic (Ingenu)
01-18-2008, 01:31 AM
Keep up the good work, we've (at least I) been waiting for a complete OpenGL rewrite for a very long time now, hence the lack of patience some/many exhibit now...

santyhamer
01-18-2008, 11:19 AM
I think is better to wait and get all the problems solved than launching a bad designed API. There is no need to hurry really... Vista(and DX10) market-share is very poor ... and, from my experience, DX10 is really bugged atm ( specially the fxc compiler and immature drivers )... not useable I would say...

Btw... anybody know if Intel was trying to adapt the API for Larrabee? :D

sylware
01-22-2008, 01:36 AM
As far as I understood the larrabee thing from Intel, it's a general processing vector chip. At the beginning you will code for it like any other SMP machine. The thing is that SMP means in current OSes (except Linux) a few cores. Those chips will probably need new APIs to be coded properly (means not POSIX).
I don't think it will be able to catch in speed texture mapping of NVIDIA/ATI if not done directly on the silicium. Texture mapping, with its intensive memory management requirements, is more and more complex to manage (see the Mesa DRM and the new architecture Gallium3D). The next engine from ID will stream giant textures...

sqrt[-1]
01-22-2008, 05:16 PM
Most of the Internet rumors of Larrabee seem to indicate that it does have dedicated texturing hardware.

Korval
01-22-2008, 05:34 PM
Most of the Internet rumors of Larrabee seem to indicate that it does have dedicated texturing hardware.

It will also almost certainly have basic scan-conversion hardware too. And probably some specialized memory architectures (the post T&L cache for example) and such. I mean, it is a GPU, even if a fairly generic one by nVidia/ATi standards.

santyhamer
01-24-2008, 05:26 AM
Well, I think gonna be interesting to see if Intel is collaborating actively in the OpenGL 3 spec. Larrabee prototype is supposed to be presented by the end of 2008... so I bet they need to be very present in the ARB and to release some extensions soon ( in case they don't use a 100% propietary API ).

Chris Lux
01-26-2008, 05:16 AM
The face to face meeting of Khronos member companies is coming up next week in Portland, Oregon; raising the "cone of silence" is a top priority because we know the community is eager to learn more about the next GL revision.
so one week later... ;)

i hope no new differences came up.

HenriH
01-29-2008, 05:32 AM
It's the end of January and OpenGL 3 still out of sight :p I feel troubled. I get the feeling that we won't see the spec in months and proper implementation until Autumn, if ever. This may be even the end of OpenGL, as DX10 is getting more and more usage in games industry.

Jan
01-29-2008, 06:22 AM
At first i was patient. Then i became worried. But now i am angry.

This is turning into a farce. The last time this happened, we got OpenGL 2.0, the biggest disappointment one could imagine.

There is only a small time window left for OpenGL to fill the gap, that D3D10 has left. Once Vista has got enough momentum, OpenGL will be dead, if it isn't absolutely great. For that there does not only need to be a spec, but also really good drivers. Drivers will take at least a year. If the spec isn't done soon, we can forget about it.

So get on with it!

Jan.

CatDog
01-29-2008, 07:10 AM
I started to add a layer of abstraction to my application. Just to be prepared to switch to DX if needed. Unfortunately, I didn't do this, when the project was started a few years ago. My guess is, that I'm not the only one with this problem and I'm shure, that this is the reason for OpenGL not being dead right now.

If I had to start a new project today, I'd use DX (and that abstraction layer). Sorry GL.

CatDog

bobvodka
01-29-2008, 07:28 AM
More details will follow soon in an upcoming OpenGL Pipeline newsletter.

Barthold Lichtenbelt
OpenGL ARB Working Group chair

3 months on and still no 'soon'? :(

I don't think it's so much the lack of spec it's the lack of communication which is getting to everyone and given that I'm pretty sure at SIGGRAPH there was praise being spouted about communicating with the community this is just very poor form indeed.

Brolingstanz
01-29-2008, 07:43 AM
you guys are kidding, right?

CatDog
01-29-2008, 08:25 AM
Maybe exaggerating a little bit.

-NiCo-
01-30-2008, 01:50 AM
Being a GPGPU programmer myself, I need little more than textures,FBO,RTT,MRT,VBO and shaders so moving to DX is no problem for me, especially since I already encapsulated them into C++ classes. The reason I chose OpenGL was because of it's cross-platform support and because I believe it to be a cleaner API than DX.

Most of the time I'm running Linux so I'm basically stuck with OpenGL and in order to have access to the latest features in DX I would need to move back to vista. Please hurry up and save me from this horrible fate, ARB!

N.

Timothy Farrar
01-30-2008, 10:03 AM
If I had to start a new project today, I'd use DX (and that abstraction layer). Sorry GL.
CatDog

My code already abstracts out the GL calls, so I'm also considering a DX interface as well if necessary. The real danger of this is that once a developer has a DX code base, it doesn't take a rocket scientist to look at total sales by platform and simply decide that its not worth keeping anything but a DX interface on Windows. Once that point is met, developer is gone for good.

However on a positive note, one thing that GL definitely has in its favor is that MS made DX10 Vista only and stalled the entire industry, buying GL3 and friends some more time. According to current Valve survey results, only 13% of users have Vista, and of the rest, about 31% of the DX9 SM3.0 users actually have a DX10 capable card without Vista. Had MS rolled out DX10 for XP, game devs would have actually been able to seriously use DX10 (SM4.0) giving consumers a good reason to upgrade GPUs, and widening the gap between DX and GL.

Really it's not just GL3 which is in limbo right now!

GL2 still does SM3.0 very well, and GL2.1 with NVidia's drivers does most of SM4.0 really well on XP (without Vista).

So perk up people, if they get GL3 right in 2008, things will look rather good!

Warshade
01-30-2008, 10:52 AM
My hope is that the working group members noticed that releasing 3 APIs (Mt. Evans, LP and LP reloaded) is a DirectX approach of things, and the delay is caused by them seeking ways to design a single API, which makes use of Extension mechanisms to include all the features. It would be weird if the 3 APIs are so fundamentally different, that it's not possible to find a common denominator? Personally I'd rather like to see 1 new OpenGL 3 API, than 3 new OpenGL APIs.

I don't intend to start any rumors, but the above could explain the delay, and the silence about progress. The only thing i'm positive about is that they'd have released way more information if the changes they are working on would be trivial.

@People who are threatening to switch to DX:
Seriously, if that works I'd like to threaten to switch to DX too, unless the working group members wire me 1 gazillion $ to my swiss bank account...

Korval
01-30-2008, 11:50 AM
My hope is that the working group members noticed that releasing 3 APIs (Mt. Evans, LP and LP reloaded) is a DirectX approach of things, and the delay is caused by them seeking ways to design a single API, which makes use of Extension mechanisms to include all the features.

So, what you're saying is that you don't actually understand what they're doing.

GL 3.0 (LP) is a fundamentally new API. LP Reloaded are some relatively minor extra features/functionality added to that API. Mt Evans is some relatively substantial extra features/functionality added to that API. At no time are any of them "new API" except for 3.0.

speedy
01-30-2008, 12:22 PM
I think AMD/ATI could buy some more time for the 3.0 spec. if they would release support for their advanced hardware features in 2.x as extensions.

Then 3.0 would come on top (whenever it comes to light) as a pretty syntactic sugar layer. ;)

Warshade
01-30-2008, 12:33 PM
What I do not understand is: if Long Peaks is the new core API (call it OpenGL 3.0 or whatever), why not realize Mt. Evans and Reloaded features as Extensions, rather than branch it into 2 more APIs?

Korval
01-30-2008, 01:16 PM
why not realize Mt. Evans and Reloaded features as Extensions, rather than branch it into 2 more APIs?

They are! That's what I just got through explaining to you.

Warshade
01-30-2008, 02:01 PM
Thanks alot for clarifying that :)

Since this is what I hoped for, I'd like to join the protesters now who nag for an update.

Seth Hoffert
01-30-2008, 02:42 PM
I am extremely grateful that NVIDIA has created so many wonderful OpenGL extensions. Keep up the great work NVIDIA!!!

Timothy Farrar
01-30-2008, 09:06 PM
I am extremely grateful that NVIDIA has created so many wonderful OpenGL extensions. Keep up the great work NVIDIA!!!

I have a sneaking suspicion that part of the reason NVidia built the SM4.0 GL extensions was because the G80 was ready before DX10 and they wanted to test stuff... ;)

Anyway, NVidia is a great example of how to do GL right. Weren't they advertising that 95% of the driver code is shared between operating systems and platforms. Having unified drivers working across Windows, Linux, Solaris, and even FreeBSD, is simply awesome and a smart idea. My only wish is that Apple would get with the program and help adapt NVidia's unified driver instead of rolling their own which is missing lots of features.

sylware
01-31-2008, 02:40 AM
I am extremely grateful that NVIDIA has created so many wonderful OpenGL extensions. Keep up the great work NVIDIA!!!

I have a sneaking suspicion that part of the reason NVidia built the SM4.0 GL extensions was because the G80 was ready before DX10 and they wanted to test stuff... ;)

Anyway, NVidia is a great example of how to do GL right. Weren't they advertising that 95% of the driver code is shared between operating systems and platforms. Having unified drivers working across Windows, Linux, Solaris, and even FreeBSD, is simply awesome and a smart idea. My only wish is that Apple would get with the program and help adapt NVidia's unified driver instead of rolling their own which is missing lots of features.
I would prefer them to release the programming specification in order to speed up nouveau (Linux NVIDIA open source driver) dev.

Seth Hoffert
01-31-2008, 06:55 AM
Why, though? The closed source driver works fine as it is. ;)

I use Linux for all of my OpenGL development and I am able to use all of the new SM4.0 features, so I am in heaven.

EDIT: Okay, it might be kind of cool to be able to experiment with extension modification... ;)

Timothy Farrar
01-31-2008, 09:00 PM
I would prefer them to release the programming specification in order to speed up nouveau (Linux NVIDIA open source driver) dev.

Be careful what you wish for, isn't this what AMD/ATI is doing ... care to take a stab at how long it will take before you see SM4.0 support in the open source drivers for the HD cards on Linux?

sylware
02-01-2008, 01:29 AM
Be careful what you wish for, isn't this what AMD/ATI is doing ... care to take a stab at how long it will take before you see SM4.0 support in the open source drivers for the HD cards on Linux?
AMD/ATI has not released 3D programming specifications. But they are still working on it with sample code. Heard Intel did release its GPUs documentation with 3D included and there is already working code.
Mesa works on Gallium, the new ultra light 3D driver framework (hope opengl3 will be *very* simplified too...)
Well, almost everybody is moving forward, except NVIDIA :( . The only thing NVIDIA has left: they make the fastest hardware... if AMD and Intel reasonably catch up in speed, meaning nvidia chips become not that faster that other chips, they are screwed because they will be *very* late and they will look bad. So the rumor that they would plot an open source strategy is not surprising.

bertgp
02-01-2008, 08:30 AM
Be careful what you wish for, isn't this what AMD/ATI is doing ... care to take a stab at how long it will take before you see SM4.0 support in the open source drivers for the HD cards on Linux?
AMD/ATI has not released 3D programming specifications. But they are still working on it with sample code. Heard Intel did release its GPUs documentation with 3D included and there is already working code.
Mesa works on Gallium, the new ultra light 3D driver framework (hope opengl3 will be *very* simplified too...)
Well, almost everybody is moving forward, except NVIDIA :( . The only thing NVIDIA has left: they make the fastest hardware... if AMD and Intel reasonably catch up in speed, meaning nvidia chips become not that faster that other chips, they are screwed because they will be *very* late and they will look bad. So the rumor that they would plot an open source strategy is not surprising.

Hmmm... That is not quite true. NVIDIA also have their excellent OpenGL drivers going for them. It is not trivial to write good driver code to provide an efficient OpenGL implementation. You need full-time dedicated programmers for that and much testing, especially considering that there is no single central test suite to test for OpenGL conformance. It's not something you can just do as a hobby and hope to achieve the same performance as the vendor's driver team. If you can, I'm sure they would love to offer you a good salary for it ;)

sylware
02-01-2008, 09:09 AM
Hmmm... That is not quite true. NVIDIA also have their excellent OpenGL drivers going for them. It is not trivial to write good driver code to provide an efficient OpenGL implementation. You need full-time dedicated programmers for that and much testing, especially considering that there is no single central test suite to test for OpenGL conformance. It's not something you can just do as a hobby and hope to achieve the same performance as the vendor's driver team. If you can, I'm sure they would love to offer you a good salary for it ;)

I was not talinkg about their proprietary driver for Linux. I'm talking about free (as in freedom) drivers and available hardware programming manual. And what you say is almost exactly what said the proprietary UNIXes guys when Linux started... but I won't troll anymore on this, since our worry right now is "where is opengl 3?". :)

Timothy Farrar
02-01-2008, 12:07 PM
I was not talinkg about their proprietary driver for Linux. I'm talking about free (as in freedom) drivers and available hardware programming manual. And what you say is almost exactly what said the proprietary UNIXes guys when Linux started... but I won't troll anymore on this, since our worry right now is "where is opengl 3?". :)

First, I'm also a fellow Linux GL programmer.

I would suggest you take a second to thing about this objectively for a second. NVidia's GL advantage isn't just speed (which could be arguable), it is that they actually produce good GL drivers, and they have a good market share. There is definitely an objective balance between open information about the hardware for programmers (which if you read through the NVidia's CUDA docs and PTX they are more than being generous with free information) and needs of a business to maintain a competitive advantage (private information) in order to keep producing great hardware.

When a company is going out of their way to both produce good drivers for platforms which might not even really be profitable like FreeBSD, and also is going out of their way to generate GL2 extensions which allow you to use their hardware features long before GL3 will be ready, you've got the best you could ask for.

As for graphics, vendors are bound to get lots of feedback from game developers which they roll back into optimizations, updates, and bug fixes on drivers. With NVidia's unified driver source, these fixes would be basically "free" for those using Linux drivers. This simply would happen with open source drivers. Sorry, but there is no objective advantage for either Linux users or Linux programmers to have open source drivers when a company is handling providing binary Linux drivers (and detailed information, ie PTX) as well as NVidia is.

A wise thing might be to instead thank those at NVidia who are making it possible for you to have and enjoy a no hassle working GL2.1 SM4.0 driver on Linux.

Please do us and ourself a favor and be supportive! Serious professional vendor support is doing a lot for helping Linux become an alternative for many of us.

Now think about this in terms of GL3, which vendor do you think will have fully functional working GL3 drivers for Linux first, and how long before the other vendors get there?

Korval
02-01-2008, 03:03 PM
Serious professional vendor support is doing a lot for helping Linux become an alternative for many of us.

Sylware is talking about an ideological point, not a practical concern. He wants liberated drivers, those that are written under the guidelines set down by the Free Software Foundation. Whether they work better or worse than professional drivers is entirely irrelevant to the FSF ideology of free software above all.

Some Linux distros have a policy against including any non-"free" software, which makes nVidia's drivers useless.

elFarto
02-01-2008, 04:06 PM
Serious professional vendor support is doing a lot for helping Linux become an alternative for many of us.

Sylware is talking about an ideological point, not a practical concern. He wants liberated drivers, those that are written under the guidelines set down by the Free Software Foundation. Whether they work better or worse than professional drivers is entirely irrelevant to the FSF ideology of free software above all.

Some Linux distros have a policy against including any non-"free" software, which makes nVidia's drivers useless.

There's also a slight legal issue. The NVIDIA kernel module is technically a derivative work of the kernel, and therefore must be licensed under the GPLv2. So they (the kernel developers) could sue NVIDIA, but that'll get us nowhere as they'll just withdraw the driver.

Also the kernel is being (or was going to be) modified to make it legally impossible to make a closed-source driver. (There's more information here (http://thread.gmane.org/gmane.linux.kernel/475654/focus=475796)).

Regards
elFarto

Korval
02-01-2008, 05:33 PM
Also the kernel is being (or was going to be) modified to make it legally impossible to make a closed-source driver.

Wow, Linux just doesn't like being usable, does it? This doesn't even sound like Torvalds, who tends to be less ideological and more practical in his decisions.

Seth Hoffert
02-01-2008, 06:07 PM
Also the kernel is being (or was going to be) modified to make it legally impossible to make a closed-source driver.

It would be quite unfortunate if this were to happen. I would switch back to XP without hesitation, to be perfectly honest.

wien
02-01-2008, 08:13 PM
Also the kernel is being (or was going to be) modified to make it legally impossible to make a closed-source driver.I wouldn't go around announcing that just yet. Linus seems quite adamant he won't include anything like that unless most other trees (distros etc.) include it first.

elFarto
02-02-2008, 09:04 AM
I wouldn't go around announcing that just yet. Linus seems quite adamant he won't include anything like that unless most other trees (distros etc.) include it first.

Very true, You need to read the (very long) thread I linked to for the full story.

Regards
elFarto

Timothy Farrar
02-02-2008, 12:02 PM
Sylware is talking about an ideological point, not a practical concern. He wants liberated drivers, those that are written under the guidelines set down by the Free Software Foundation. Whether they work better or worse than professional drivers is entirely irrelevant to the FSF ideology of free software above all.

Some Linux distros have a policy against including any non-"free" software, which makes nVidia's drivers useless.

Which makes those distros effectively useless and of no consequence or importance to anyone wanting to run any OpenGL based software on Linux. I'm well aware of what his point was. When politics and ideology start to trump common sense and objective thinking, it is not good for anyone...

... well actually it might be great for FreeBSD! ;)

PkK
02-02-2008, 12:38 PM
Please remember that GNU/Linux has been created by a large extend by people that wanted _free_ software. While some users may see it just as an operating system competing for market share to many users and developers of GNU/Linux still value freedom to some degree.
I don't want non-free stuff in my kernel. I want vendors to release specifications like Intel does (and AMD claims to intend to do), so that there can be free drivers.

Philipp

Jan
02-02-2008, 01:18 PM
Since when did this turn into a discussion about Linux? I know we need a substitute, since there is no OpenGL related information whatsoever, but this discussion is slowly heading into a flame-war about free software, please stop that.

Jan.

Timothy Farrar
02-03-2008, 02:12 PM
How about some healthy GL3 speculation?

Is there a chance with GL3 that we will see the ability for some kind of ability to load some kind of pre-compiled shader objects?

Korval
02-03-2008, 11:15 PM
Is there a chance with GL3 that we will see the ability for some kind of ability to load some kind of pre-compiled shader objects?

According to the last info from SIGGRAPH, any such functionality would come, if it does, with LP Reloaded.

Unless they decided to fold it into LP due to the delay.

bobvodka
02-04-2008, 09:43 AM
At this point I'm tempted to say that folding LP Reloaded into GL3.0 would be a good idea.. however no knowing what the delay is makes it hard to judge these things...

I wonder if we'll hear anything before the end of feb?

santyhamer
02-04-2008, 10:53 PM
We will get OpenGL 3.0 LP spec at GDC by Feb 18-20. I'm a 105% sure!

Chris Lux
02-05-2008, 05:43 AM
We will get OpenGL 3.0 LP spec at GDC by Feb 18-20. I'm a 105% sure!
that's a overflow to 5%, right? ;)

sqrt[-1]
02-05-2008, 05:59 AM
That is because the "clamping of values" restriction was removed from hardware a long time ago.
This allows you to perform a nice bloom when you tone map your guesses.

Jan
02-05-2008, 12:53 PM
No, we will get this:
"We are SOOO excited, the spec is coming along SOOO well, we will release further information in the next regular newsletter, explaining yet another small detail with a 10 line example! LP will be ready sometime, MtE following sometime later, improving it even further!"

Honestly, i'm pissed off.

Jan.

Warshade
02-05-2008, 01:03 PM
Let's grab torches and pitchforks, then march to Beaverton?
It would sure be funny to see the looks on their faces when there's an angry mob of OpenGL users outside Khronos headquarters ;)

santyhamer
02-06-2008, 03:23 PM
Let's grab torches and pitchforks, then march to Beaverton?
It would sure be funny to see the looks on their faces when there's an angry mob of OpenGL users outside Khronos headquarters ;)

I did this on his computer:



c:\windows\system32> addspyware on Warshade's computer

hook installed on explorer.exe
NTFS data stream explorer.exe : 1 completed

c:\windows\system32> cls


See what I found! Looks like a plan!

http://img164.imageshack.us/img164/1508/torchesjd7.jpg

:D Mwahahaha!

RenderBuffer
02-06-2008, 05:39 PM
I honestly expect that if they could give us updates they would. My guess is that it's some IP issue they're trying to resolve, and they don't want to or can't talk about it until it is resolved.

We'll just have to sit and wait and do something productive in the mean-time. I'm taking the time to reevaluate my choice of shading languages.

Hampel
02-07-2008, 01:30 AM
And I am using the mean-time to implement a backend for the already existing and usable DX10-API for our rendering engine...

pudman
02-07-2008, 09:40 AM
They'd better start putting out some newsletters... only because after the 3.0 release there probably won't be enough to fill four quarters worth of newsletters.

The Pipeline: DOA.

Hampel
02-11-2008, 04:57 AM
They probably implemented a reference software rasterizer in parallel with their API specification and detected, that on current multi-core systems it was as fast as their hardware implementations.

So, they are thinking about, what else could be added to the specification, that can't be implemented in a software renderer, such as quantum teleportation for a wireless and untracable connector between graphics card (Alice) and monitor (Bob) ... :-)

Zengar
02-11-2008, 06:00 AM
So Alice and Bob are famous? I though that they are alone unhealthy obsessions of my internet & networks professor? (God was it a bad choice of courses, ts, ts)..

Lindley
02-11-2008, 07:57 AM
http://en.wikipedia.org/wiki/Alice_and_Bob

Furthermore, Alice is such a slut. "Man in the middle" indeed....

bobvodka
02-11-2008, 09:36 AM
Well, with GDC next week I'm gonna take a guess that everyone has been geared towards that of late (definate lack of GL content this year by the looks of it as well), so with that distracting things I'm not holding out much hope of GL3 before March now, maybe mid-March at best.

And I agree with pudman, The Pipeline does seem dead; which sucks somewhat given how they patted themselves on the back about it at SIGGRAPH and how it would continue etc...

Brolingstanz
02-11-2008, 09:45 AM
They probably felt there was insufficient content for a newsletter, or perhaps enough only to goad those expecting more into complaining more than usual (which is not entirely unprecedented).

Under normal circumstances, I'd say that Siggraph would be a great time for an unveiling of such import.

Back to my beans and cornbread...

Korval
02-11-2008, 11:15 AM
If they don't have anything until SIGGRAPH (where last SIGGRAPH they claimed that they were "close"), it represents a fundamental failure by the ARB to get something done. Granted, you could say the same about it being 6 months since the last real update and info, after being pretty good about giving 3 month updates.

They don't need a big event to unveil GL 3. They can certainly host talks about GL 3 at big events where important. The main thing is to get it done so that we can get drivers and so forth.

n00body
02-11-2008, 09:56 PM
I think that Khronos was busy trying to get OpenKODE out the door. With that being such an important milestone in the mobile space, I could definitely see them delaying the GL3 revision in favor of getting that out first.

So maybe now that they've got that covered, they can focus on GL3. Just my two cents on the matter. :)

Hampel
02-12-2008, 01:47 AM
I think, OpenKODE and OpenGL are driven by different teams (with no or minimal overlap). So, the work of one working group should not delay/influence the work of the other working group with such an impact/delay. If that was/is really the case, the movement of the ARB to Khronos was a big mistake for the OpenGL community!

My 2 cents...

CatDog
02-12-2008, 11:10 AM
you guys are kidding, right?
A customer sent this link today:
TechSoft3D about the "Changing Graphics Landscape" (http://www.techsoft3d.com/products/pdfs/wp_hoopsvista.pdf)

This is not funny.

CatDog

Brolingstanz
02-12-2008, 12:40 PM
you're right; that's not particularly funny. Though it doesn't exactly bring a tear to the eye either..

noncopyable
02-12-2008, 07:17 PM
I don't know if it is funny or not, but is that something from Bible or a text from Nostradamus?
I am asking because there are lots of "will" in it, like it has not already happened, and will be like that in the future, hmmm... 250 years later from now?

CatDog
02-13-2008, 05:01 AM
Speaking of the Bible. What should I respond to my customer? That I believe in OpenGL? That prophets told me of better times to come? And that these prophets are currently... err... away?

CatDog

bobvodka
02-13-2008, 06:59 AM
Works for every other religion ;)

sqrt[-1]
02-13-2008, 07:11 PM
Careful, walking on dangerous ground there...

PkK
02-16-2008, 02:51 PM
Well maybe the ARB was waiting for Toshiba's statement http://www.reuters.com/article/technologyNews/idUSL1637974620080216 for inspiration for the next GL pipeline newsletter.

Philipp
P.S. Somehow I still have a vague, irrational hope that they're working on technical stuff or sorting out S3TC patent prblems.

Jan
02-16-2008, 04:39 PM
I don't get it: What has HD-DVD to do with OpenGL / the ARB ?!

In my opinion, there is something rotten with the whole OpenGL 3.0 thing. It makes no sense to keep us in the dark, if everything would be going along well. I doubt, that drivers are already in the works and the ARB is just waiting to release everything in one big package.

I am pretty sure several big issues have come up, that make it impossible for the ARB to make clear statements, right now. That's the only reason, IMO, why they should stop all communication with the community. Maybe MS holds some key-patents ... ?

I said it several times: They were much too optimistic, to get a whole new API out in such short time. At least they didn't call it "OpenGL Forever".

Jan.

CatDog
02-16-2008, 07:19 PM
My problem is not to stay in a dark room. But those noises from the outside suddenly stopped. And nobody is knocking at the door, shouting "Err, hold on - we've got some issues here, but we're working on it!". There's just deadly quietness outside... and that's a little bit scary, when you're sitting in the dark. :)

No, seriously, I've got some decisions to make and I'm probably not the only one. Time is running, hardware evolving rapidly, and we're sitting here, making jokes, listening to that quietness. Meanwhile, OpenGL seems to be loosing its positioning as "the industry's foundation for high performance graphics" (heck, where did I get this from..?). At least, this is what I read from the paper I mentioned above.

So, I don't need a clear statement. At first, *any* statement would do. (Or did I miss something? To be honest, I'm predominantly scanning this forum for news, so if there's other information, please let me know!)

CatDog

Korval
02-16-2008, 07:59 PM
They were much too optimistic, to get a whole new API out in such short time.

It wasn't that short of a time. And a graphics API is not that complicated.

It's fairly apparent that, at SIGGRAPH, they felt certain that they were close to the end. It is therefore apparent that something changed after SIGGRAPH.

It's been 6 months since SIGGRAPH. That's a long time, particularly since they keep stressing that they are having frequent meetings.

You don't hold up a spec like GL 3.0 for something simple. Not for 6 moths. No, it had to be something substantial. And since things seemed to be coallessing pretty well on the API front, it's either one of two things.

1: Someone discovered something fundamentally wrong about their API. Either the API couldn't support extensibility in some way, or it was a major API wart that made practical coding to the API exceedingly difficult.

2: They decided to make a new glslang. They chucked the old one out and have spent the last 6 months building a new, probably lower-level, shading language.

These are the only two reasonable excuses I can see. If it's #1, then we will see a dramatically different GL 3.0 API than what we were led to believe. If it's #2, then we will see a dramatically different glslang.

If it's neither... then the ARB has been wasting time. And thus, failed. Again.


Meanwhile, OpenGL seems to be loosing its positioning as "the industry's foundation for high performance graphics" (heck, where did I get this from..?). At least, this is what I read from the paper I mentioned above.

Ultimately, OpenGL has to exist for Linux and MacOS. So it isn't a question of OpenGL going away; there will be a GL 3.0. It's more of a question of what Windows graphics developers are going to do. And what cross-platform graphics developers are going to do.

The main advantage GL has on Windows at present is that it works on XP and Vista. That advantage exists only as long XP is a viable platform. And even that is circumvented by designing one's rendering code around the differences; that only takes development time.

OpenGL will always exist on Windows platforms. Cross-platform code (Firefox 3, etc) will use it. The question is whether Windows-only programs will use it.


At first, *any* statement would do.

Well, a few weeks ago, there was a post in one of the threads that said something to the effect of, "We're still progressing, and we'll have some news for you soon."

PkK
02-17-2008, 03:18 AM
I don't get it: What has HD-DVD to do with OpenGL / the ARB ?!
Jan.

Sarcasm: The newletter might not be about OpenGL 3, but about giving up, leaving the field to Direct3D.

Lord crc
02-17-2008, 03:49 AM
These are the only two reasonable excuses I can see. If it's #1, then we will see a dramatically different GL 3.0 API than what we were led to believe. If it's #2, then we will see a dramatically different glslang.

I just cannot see how ANY technical issues warrant a complete black-out of communications though, and THAT is what worries me. Yeah they'd lose some face by saying "oops, we screwed up the standard", but they're losing a LOT more (and not just face) by not saying anything.

The complete lack of communication is far FAR worse than the actual delay, or even the reason for it.

ZbuffeR
02-17-2008, 05:00 AM
I just cannot see how ANY technical issues warrant a complete black-out of communications though, and THAT is what worries me.
Would IP or patents problems explain why it is not possible to discuss it in public, until resolved ?
Or (almost) new comers would like a total rebuild of the API for much more general uses ? I am thinking about AMD/Intel, wanting meta-shaders or something...

santyhamer
02-17-2008, 10:28 AM
I think the problems are:

1. Initially they wanted to launch Longs Peak... but then somebody realized the interfaces they were designing won't fit well in the Evans model... so I suspect they are going to launch Evans and Longs Peak at the same time. ATI was developing the R700 as a multicore GPU and they realized all the asyncronous object creation and context sharing was not good enough... so needed a complete API revision.

2. IP problems with PCF shadows, fetch4/gather, tessellation... The problem is that SGI owned the shadows comparison mechanism... then NVIDIA invented the automatic bilinear PCF to avoid the SGI's patent... then ATI invented fetch4... and now they have to relax their IPs to allow the DX10.1 equivalent gather4 on Evans. There's also an IP problem with NPatches and R600 specialized tessellation... And also with some stencil volume shadows algorithms(Creative owned some patents about that).

3. DX10.1 vs DX1.0. ATI wanna include DX10.1 funcitonality into Evans... but NVIDIA, apparently, not. ATI also wanna include double precision now... but NVIDIA apparently not. ATI wanna include patches and tessellation... and NVIDIA not. Just some examples.

4. Intel(with Larrabee, Nehalem and new IGPs), S3(with Chrome 400 Dx10.1) and AMD(Fusion) gonna start asking for extra features and to modify the existing ones to support better their products. The S3 one can be simple to achieve, but all the others can be hard due to the CPU-GPU/GPGPU syncronization, SIMD, multicores/multiGPUs, new features, etc...

5. They got an early DX11 GPGPU specification about what Microsoft wants to do in the future... and their spies also got a copy of the Larrabee propietary API specs... and NVIDIA is interested in putting the PhysX and MentalRay into their new RayForce hardware... so they realized all their OGL job could be deprecated soon with the inclusion of realtime raytracing and global illumination API.

6. Like DX10.0 and Vista market share is not very good(aprox 10%), they don't have any hurry to release the spec... in fact, the number of DX10-capable games can be counted with your fingers currently.

But I still think we're going to see news about OGL3 in the GDC 2008.

Korval
02-17-2008, 02:00 PM
Initially they wanted to launch Longs Peak... but then somebody realized the interfaces they were designing won't fit well in the Evans model...

That one makes no sense, as LP's object model wouldn't change with the additions to the Mt Evans API. Just like the DX10 features in GL 2.1 work just fine with the 2.1 API.


There's also an IP problem with NPatches and R600 specialized tessellation...

Um, why would the ARB expose specialized tessellation at all? They never felt the need to in D3D or GL 2.1. I mean, this is purely platform specific stuff; it clearly belongs in an ATi extension.


so they realized all their OGL job could be deprecated soon with the inclusion of realtime raytracing and global illumination API.

If that's the case, why wouldn't they just explain that and simply drop the new API? Why the pretense about continuing forward?

Brolingstanz
02-17-2008, 02:18 PM
6. Like DX10.0 and Vista market share is not very good(aprox 10%), they don't have any hurry to release the spec...

FYI, d3d10 doesn't have a publicly available spec :p

santyhamer
02-17-2008, 08:25 PM
That one makes no sense, as LP's object model wouldn't change with the additions to the Mt Evans API. Just like the DX10 features in GL 2.1 work just fine with the 2.1 API.

Well, although I'm sure you could implement a lot of things using extensions, perhaps they want to change some core parts to fit better predication, DrawAuto, queries/diagnostics/stats, multiGPU support, syncronization, etc... I don't know why ATI does not provide OpenGL extensions for geometry shaders or Crossfire like NVIDIA does... that's pretty indicative they are having some problem with the API or with some extension IP.



Um, why would the ARB expose specialized tessellation at all?

Well, that was not in the Evans milestone they planned... but the time passed and like they have a considerable delay and GT200/R700 are comming soon perhaps the IHVs wanna include that in the spec.

You could use it for adaptive terrain tessellation, pn triangles, displacement mapping... i'm able to imagine more.
I'm just speculating but this fragment on an internal ATI document from their new GPU Mesh ( http://ati.amd.com/developer/gpumeshmapper.html ) says

"NOTE: Tessellation will first be supported in the March 2008 Catalyst driver release."

Notice this old tessellation demo(from CeBit?)uses that ninja model ... and it's rumored that demo does not use geometry shaders:

http://www.youtube.com/watch?v=SgQj4JRgMo0

I bet one of the causes for the spec delay is that ATI wanna modify the pipeline to include in the future the improved R700 tessellation API 2.0... or because is conflicting with other IHV tessellation extension.




If that's the case, why wouldn't they just explain that and simply drop the new API? Why the pretense about continuing forward?
I would be happy if they just explain "something" :D

sylware
02-18-2008, 02:12 AM
Again, blah blah blah...
Who does know real people working on the specifications?
Do real people working on the specifications read this forum thread?
Let's get as real as possible stuff, stop speculation: it's becoming toxic.

Zengar
02-18-2008, 03:07 AM
sylware, it only shows that you don't read the forum carefully ;)

Lots people who potentially work on the spec read/write in this forum (like Rob Barris, Barthold Lichtenbalt, Pat Brown and Mark Kilgart just to name few) -- I am not 100% if they DO work on teh spec, but it is very probable.

Korval
02-18-2008, 03:31 AM
Well, that was not in the Evans milestone they planned... but the time passed and like they have a considerable delay and GT200/R700 are comming soon perhaps the IHVs wanna include that in the spec.

I'm not saying that it isn't useful. I'm saying that only ATi will be supporting it. It's purely vendor-specific; no nVidia card now or in the near future will expose it.

That's extension territory.

santyhamer
02-21-2008, 05:51 PM
ok, no real OpenGL 3 news from the GDC 8(
Well, almost we got some for COLLADA and OpenGL|ES

Dark Photon
02-21-2008, 06:12 PM
ok, no news from the GDC 8(
Wasn't there, but I find it very odd that Khronos covered virtually every software component managed by Khronos in the slides <u>except</u> OpenGL:

* Neil Trevett: Khronos Ecosystem GDC Feb2008.pdf (http://www.khronos.org/library/detail/game_developers_conference_2008/)

especially considering the info black-out on GL3.

Did anybody go to this talk? Any official word on what the heck's going on with GL3? I've heard some things through game dev channels, but I'd really like official facts to hang a hat on.

Chris Lux
02-22-2008, 12:21 AM
[quote=santyhamer]Did anybody go to this talk? Any official word on what the heck's going on with GL3? I've heard some things through game dev channels, but I'd really like official facts to hang a hat on.
ca you tell some things you heard?

Jan
02-22-2008, 06:22 AM
On page 9 they actually mention OpenGL 3.0, so one can at least assume it's not dead (yet).

elFarto
02-22-2008, 02:13 PM
mmmm EGL 1.5 + OpenMax looks nice. Shame we'll never see it on Windows :(.

Regards
elFarto

pudman
02-22-2008, 04:29 PM
Maybe all of the emphasis on OpenGL ES has jaded their approach to OpenGL3.0. OpenGL ES was based on OpenGL2.0 (let me know if I'm mistaken) and so if OpenGL jump to a completely new API (OpenGL3.0) then they can no longer bank on the "OpenGL ES is like OpenGL" statements.

And look at the level of importance of OpenGL ES. Mobile products are significantly increasing their 3D power right no and applications need a nice stable API to help take advantage of that. Advancing OpenGL ES is a very wise move.

But what is the importance of OpenGL3.0? We can already do DX10 features in 2.1. 2.1 has been "stable" for years. Hardware vendors can just keep on cranking out extensions for new stuff.

From a Level Of Effort vs. Payout standpoint where would you focus your resources?

bobvodka
02-22-2008, 07:08 PM
OpenGL ES was already removing things such as immediate mode from the API, so there are already differences.

The importance of OpenGL3.0 is to stream line the API and get us back to being a thin wrapper over the hardware with less chance of fulling off the 'fast' path. It isn't about DX10 features, heck OpenGL3.0 wont even HAVE DX10 features in it (that's for Mt. Evans which follows), it's about cleaning up the API, making the drivers saner to write and setting a good foundation for the next X years of development.

Also, what is it with people and the idea that an orgainsation/company can do one thing at a time; to hear people talk you'd think that ever member of a group was focused on one product; Khronos is made up of numberous companies, numberous 'groups' and works on numberous projects at the same time. Just because OpenGL ES is being pushed forward on the mobile space doesn't mean that OpenGL will be affected at all (aside from the normal cross talk between groups).

Korval
02-22-2008, 08:17 PM
But what is the importance of OpenGL3.0?

To clarify and expand on bobvodka's point.

Look around the Advanced forum sometimes. There are questions about multithreading. There are questions about proper VBO usage. FBO usage. Etc.

The GL 2.1 API offers no hints as to the thread safety of any operation. It provides no clues as to how heavyweight a gl*Pointer call is on certain hardware, nor does it provide any way around them. There are innumerable, platform-specific performance holds in OpenGL 2.1. Writing a performant GL 2.1 application is very difficult and requires huge amounts of testing.

Worst of all, the next driver revision can come out tomorrow and bam: your application's buffer objects now take up 2x the memory they used to.

Why? Because making GL drivers is hard. Having to support a decade of legacy features is hard. Having to support two kinds of bind semantics (bind to modify an object, bind to use it) in a single call is hard to make performant. And so on.

The purpose of GL 3.0 is to get rid of the cruft. To make it so that there is one optimal path. If you have a mesh with 4 vertex attributes of a certain type, and you want to render with it, the API will tell you if you can combine those 4 vertex attributes together as you are trying to. And if the hardware won't allow it, then the API will refuse your request.

In short, GL 3.0 will be like this. Either it works fast, or it doesn't work at all. Now, of course there will still be "pathological" use of the API; GL 3.0 won't be able to stop it. However, it won't be easy to fall into those performance holes. And there should be fewer cross-platform performance holes.


Also, what is it with people and the idea that an orgainsation/company can do one thing at a time

It's simple. People are looking for reasons why OpenGL 3.0 is as late as it is. And since the ARB, in its "wisdom" basically decided to stop providing any information, and in the absence of reasonable alternative theories, people tend towards any theory, regardless of probability. And the idea that Khronos is interfering in some way with the ARB is one of them.

Smokey
02-23-2008, 03:50 AM
*sighs*

I've been relatively patient - I've waited many many many months, without complaining too much.

Now seriously, lack of progress, lack of information, lack of support to the community, lack of uptake from professional 3rd parties... The ARB and Khronos, for me, have just gone past the line of respect - I feel very disappointed I've backed a technology lead/driven by such a foundation - but worse yet, that this is the only massively cross platform alternative for hardware accelerated 2D/3D rendering...

I'll admit, I'm not working on anything ground breaking that will push OpenGL forward in to the future - but there ARE people out there who want/need to use OpenGL 3.0 for potentially ground breaking projects - and I feel sorry for them most of all...

I fear OpenGL will lose it's place soon - especially if a competing cross platform 3D rendering API/standard emerges...

*disapointed & confused* :(

noncopyable
02-23-2008, 05:20 AM
I fear OpenGL will lose it's place soon - especially if a competing cross platform 3D rendering API/standard emerges...

Wouldn't that be great? An alternative, maybe something better than we have, add stability/low-level and you got everything you could ask as a graphic coder. GL3 was offering these, that is why it was important, no?

1 - DX only games. (famous - "nextgen")
2 - DX only cards. (soon - if not already happened)
3 - what is next?

Smokey
02-23-2008, 05:57 AM
GL3 was offering these, that is why it was important, no?


Yes, it was offering these - or 'is'...

I doubt something will emerge though, but ideally if nVidia/AMD/Intel could put their differences aside and develop an API for their cards, they would have complete control without outside interference (Microsoft, other members of the ARB, and other members of Khronos)... It could potentially bring about something revolutionary.

But as I said, I doubt something like that will emerge.

Korval
02-23-2008, 12:55 PM
if a competing cross platform 3D rendering API/standard emerges...

And where would that come from, exactly? Without nVidia and ATi behind it (and Intel should be on that list somewhere too), it'll never fly.


if nVidia/AMD/Intel could put their differences aside and develop an API for their cards, they would have complete control without outside interference (Microsoft, other members of the ARB, and other members of Khronos)... It could potentially bring about something revolutionary.

That assumes lots of things.

One, that the reason for the delay of GL 3.0 has something to do with competitive differences between nVidia, ATi, and Intel.

Two, that they could create an API and force Linux and MacOS X to implement it. Remember: MacOS X is built on OpenGL. They're not going to ransack the internals of their rendering system just because a few graphics card companies want it.

tranders
02-23-2008, 01:10 PM
OpenGL ES was already removing things such as immediate mode from the API, so there are already differences.

But don't forget that OpenGL ES was quickly followed by OpenGL SC which ADDED back immediate mode and other similar features. One reason for that was the requirement for a well defined, deterministic, or even static memory footprint for life critical embedded systems as well as the ability to review code and know what the expected behavior would be (something that is difficult to do with shaders). So really the differences are not as clean as you might think.

pudman
02-23-2008, 01:48 PM
It's simple. People are looking for reasons why OpenGL 3.0 is as late as it is.

Absolutely true! This thread had gone quiet for a few days so it required another conspiracy theory.

One could also point out that OpenGL3.0 is truly the way forward for future hardware generations and therefore would be worth it in order to avoid continually retrofitting GL2.x with more incremental versions and extensions. Then again, actually *doing* OpenGL3.0 would require IHVs to stop moving forward GL2.x development. What's the benefit of GL3.0 when you still have to continually maintain yet another driver model?

That said, if say nVidia said their next hardware would *require* a GL3.0 driver then that would be a Really Good Thing.


And the idea that Khronos is interfering in some way with the ARB is one of them.

Maybe I'm not clear and the difference between Kronos and the ARB. I thought the ARB was absorbed into Kronos and therefore *was* Kronos, not a separate entity. Therefore OpenGL is simply advanced by a Kronos Working Group. Am I wrong?

It does make it a bit scary that there was only a tiny reference to OpenGL (pg 5+9) in the GDC presentation with no mention of its progression forward. I'm not clear on whether when they refer to OpenGL|ES that they are referring to all OpenGLs or simply ES and possibly SC.

It's been very interesting observing the goings-on in the OpenGL world since I stumbled onto this website one day. I'd always been a fan of GL over DX giving its relative simplicity and portability. And when I found this site they were just starting to crank out the Pipeline. Exciting times! Things are much more dull here compared with OpenGL ES, XNA, CUDA, COLLADA, ... you name it.



The importance of OpenGL3.0 is to stream line the API and get us back to being a thin wrapper over the hardware with less chance of fulling off the 'fast' path. It isn't about DX10 features, heck OpenGL3.0 wont even HAVE DX10 features in it (that's for Mt. Evans which follows), it's about cleaning up the API, making the drivers saner to write and setting a good foundation for the next X years of development.

*I* understand what 3.0 it supposed to accomplish. But in the broader scope of developmental resources (spec and driver prototypes) it could be a more difficult sell to put all effort into something that right now "works fine". Regardless of the issues with the current spec (threading, VBOs, whatever) it still works (of course, with many caveats depending on vendor/driver/moon phase).

Maybe the world needs another statement from John Carmack saying how OpenGL3.0 is the Future of Gaming.

Brolingstanz
02-23-2008, 01:50 PM
One, that the reason for the delay of GL 3.0 has something to do with competitive differences between nVidia, ATi, and Intel.

A recent update in this thread did seem to suggest that this may in fact be the case, though no specifics were given. It did sound strikingly like some old hatchets were in the process of being buried...

Chris Lux
02-23-2008, 02:08 PM
Maybe the world needs another statement from John Carmack saying how OpenGL3.0 is the Future of Gaming.
the problem is that Carmack more than once said that D3D is an option for him and how he is happy with the xbox sdk etc.. he actually could make it impossible for OpenGL to get the foot back into the gaming scene.

i am way past being angry at the ARB/Khronos, the complete lack of any communication is the most aonnoying problem. i simply can not understand anymore what the problem can be to stall a spec which was by their counts almost out the door.

pudman
02-23-2008, 03:22 PM
the problem is that Carmack more than once said that D3D is an option for him and how he is happy with the xbox sdk etc.. he actually could make it impossible for OpenGL to get the foot back into the gaming scene.

Thus the reason why it would be so beneficial for someone like that to make such a statement. The reality is that it is not true with the advances that DX has made among other things. If GL was the API for cross platform (in this case PC/xbox/ps3/wii) development then it would have mattered.

Then, in the scientific community, GL2.x is probably completely sufficient. CUDA is filling a parallel processing need and DX10 features possibly aren't needed for CAD and medical visualization (there's always exceptions).

I'm not trying to argue against all of the benefits a GL3.0 API would bring, just attempting to bring some broader perspective onto the reasons one might throw a given amount of resources at the issue.

Smokey
02-23-2008, 04:02 PM
That assumes lots of things.

One, that the reason for the delay of GL 3.0 has something to do with competitive differences between nVidia, ATi, and Intel.

Two, that they could create an API and force Linux and MacOS X to implement it. Remember: MacOS X is built on OpenGL. They're not going to ransack the internals of their rendering system just because a few graphics card companies want it.

1) It doesn't assume the reason for the delay is competative differences, it actually assumes they can put aside technical differences if anything.

2) They wouldn't have to 'force' anyone to use it at first - I'm more than positive there would be some interested parties for implementing such an API under linux, and it's not like anyone is ever going to drop support for legacy OpenGL anytime soon - so it's not forcing Mac to do anything either.

It's just opening up the full potential of GPU programming to a wider audience, without the limitations of a working group, standards committee, or any other political bull... interfering.

If it were implemented in a similar way to OpenGL on linux (eg: with a strict ABI), it wouldn't require changes by any operating system to implement - it would simply be a library which invoked the driver/card(s) directly. And if apple truly did want to do follow it up, and do similar things to what they're doing with OpenGL, they could simply make a library following the same ABI, overriding the specific functions they need to standardize - as a wrapper around the driver's official library. (more or less what they're doing with OpenGL) & passthrough the rest of the functions directly to the driver's lib...

Anyways - just putting forward ideas and theories - while 'patiently' waiting for any news on GL3 :)

Zengar
02-23-2008, 04:05 PM
well, it is simple IMO: there is a need for a simple, open, cross-platform, flexible, extendable API that would expose functions of modern graphics hardware. Neither GL2x nor DX are able to do that: DX is MS-only and is not easily extendable; current GL is patchwork of different ideas and times; bloated with legacy functions and is a horror for a driver developer to write. So we need a new API. I don't care if it will be called GL3 or Super3D or whatever, as long as it design corressponds to that we heard about and expect of Longs Peak.

Brolingstanz
02-23-2008, 04:22 PM
Personally I think GL 2.1 is pretty darn sweet. Pretty much what you have in Dx10 already, and pretty amazing considering it's cross-platform to the extent that it is.

I'm truly stoked about GL3, but I'm not desperate for it by any stretch. As bobvodka mentioned earlier, I've plenty to do in the interim, and for me GL3 should be a plug-n-play affair when it arrives, besides.

Korval
02-23-2008, 11:42 PM
It's just opening up the full potential of GPU programming to a wider audience, without the limitations of a working group, standards committee, or any other political bull... interfering.

Yeah, that's how OpenGL 1.0 was invented. It was SGI saying, "Here's our API." Without a thought in the world as to whether the actual future of hardware would be different from their expected vision.

The problem with working alone is that you have a single vision. You have no input from the people who would actually have to implement the API, and thus no input as to whether API X would be fast or slow.

plasmonster
02-26-2008, 07:52 PM
The question is whether Windows-only programs will use it.

I think it's safe to say that Windows folks will continue to use OpenGL for the same reasons they've used it in the past: it tastes great and it's less filling.

Coders are pretty loyal creatures; you tend to stick with what you start with.

stephanh
02-26-2008, 11:46 PM
For us it's not about loyalty but lack of alternatives. We'd love to use DX10 if it was available on XP and would support (as far as the hw can handle it) SM3-class HW.

Zengar
02-27-2008, 12:33 AM
The question is whether Windows-only programs will use it.

I think it's safe to say that Windows folks will continue to use OpenGL for the same reasons they've used it in the past: it tastes great and it's less filling.

Coders are pretty loyal creatures; you tend to stick with what you start with.

I would like to put it this way: I don't care if the new API is called this or that, and I don't care if it has similarity to current GL (see my post earlier). If it is a good API with good design and flexibility, I will use it (and I think lots of others will use it too).

CrazyButcher
02-27-2008, 01:31 AM
personally I would mostly like to see GLSL be redone, more like the "program" extensions were, more like DX. The current thing with "linking" then fetching parameters from linked and so on, no "env" uniforms and all that is just ugly. the "program" extensions are much nicer to work with... I can understand why IHVs want to have the high-level code and not just some low-level stuff for optimizing, but frankly they are used to the same with DX, so what...

and I agree with the "silence" being a punch in the face of us devs, especially after before it was announced to have so much more frequent news, it really feels like a big joke. whatever the reasons are for a delay, it does not justify the kind of treatment we get.

Korval
02-27-2008, 02:15 AM
The current thing with "linking" then fetching parameters from linked and so on

I don't know everything you're talking about, but I have nothing but disgust for that whole nonsense in D3D about "semantics". The shader should know exactly and only what it needs to about the data it's getting: that it has a name, is a vector of 3 floats, and will be passed in as an attribute. That's it. That you happen to be using glVertexPointer, glColorPointer, or glAttribPointer or whatever is far more than any shader should know.


no "env" uniforms

What is an "env" uniform? If you're talking about state tracking, glslang does a far better job than the program extensions. You don't have to ask for state tracking, the shader simply uses certain pre-defined uniforms and it all just works.

Komat
02-27-2008, 03:18 AM
What is an "env" uniform? If you're talking about state tracking, glslang does a far better job than the program extensions.
It is reference to program.env state from ARB_*_program extensions. Bascially uniforms which are shared by all shaders.

bobvodka
02-27-2008, 04:18 AM
We already have those after a fashion with the built in uniforms and I believe GL3 improves on that with blocks of uniforms which cna be bound to programs and thus shared between them.

GLSL, poor compilers and no 'binary' format aside, is SO much better than HLSL that is crazy; HLSL should really have been called MLSL (Mid-Level Shading Language) as it's stuck somewhere between low level shaders and having to inform the compiler about your intent and high level syntax. GLSL's varying system is much better, a couple of die hard D3D users even agree that GLSL is better than HLSL... before going on to rag on the rest of the API ;)

Komat
02-27-2008, 06:16 AM
GLSL, poor compilers and no 'binary' format aside, is SO much better than HLSL that is crazy;

If you put usability in real word aside, then yes, GLSL has advantages.


having to inform the compiler about your intent and high level syntax.

I like when I can tell the compiler about my intentions so it does not need to make guess about them (e.g. reoptimize shader when uniform value changes).



GLSL's varying system is much better, a couple of die hard D3D users even agree that GLSL is better than HLSL... before going on to rag on the rest of the API ;)

I personaly use only the gl_* varyings so I can take advantage of the color interpolators on NV hw and to reduce chance of driver wasting interpolators (e.g. those older ATI drivers where each varying consumed one 4 coordinate interpolator even if it was only float one). The DX approach also avoids the need to create explicit linking between vertex and fragment shader.

PkK
02-27-2008, 08:48 AM
With GL3 removing legacy functionality anyway, maybe Khronos decided to make a unified GL3/GLES3. One 3D API for everything from embedded deviced to graphics workstations.

Philipp

pudman
02-27-2008, 03:09 PM
With GL3 removing legacy functionality anyway, maybe Khronos decided to make a unified GL3/GLES3. One 3D API for everything from embedded deviced to graphics workstations.

It's possible. I'm sure GL ES will use a 3.0-like API eventually if GL3.0 ultimately proves a Good Thing. Still waiting for that to happen though.

Even so, that wouldn't explain the silence. If anything I think people would respect such a decision were it to be made public.

Finally, I don't see how a GLES3.0 should truly impact the GL3.0 spec. There's no need for compatibility between the two. I believe it's just a convenience that GLES leverages the GL API. Similarly, GLES should have an easy time of stripping out what they don't (or can't) use from 3.0 to make their own v3.0, just as they did with 2.0.

PaladinOfKaos
02-27-2008, 03:44 PM
Wasn't there something about hopefully getting more news after the Khronos face-to-face meeting? Has that meeting happened yet, or are we still waiting? I don't see anything about it on the Khronos events calendar, either future or past...

bobvodka
02-28-2008, 02:13 AM
I'm reasonably sure that was around a month ago...

pudman
02-28-2008, 01:33 PM
Wasn't there something about hopefully getting more news after the Khronos face-to-face meeting? Has that meeting happened yet, or are we still waiting? I don't see anything about it on the Khronos events calendar, either future or past...

Shhh!! Kronos is a timid creature and if it becomes aware that we're watching it it will run away and hide again!

pudman
02-28-2008, 01:40 PM
BTW, the link is: Rob Barris mentions WG meeting (http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Board=12&Number=232918&Searchpage=1&Main=45784&Words=meeting&topic=0&Search=true#Post232918)

Warshade
02-28-2008, 03:32 PM
How about some optimism? They're hopefully working on a GL3 driver that routes function calls to GL2.

pudman
02-28-2008, 07:08 PM
How about some optimism? They're hopefully working on a GL3 driver that routes function calls to GL2.

Another link from our most informative poster, Mr. Rob Barris of Blizzard: GL3 wrapper for GL2 driver (http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Main=27853&Number=118702#Post118702)

Wow, even a tiny bit of information can quell the sarcasm! I feel so... fresh!

Warshade
03-01-2008, 03:19 AM
The suggestion wasn't meant to be a high performance (end-) solution, rather supplying a working driver that people can use to start toying around when GL3 arrives. Writing such a router to opengl32.dll is probably not too hard for someone with experience with both APIs?

Else this "we want specs!" topic will be replaced by a "we want drivers!" topic, once the specs are available. ;-)

microwerx
03-11-2008, 10:45 AM
Hey maybe I'm just speculating here, but I just took a look at the Khronos group slides at http://www.khronos.org/developers/library/ ... specifically the "OpenGL, COLLADA, and glFX Overview" one and the latest GDC 2008 one as well. It appears to me almost as if the group is just going to Mt. Evans. It also appears as if the main focus has been on getting OpenGL ES 2 out the door and then we'll see OpenGL 3 arrive...

What do you all think?

sylware
03-12-2008, 01:08 AM
Speculation is pointless now. It's better to wait for *real* things. In the mean time, we should work on the new GPL graphic stack for Linux and its drivers. We will have very interesting, modern and hardwired for performance interfaces.
Actually, it would quite reassuring to see the "non identified people" working on opengl3 interfaces following the stack development.

elazutkin
03-17-2008, 05:29 PM
Pardon me, but I skimmed this thread and didn't find a link to documents that reflect the current thinking on OpenGL 3. Is there any document that goes beyond "we'll remove a lot of stuff, we'll change a lot of stuff, and we'll add a lot of stuff"? I don't ask for the formal spec, but I'd like to see API mockups, planned objects, handling of the asynchronous creation. It would be nice see the road ahead, the general direction, parts that are already settled, and parts, which have several competing proposals.

I am pretty sure that there is a wise editor of this spec, who has all this information already. Can anybody share the knowledge? Or at least point me to documents I missed.

CatDog
03-17-2008, 05:37 PM
elazutkin: First of all, read the quarterly "pipeline newsletters" (http://www.opengl.org/pipeline)! :)

CatDog

tanzanite
03-18-2008, 04:35 AM
... quarterly ... :sorrow:

Brolingstanz
03-18-2008, 06:57 AM
quarterly means it's going to cost you 2 bits to see the next newsletter.. (can't get a shave and a haircut for that anymore).

What do we need with intermediate details anyway? When the spec and drivers are released we'll all be a picking and a grinning.

Lord crc
03-18-2008, 03:55 PM
Only good thing about the delay is that if Duke Nukem Forever is released this year, OpenGL 3 will be the perfect replacement candidate for all those jokes...

dor00
03-19-2008, 05:03 AM
Only good thing about the delay is that if Duke Nukem Forever is released this year, OpenGL 3 will be the perfect replacement candidate for all those jokes...

Hmm.. thats sadly..

Eddy Luten
03-27-2008, 08:05 AM
Last time I checked in here was in December 2007, anything happen with the spec since then?

Seth Hoffert
03-27-2008, 08:10 AM
You haven't missed anything. :)

Eddy Luten
03-27-2008, 08:24 AM
Thanks, HexCat. I kind of figured that since the newsletter is still "Spring 2007". Too bad though, I would love to hear something official.

Anyway, better a well thought through API than something simply slapped together. Like an API with *cough* very long datatype (API NAME_INPUT_ELEMENT_DESC) descriptors and half asses backwards compatibility.

bobvodka
03-27-2008, 09:59 AM
While true it's been six months since 'almost ready' and no word, and as much as you might dislike D3D you can't argue with results; DX9 is used all over the place by major developers on the PC. Sure, it might change but apprently the docs, examples and such are enough to keep people with it.

Stability is nice, but change too slow and people move on.

Eddy Luten
03-28-2008, 12:54 PM
I definitely agree. Yet the way the API is constructed is horrible in my opinion. And I think that OpenGL would be in real trouble if MS would do a total naming convention conversion for the next D3D release.

But looking at the WINAPI, this will never happen.

PkK
03-28-2008, 05:18 PM
Only good thing about the delay is that if Duke Nukem Forever is released this year, OpenGL 3 will be the perfect replacement candidate for all those jokes...

Hmm.. thats sadly..

Maybe not that sad.

OpenGL 3 will live in the jokes.

Maybe it's better than just being forgotten or living as a ghost in the subconscious of the minds of graphics programmers, which will use Direct3D for the foreseeable future.

Philipp

Eddy Luten
03-28-2008, 11:07 PM
Maybe it's better than just being forgotten or living as a ghost in the subconscious of the minds of graphics programmers, which will use Direct3D for the foreseeable future.Do you honestly believe that? There are two platforms supporting Direct3D, namely: Windows and Xbox. Unless all graphics programmers switch over to a Microsoft platform this will never happen. It would mean a total abandonment of SGI workstations, Linux, Unixes, Mac and a butt load more which are all heavily used in combination with OpenGL.

Plus, you can access most (if not every) piece of functionality Direct3D provides through extensions AFAIK. Unless you want to take advantage of WDDM -- which is Vista only and not useful for OpenGL -- I see no reason to switch to D3D as long as I can access D3D10-like features through OpenGL under Windows XP.

In all honesty, I pretty much understand why its taking a while. The spec is developed mostly by independent companies who first have to agree on a bunch of stuff. I think it was John Carmack who said a year or so ago that he was less active on the ARB because he had so much stuff to do -- which should be understandable for most parties involved in the spec. Also, if you look at the release dates of the previous APIs, you notice that there's about 2 years in between major changes in versions. When it was announced that 3.0 was going to be released in September 2007, I think the Khronos Group kind of jumped the shark after the release of 2.1 in 2006; maybe for community attention, who knows?

But then again, why promise when you can't deliver and say "oops, we f-ed up!" a month after 3.0 was supposed to be finalized? It would just be nice to hear something at this point, but no reason to switch to D3D unless IHVs stop developing extensions for OpenGL, or a decision is made to stop developing OpenGL in its entirety.

Sorry about the length of the post, it just happened!

CrazyButcher
03-29-2008, 01:18 AM
"unless IHVs stop developing extensions for OpenGL"

this is already happening outside the Nvidia world.

PkK
03-29-2008, 10:27 AM
Maybe it's better than just being forgotten or living as a ghost in the subconscious of the minds of graphics programmers, which will use Direct3D for the foreseeable future.Do you honestly believe that? There are two platforms supporting Direct3D, namely: Windows and Xbox. Unless all graphics programmers switch over to a Microsoft platform this will never happen. It would mean a total abandonment of SGI workstations, Linux, Unixes, Mac and a butt load more which are all heavily used in combination with OpenGL.


Hmm, it's probably unlikely that Unices will start to support Direct3D, but not impossible. There's stuff like winelib (it has a Direct3D implementation, though it's a wrapper on top of GL for now) and C# compilers on Unices. The Linux people might develop their own 3D API as well.
Free Linux drivers are moving towards the new Gallium3D architecture, an API-neutral driver model is one of the key features of Gallium3D.



Plus, you can access most (if not every) piece of functionality Direct3D provides through extensions AFAIK. Unless you want to take advantage of WDDM -- which is Vista only and not useful for OpenGL -- I see no reason to switch to D3D as long as I can access D3D10-like features through OpenGL under Windows XP.


When OpenGL doesn't evolve except for extensions Direct3D will be exposing hardware features in a much more natural way than OpenGL and be easier to learn and use.



In all honesty, I pretty much understand why its taking a while.
Whenever news about GL3 came it was claimed that the spec was nearly complete and they were working on it. Last time we heard anything about GL3 was in october 2007, half a year go.

Unless Khronos or at least someone influential among them wants GL to die this doesn't make sense.

Maybe they decided to make a completly new API that doesn't resemble GL. That would explain the silence: They wouldn't want to tell that GL is dead before the replacement is ready.

Whatever the ARB's reasons are, no matter if they still want to get GL 3 done, replace it by GL ES or something completly new, their time is running out.

Philipp

Eddy Luten
03-29-2008, 06:37 PM
Your cynicism irks me but there's a truth to it. I guess the coin also has two sides in this case. Yet I highly doubt anyone would implement Direct3D if they wouldn't have to, even if it were possible and they were allowed to.


The Linux people might develop their own 3D API as well.Why step away from standardization? If this would happen it would work against everything that has been developed since 1992.

PkK
03-30-2008, 02:44 AM
Your cynicism irks me but there's a truth to it. I guess the coin also has two sides in this case. Yet I highly doubt anyone would implement Direct3D if they wouldn't have to, even if it were possible and they were allowed to.

The wine people are doing it for compability reasons anyway.
http://winehq.org/site/status_directx
Says D3D8 and D3D9 are 95% complete. While it is a wrapper on top of OpenGL I wouldn't be surprised if they decided to change that for performance reasons.


The Linux people might develop their own 3D API as well.Why step away from standardization? If this would happen it would work against everything that has been developed since 1992. [/QUOTE]

When Qt was non-free and there was no free alternative, GTK+ and Gnome were developed. OK, the situation probably isn't that bad with GL and it makes much more sense to use just use GL ES, which seems to be still alive (though the standard seems to be more confusing than GL in some places and the standardization process seems even less transparent).

Philipp

dor00
03-30-2008, 03:04 AM
Can anyone BAN those D3D and Microsoft fun boys from OpenGL forums? Pleasse?

speedy
03-30-2008, 12:04 PM
"unless IHVs stop developing extensions for OpenGL"

this is already happening outside the Nvidia world.

Note that ATI has all the recent extensions implemented on Mac OS X. ;) Hopefully they'll port them to Windows and Linux.. I thought they had unified their driver architecture in the latest rewamp and that features propagate automatically.

By a quick glance, Intel seems to have all the extensions which their hardware can support.

NeARAZ
03-31-2008, 12:11 AM
Note that ATI has all the recent extensions implemented on Mac OS X. ;) Hopefully they'll port them to Windows and Linux.. I thought they had unified their driver architecture in the latest rewamp and that features propagate automatically.
It's more like "Apple has some DX10-like extensions implemented on ATI cards as well". The major part of OS X drivers are written by Apple; and the hardware-specific driver part there is completely different than that on Windows or Linux.


By a quick glance, Intel seems to have all the extensions which their hardware can support.
FBO? GLSL?

PkK
03-31-2008, 03:09 PM
By a quick glance, Intel seems to have all the extensions which their hardware can support.
FBO? GLSL?

Supported in the free (Linux / BSD) drivers. I don't know about Windows.

Philipp

Lindley
04-01-2008, 05:19 AM
Microsoft is now saying DX11 will be out by the end of the year. Great work, OpenGL team, you're now competing against a version later than you were supposed to be.

Chris Lux
04-01-2008, 06:50 AM
don't forget GL3 is more like D3D9 than D3D10, first Mnt. Evans was/is supposed to be the D3D10 counterpart.

tanzanite
04-01-2008, 09:40 AM
Microsoft is now saying DX11 will be out by the end of the year. /.../ 01 April, 2008

ebray99
04-01-2008, 09:41 AM
Well, it's kinda hard to put blame where it's due. I doubt it's the whole team, but probably some IHV saying, "well, if it doesn't have blah, then *insert complaints here*". That said, if I had to guess, the people who are actually working on the spec probably aren't to blame. I'm sure that they're aware of the fact that DX11 will be out by the end of the year, and I presume they probably see the colossal failure that this is becoming. I would also bet that they've stated their complaints to their managers and that politics and such are getting in the way.

Given the quality of the people that are on the OpenGL team, I would guess that it's not the API designers themselves, but probably some political rivalry between a company or two. That's largely been the case in the past, so it seems likely that this is the problem here.

This whole thing really is a shame... OpenGL could have become the dominant API, but with a failure like this, I doubt many people will really want to give it a chance now. Khronos had some leeway when they first came in. They even built a little credibility with the first four news letters. Now, they've completely lost that and are simply being compared with the ARB. There is a lot of strategic value in an API controlled by hardware vendors, but perhaps some IHVs don't feel that way.

Maybe some people could send e-mails to various IHVs to see what the problem is? Does anyone know Hector Ruiz's or Jen-Hsun Huang's e-mail address?

Kevin B

Lindley
04-01-2008, 10:02 AM
Microsoft is now saying DX11 will be out by the end of the year. /.../ 01 April, 2008

There is that. But it sounded reasonable when they started talking about including a ray tracing mode. :p

CatDog
04-01-2008, 10:19 AM
You don't believe that? It will run on x86 architecture and Intel's ray-tracing engine.

Click (http://www.techarp.com/showarticle.aspx?artno=526)

CatDog

Eddy Luten
04-01-2008, 10:29 AM
Times are tough for us. :(
That's funny. Great article.

Seth Hoffert
04-01-2008, 10:31 AM
Sure it will. ;)

Lindley
04-01-2008, 10:36 AM
You don't believe that? It will run on x86 architecture and Intel's ray-tracing engine.

Click (http://www.techarp.com/showarticle.aspx?artno=526)

CatDog

No, the ray tracing mention was what made me figure it wasn't an April Fools thing.

Eddy Luten
04-01-2008, 11:27 AM
On another note: I hope this (http://www.tomshardware.com/2008/04/01/nvidia_geforce_9800gtx_review/) is an April fools joke. I was hoping for a bit more performance from the "new" 9x series.

sylware
04-02-2008, 03:50 AM
On another note: I hope this (http://www.tomshardware.com/2008/04/01/nvidia_geforce_9800gtx_review/) is an April fools joke. I was hoping for a bit more performance from the "new" 9x series.
Presuming it's not:
- on one side we have AMD with *full total open* specifications and *several* GPL drivers in progress.
- on the other side NVIDIA with *full total closed* specifications (but have not that buggy closed source drivers... hey! that's half the work) with reverse engineering in progress.

Presuming it is... well better nvidia 9800GTX be *really* damn faster than it's AMD counter part to keep reverse engineering a motivating task.

Lindley
04-02-2008, 08:09 AM
Hmm, it occurs to me that if MS really is planning to add raytracing capability to D3D, a desire to do the same in OGL3 could be responsible for the delay.

ZbuffeR
04-02-2008, 08:19 AM
I think it is probably the other way round : Intel may be pushing for raytracing, on both GL and D3D

And that techarp article was crap anyway.

Zengar
04-02-2008, 10:33 AM
Not crap, a joke :)

tanzanite
04-03-2008, 01:59 AM
crappy joke or jokey crap perhaps?

zBogdan
04-09-2008, 11:38 PM
Are there any news on the topic of releasing OpenGl 3.0 ?

I understood from the community that there is a major blocker bug in OpenGL 3.0, bug which delays the release. However the public has not been updated on the progress made for almost a year. Correct me if I got the timing wrong.

Several people are reporting this issue: see liquidat at http://liquidat.wordpress.com/2008/03/01...here-is-opengl/ (http://liquidat.wordpress.com/2008/03/01/graphics-and-free-software-a-great-2007-but-where-is-opengl/)

Please let the community know about the problem and maybe we can find a way out of it together.
Or at least we don't lose hope in that we know that someone is working and making progress on the issue/s. Slow progress is much better than no progress.

I see it as this: "lack of news is worse than bad news".

Zengar
04-09-2008, 11:58 PM
zBogdan, read through this thread, you will find all revelant and known information here... To summarize: the status of GL3 is currently unknown.

sylware
04-10-2008, 01:44 AM
Are there any news on the topic of releasing OpenGl 3.0 ?

I understood from the community that there is a major blocker bug in OpenGL 3.0, bug which delays the release. However the public has not been updated on the progress made for almost a year. Correct me if I got the timing wrong.

Several people are reporting this issue: see liquidat at http://liquidat.wordpress.com/2008/03/01...here-is-opengl/ (http://liquidat.wordpress.com/2008/03/01/graphics-and-free-software-a-great-2007-but-where-is-opengl/)

Please let the community know about the problem and maybe we can find a way out of it together.
Or at least we don't lose hope in that we know that someone is working and making progress on the issue/s. Slow progress is much better than no progress.

I see it as this: "lack of news is worse than bad news".


Ok, I know nothing, but here are my speculations:
The OpenGL designers are looking at the new GPL graphic stack because in order to have modern APIs, you must undersdand how modern GPUs do their work. There is still a lot to do on this GPL graphic stack and the full understanding of all major GPUs. Moreover they will have to feel where the GPUs are finally going... and for that, better have a strong connection with main GPU architects.
They are also getting the technical opinion of main 3D engines developers (id,unreal...) and CAO developers (catia,microstation...).
And the tough part: there are 3 main contexts where the new APIs will have to run:general purpose, high performance context (fully asynchronous,). The synchronous, formally proven context where the state space has a reasonable size. And the scarse resources embedded world.
After digesting all that: write some code. Carmark is right on this: If you want to be serious about APIs design, write some code to back them up.

There is another solution: make a very modular open source framework with everything in it (understand all hardware acceleration knownledge and code). Then if a piece of software wants hardware 3D, it will have to build on top of this modular framework. Actually mesa/gallium3D/kernel DRM and so on are basically becoming this framework. Casually surfing on the net on this subject I saw that some 3D engines devs are really following the new stack developement.
Well in this case, no more APIs, but a very modular framework with the grand 3D knowledge.

bobvodka
04-10-2008, 05:19 AM
You do realise the people designing GL3.0 already know how GPUs work and the direction they are heading because they work for the companies who make said GPUs?

The ARB isn't just some random collection of people; they work for the companies who make the chips, they know what happens and how the hardware works.

As for the rest of your post.. I've no idea what you are going on about; GPL graphics stack? (which I will never touch as I see the GPL as nothing more than a virial freedom stealing licence), Carmack? where did he get into this?

V-man
04-10-2008, 06:45 PM
There is another solution: make a very modular open source framework with everything in it (understand all hardware acceleration knownledge and code). Then if a piece of software wants hardware 3D, it will have to build on top of this modular framework. Actually mesa/gallium3D/kernel DRM and so on are basically becoming this framework. Casually surfing on the net on this subject I saw that some 3D engines devs are really following the new stack developement.
Well in this case, no more APIs, but a very modular framework with the grand 3D knowledge.

What's the difference between a API and a framework?

sylware
04-11-2008, 01:36 AM
There is another solution: make a very modular open source framework with everything in it (understand all hardware acceleration knownledge and code). Then if a piece of software wants hardware 3D, it will have to build on top of this modular framework. Actually mesa/gallium3D/kernel DRM and so on are basically becoming this framework. Casually surfing on the net on this subject I saw that some 3D engines devs are really following the new stack developement.
Well in this case, no more APIs, but a very modular framework with the grand 3D knowledge.

What's the difference between a API and a framework?

Well... what I meant, is that with an API you can have several implementations (closed source, open source etc...). With a "framework" you have only one modular code base with all the knowledge and everybody works on it.

zBogdan
04-11-2008, 10:37 AM
So on the topic of "OpenGL 3 Updates" the reasons for delaying its release is just anybody's guess. Sad news for me.

Sounds like, the best thing I can do right now for OpenGL 3.0 is to pray for it. (No offence meant to atheists!)

Thanks for the update,
Bogdan

Eddy Luten
04-11-2008, 01:22 PM
As for the rest of your post.. I've no idea what you are going on about; GPL graphics stack? (which I will never touch as I see the GPL as nothing more than a virial freedom stealing licence), Carmack? where did he get into this? Don't worry, OpenGL cannot become GPL licensed since GPL applies to source code and OpenGL doesn't have any since it's a specification, not a product.

Anyway, even if the spec for OpenGL 3.0 was released today, the implementation would take another six months, so that's the minimal time-frame we're looking at IMO.

// offtopic:
I agree with your viewpoint on the GPL though; it's a virus.

bobvodka
04-11-2008, 01:58 PM
Well, I was more wonder what on earth he meant by a GPL graphics stack, no worried about OpenGL becoming Open Source as you say. I got the impression he seemed to feel it was some sort of 'alternative' to OpenGL3.0 or something... *shrugs*

Brolingstanz
04-12-2008, 02:19 AM
Maybe he's drawing an analogy between GPL and a stack of 3D pancakes.. <wonders off muttering to himself>

bobvodka
04-12-2008, 06:50 AM
hmmm... pancakes....

tanzanite
04-12-2008, 11:48 AM
So, what is the latest on OpenGL 3 front ...

... pancakes ... ? ...

... hmmm ... pancakes! yummy!

spooky_paul
04-13-2008, 05:12 PM
i wish there were some news... even bad news... allot of BIG names in the ARB.... how come the board is so unresponsable towards the developers working with opengl? there are allot of people in this community just waiting for a scrap of information...

i just hope this is not a remake of the "duke nukem forever" syndrome...

Hampel
04-14-2008, 01:06 AM
oh come on, this nukem stuff is so old...

I thought OpenGL 3 stands for some new innovative ... ah ... jokes. So come up with some new ones...

sylware
04-14-2008, 01:58 AM
As for the rest of your post.. I've no idea what you are going on about; GPL graphics stack? (which I will never touch as I see the GPL as nothing more than a virial freedom stealing licence), Carmack? where did he get into this? Don't worry, OpenGL cannot become GPL licensed since GPL applies to source code and OpenGL doesn't have any since it's a specification, not a product.

Anyway, even if the spec for OpenGL 3.0 was released today, the implementation would take another six months, so that's the minimal time-frame we're looking at IMO.

// offtopic:
I agree with your viewpoint on the GPL though; it's a virus.

The GPL removes one piece of freedom: the freedom to remove its freedom... And a freedom which does not defend itself... well, then the code ends in MacOsX, windows or other proprietary *nixes and you know the rest of the (hi-)story.
It's a matter of personnal choice: you are ok with such things, you can use BSD like licenses, you are not... well you use the GPL or the less viral LGPL (which is proprietary friendly like the linux GPL for user space). Dual licenses do not work since the BSD like licenses cancel the GPL. And the GPL/proprietary model forces the contributors to surrender all their rights to the main author in order to let him provide binaries with a proprietary like license.
Everybody is free to choose.
I stop there, because, it's quite off topic indeed.

spooky_paul
04-14-2008, 10:40 AM
oh come on, this nukem stuff is so old...

I thought OpenGL 3 stands for some new innovative ... ah ... jokes. So come up with some new ones...

i wasn't jocking.. i really fear this.

Brolingstanz
04-14-2008, 09:33 PM
We'd be far more likely to get an update if we'd all show a little more faith and enthusiasm for the ARB/Khronos, and a little sympathy for what they're apparently up against. It's no great leap of the imagination to see the tussle that must be transpiring between well meaning corporate interests, some of which in direct competition with one another. This can't be easy sailing. I may be a simple Irish potato farmer, but even I can see this.

Everyone loves a good joke. But perhaps, for the sake of this thread and the public at large, we should exercise a little restraint.

HenriH
04-15-2008, 01:28 AM
We'd be far more likely to get an update if we'd all show a little more faith and enthusiasm for the ARB/Khronos


Haha. Sounds like a religious comment :)

bobvodka
04-15-2008, 01:53 AM
We'd be far more likely to get an update if we'd all show a little more faith and enthusiasm for the ARB/Khronos, and a little sympathy for what they're apparently up against.

The thing is, we've done 'faith and enthusiasm', both in this thread and in the one in the advanced forum, however there is only so long you can keep it up when confronted with a wall of silence; we are coming up on 6 months since this thread was started with no concrete news at all and given that at SIGGRAPH they were pretty close to having the spec done it starts to make you wonder wtf is going on. More so when taken in the context of '4 Pipeline update, more to come' or words to that effect at SIGGRAPH praising the new ARB and it's communcating glory; after that this just seems like a slap in the face.

This whole thing now has become like winning the lottery for me; I'll enter but when I check the numbers I don't expect to win. In much the same way I'll load the OpenGL website 2 or 3 times a day but don't expect to see any GL3.0 related news any more.

Brolingstanz
04-15-2008, 02:47 AM
We'd be far more likely to get an update if we'd all show a little more faith and enthusiasm for the ARB/Khronos


Haha. Sounds like a religious comment :)


Not at all. Substitute "confidence" if you like. Though I'd hasten to add that confidence, in the absence of all facts, is really just faith in ignorance ;-).

Brolingstanz
04-15-2008, 03:13 AM
We'd be far more likely to get an update if we'd all show a little more faith and enthusiasm for the ARB/Khronos, and a little sympathy for what they're apparently up against.

The thing is, we've done 'faith and enthusiasm', both in this thread and in the one in the advanced forum, however there is only so long you can keep it up when confronted with a wall of silence; we are coming up on 6 months since this thread was started with no concrete news at all and given that at SIGGRAPH they were pretty close to having the spec done it starts to make you wonder wtf is going on. More so when taken in the context of '4 Pipeline update, more to come' or words to that effect at SIGGRAPH praising the new ARB and it's communcating glory; after that this just seems like a slap in the face.

This whole thing now has become like winning the lottery for me; I'll enter but when I check the numbers I don't expect to win. In much the same way I'll load the OpenGL website 2 or 3 times a day but don't expect to see any GL3.0 related news any more.

The point I'm making is that as long as folks continue to express disenchantment with progress, the less warm and inviting the atmosphere becomes for would be ARB contributors.

And to whom it may concern, the idea that creating a calamatous cloud of disatisfaction is going to convince the powers that be to make a statement falls somewhere short of reality, I suspect.

Zengar
04-15-2008, 06:12 AM
Sorry, but I don't care about ARB contributors. If they can't get the job done, then someone else should do it. Once again, I don't care if a new API is released under the brand of "OpenGL". I just want a cross-platform, beautiful, easy to use, easy to extend, shader-based fast 3D API without the redundant features. If MS or Apple releases some sort of "OpenD3D", I will gladly use it.

Hampel
04-15-2008, 06:35 AM
@Zengar: du sprichst mir aus der Seele... :-)

Jan
04-15-2008, 08:44 AM
jep

sylware
04-16-2008, 01:15 AM
@Zengar: du sprichst mir aus der Seele... :-)
http://babelfish.altavista.com/
;)

recipe for disaster
04-17-2008, 12:30 PM
test - you guys really need a test post forum.

Jan
04-17-2008, 02:47 PM
Posting into this thread was actually a good decision. It's become a big dump for any kind of stuff...

HdcDst
04-22-2008, 06:32 AM
First: Hello to Everybody in this Forum
Second: I have read what's going on in this thread for a while and made up my own thoughts about that subject.
I mean do we realy need a rendering or general 3D/graphics API which is directly supported by GPU-Vendors.
In the last three months I have been concerned with Stream-Computing including GPGPU-Computing.
I got the impression that the only reason why it is not possible to realize a graphicsprogram completely in Cuda for example on Nvidia Cards which support it, and you still have to use OpenGl or Direct3D is because of the fact, that the ROP isn't exported as a special kind of build in kernel.
I mean wouldn't it be better if there where first some kind of Low-Level-Spec's for a Streaming-API through which it is also possible to export Modules like a ROP as a build in kernel, and graphics-API's are implemented on the basis of it.
But maybe this would only transport the problem a level deeper, because the vendors had to support the Streaming-API Spec's by writing implementations of it for their GPU's.

Just some thought's.
If you think they are completely nonsense just tell it.

Zengar
04-22-2008, 08:48 AM
@HdcDst: this is indeed what I believe will happen in some future. We will go away from a graphics API to a standard programmable stream processing API: sort of a vendor-independent stream vm (like CUDA is).

HdcDst
04-22-2008, 09:56 AM
And that's where we come to my second thought.
Maybe the reason for we don't hear something about OpenGL 3 anymore is that the members of the ARB/Khronos realized that it would be better to work on the Spec's for such a Streaming-VM, and at least neglegt the work on OpenGL 3 in favor of it.

Zengar
04-22-2008, 01:05 PM
This is pointless speculation. Besides, it is too early for such an API IMHO. Maybe some years from now.

Leadwerks
04-22-2008, 10:17 PM
It's obvious this is held up by legal problems rather than technical. Everyone's lawyers have advised them not to say anything, so they are keeping silent. If it was a technical problem, they would say "Oh, hey, we ran into a problem with X feature".

sylware
04-23-2008, 12:56 AM
It's obvious this is held up by legal problems rather than technical. Everyone's lawyers have advised them not to say anything, so they are keeping silent. If it was a technical problem, they would say "Oh, hey, we ran into a problem with X feature".
Antoher one? Unreal Tournament 3 linux client is help up by legal problems too!
Is that all about luck? Or does opengl3 specifications and the UT3 linux client availability bother somebody in particular that much? After ISO Fasttrack, we have now opengl3 and UT3 linux client slowtrack.

-NiCo-
04-23-2008, 01:56 AM
Funny you should mention that. I was reading this article (http://www.phoronix.com/scan.php?page=news_item&px=NjQ0MA) about the delay of the UT3 linux client yesterday. Guess what? They're speculating that the delay is caused because Microsoft may acquire Epic Games :p

Jan
04-24-2008, 04:55 AM
Even if OpenGL was implemented not by GPU vendors directly, but on top of something like CUDA in the future, that does not mean one should stop working on OpenGL 3. It is really only a spec, so who it implements and how is really of no concern here. In the next few years it will definitely be implemented by the vendors (at least the windows-version). In the future it might indeed happen, that it will be implemented by someone else on top of CUDA or CTM, but for the USERS of OpenGL that are unimportant details.

If Vista wasn't such a crappy OS (IMO), i would have long switched to D3D10. I can't repeat often enough how disappointed i am with the whole OpenGL 3 thing.

Jan.

PkK
04-25-2008, 07:14 AM
In the next few years it will definitely be implemented by the vendors (at least the windows-version).

Nice to see some optimism about the OpenGL 3 spec release date for a change.

By the way on Linux the situation isn't that much different: There are ATI's and Nvidia's nonfree drivers, and Intel usually pays developers to create free drivers (so they're ready earlier), which are then improved by all of the community. So for all OSes vendors will be involved in creating GL3 drivers (if there will be a GL3).

Philipp

Brolingstanz
04-25-2008, 07:20 AM
I feel sure we'll see something general like CUDA for GPU progamming across the board, if for no other reason than it'd be really cool (for my money there's no better reason than that). That is ultimately it'd be nice to program in a simple linear model, with absolutely no regard to the undelying architecture(s), be it threading 1000 core CPUs and GPUs or whatever tech lerks over the horizon...

I suppose compilers and runtime environments need to get a heck of a lot more sophisticated before any of that happens.

bobvodka
04-25-2008, 01:13 PM
Not just the compilers and runtime enviroments, languages as well. Nothing we've got really maps multi-threading all that well (functional languages do a good job in general with Erlang being designed for it) but everything else pretty much sucks as they have very little native awareness of threads (C++ for example doesn't have a clue about them, C# probably has some but I don't know about any inbuilt transactional stuffs for memory, same Java, it's very much old skool).

So, while it'll be cool, we need better tools still...

Brolingstanz
04-25-2008, 02:46 PM
Wild guess but C# probably comes out on top in the long run, since there's plenty of room for expansion and, perhaps more importantly, it's on a very fast evolutionary track.

Jan
04-26-2008, 03:38 AM
I have to agree with bobvodka. It's really a big issue, that our core tools (the languages) are mostly unaware of multi-threaded development. But at least with C++ one can't blame anyone, the language is 30 years old and i got my first multi-core processor a week ago.

Jan.

ZbuffeR
04-26-2008, 05:05 AM
On the Java front too, improved approches for modern (many cores etc) concurency are being studied.
Some recent material on the subject here :
http://qcon.infoq.com/london-2008/tracks/show_track.jsp?trackOID=94
Plus it is actually an open platform, contrary to C#.


One may argue that the triangle rasterization used in graphic accelerators is one of the few concurrency paradigm that have been able to scale to a huge number of parallel computations while still being simple to program.

Brolingstanz
04-26-2008, 05:20 AM
I'm not up on the latest research in this area, but it seems to me an ultra-sophisticated execution environment could do realtime analysis of a process and create and distribute threads automatically across any number of processors, leaving the programmer to be the lazy oaf that he or she may be. That's my hope (borne out of a quasi stupor), but if it ever happens it'll probably be long after I'm dust in the wind.

C#/Java seem like obvious choices for the initial leg of that journey, not so much the languages themselves but the flexible VMs and JIT compilation capabilties that make them tick.

CatDog
04-27-2008, 04:31 AM
If you want an update on parallel processing, I'd recommend this video: Click! (http://channel9.msdn.com/Showpost.aspx?postid=384229)

It's worth it!

CatDog

Seth Hoffert
04-27-2008, 08:06 AM
What about OpenMP / MPI? :D

Brolingstanz
04-27-2008, 08:52 AM
The closest thing I've seen to a fully unified GPU/CPU framework was presented at Siggraph 2007 by RapidMind, but I wasn't there and I haven't followed up on it. It sounds like it's similar in spirit to frameworks like Sh and OpenMP, only it's able to do it all transparently. Pretty darn nifty if it lives up to its claims...

ZbuffeR
04-27-2008, 02:49 PM
The *MP* stuff is great for CPU intensive loops where each iteration is independant from the others. Everything else is quite a nightmare to program with both efficiency and correctness.
The way Erlang does message passing is much more elegant for example, but it is quite a paradigm shift.

Chris Lux
04-28-2008, 01:37 AM
The closest thing I've seen to a fully unified GPU/CPU framework was presented at Siggraph 2007 by RapidMind, but I wasn't there and I haven't followed up on it. It sounds like it's similar in spirit to frameworks like Sh and OpenMP, only it's able to do it all transparently. Pretty darn nifty if it lives up to its claims...
RapidMind _is_ Sh (gone commercial).

Leadwerks
05-01-2008, 05:57 PM
I can say with near certainty our company will be switching over to DirectX sometime in the next year due to the apparent cessation of OpenGL's progression. I like OpenGL, but it doesn't look right now like it has much of a future, and XBox 360 development looks like something that would be good to expand into.

Roderic (Ingenu)
05-02-2008, 12:04 AM
Before doing such a move I would advise you to ask your contacts at ATi and nVidia what's going on. You might just get the answer you seek.

Mark Shaxted
05-02-2008, 05:54 AM
Before doing such a move I would advise you to ask your contacts at ATi and nVidia what's going on. You might just get the answer you seek.


Meaning you've sought an answer and got one? Do tell.

Zengar
05-02-2008, 09:54 AM
They won't tell :)