The Siggraph class “OpenGL: What’s Coming Down the Graphics Pipeline” on Wednesday should be interesting. Anyone going?
All this talk about Larrabee, Cuda/CTM and being able to write/extend APIs as you like is such a non-sense!
The fact is Larrabee will be out sometime 2009/2010. Another fact is that writing your own software-rasterizer is a lot of work. And even if others write that rasterizer, they will charge you.
All that does not solve the problem, that RIGHT NOW YOU HAVE NOTHING !
Debating about what you MIGHT be doing 2 years from now, doesn’t solve the problem, that RIGHT NOW the “alternative” OpenGL 3 sucks. So either you live with that, or you switch to D3D, but there are no other options.
If i am going to wait for Larrabee, i could also just wait for GL4 (which will be GL3 + some extensions promoted to core).
Jan.
Jan, the good thing about it is that Larrabee is basically an extension card stuffed with x86’s so you can already start programming a core without having to wait for an API. I have high expectations for this hardware but I am not holding my breath as I did with GL3.
…I was really looking forward to an object-based API…
I look forward for open sourced software-rasterizer for Larrabee.
<off topic> Talking about clean up, the OpenGL site should also be cleaned up, It has always been a mess IMO </off topic>
Oh well, the Finns have never exactly been renowned for their sense of humour.
On the topic of “SM4 proper”, do you have some sense of what you think is missing ?
You really have to wonder what went on behind closed doors, while they were discussing the matter at hand.
There really isn’t any other choice but openGL for people using non-window machines.
The mac, linux, and PS3(?)/Wii(?) people are still left using the same old API that they have been using before, and they still have to jump through hoops to get all functions working on all hardware.
Or in other words, this whole ‘annoucement’ was nothing more than a big sign that read : " Nothing to see, continue on with what you did in the past. Hope it works, see ya next year!"
It truely is a shame that they couldn’t be upfront with the community with what was going to happen, or should I say what wasn’t going to happen. 
Has everybody seen this yet?
http://www.opengl.org/registry/specs/EXT/direct_state_access.txt
It looks like this is (partly) that object model we tried to get. But I really have to hold back my tears when reading a new function name like this:
NamedRenderbufferStorageMultisampleCoverageEXT(…)
Why did they pull this off? Why do it that way? Why trying to further extend a monstrosity (where you have to think of all sorts of side effects you might introduce to the already existing extension environment) instead of just creating some new, clean, elegant and modern API?
NOBODY would have complained if there was just a new opengl3x.dll that lives happily besides the legacy opengl2x.dll. And while 2.x would be still maintained but not further extended, everyone had the time to adopt GL3.
FBO is 3 years old and still not working 100% on neither nVidia nor ATI cards. How long will it take, until EXT_direct_state_access is working? This whole stunt lacks any comparison.
do you have some sense of what you think is missing ?
Are you serious? What is missing compared to SM4? You need to ask someone what that is, when you can just list the features side by side and cross off the ones that both don’t have?
With people like this on the ARB, it’s no wonder GL “3.0” turned out this way.
In particular I had geometry shaders in mind when I wrote that, Rob.
In reading the direct state access extension, it seems to me that the majority of calls simply act as if there was a private binding point that does not affect drawing state - they look up the object and they set the state, without affecting drawing state or binding points.
As with any paper spec, seeing an implementation running can provide a good existence proof of its efficacy. If one were to become available soon, that would be an important signal that it’s doable and low risk.
(that phrasing “The EXT_direct_state_access driver is +2.5% larger.” could lead one to believe that it already exists in some form).
funniest thing i’ve seen all day.
every function that relies on a client selector gets a new entry point.
and to think, they didn’t want to change the api.
Hello Slashdot!
waves hand
The approach in the DSA extension doesn’t invalidate any existing code.
The approach in Longs Peak invalidated all of it.
I first have a look on GLSL 1.3 and I thought first: “So great, there is the SM4 feature too!” then I arrived on the texture function and I thought “What the heck is going on!”.
There is no word to tell you how much I’m disappointed by this OpenGL 2.2 specification. No actually for OpenGL 2.2 specification it would have been great, for OpenGL 3.0 specification, it’s just a shame. You made us wait 2 years with so much great concepts for OpenGL 3 to end up with this…? Who did this? Is it marketing reasons? I can’t see a clue on this, it doesn’t make any sens.
Even if OpenGL 3 would not have been at the level of D3D10 in terms of features, I’m sure we would have wait for this and start with what we got.
In some ways, I expect nVidia to create it’s own API but I just hope there are not behind this mess… I really wonder that’s not the case but some will pay for this for sure.
Anyway, I fed up with OpenGL now, it’s time to go to something new I guest.
The greatest, and we are speaking about this here, always been done by people… maybe someones need to hear them.
Congratulation!
We have resolved our bottleneck and should be good to go with the rest of slashdot.
The approach in the DSA extension doesn’t invalidate any existing code.
The approach in Longs Peak invalidated all of it.
Yes, but Longs Peak would have been implemented by everyone. This extension will not be implemented by ATi or Intel until it becomes core.
The approach in the DSA extension doesn’t invalidate any existing code.
The approach in Longs Peak invalidated all of it.
And this is the all-wrong thought. If I had a 10-year-old application, of course I wanted it to continue working. This is what the old opengl2.x dll would have been for. Install the new GL driver, but it would still work. NOTHING is invalidated.
Now, if I decided to switch to GL3, I would NEVER expect to just link against opengl3.lib without any work. Instead I knew that I probably have to rewrite the whole thing, because that old application is not architected to meet the needs of a modern gfx card. Instead you just need a clean redesign. I’d had to throw out display lists and switch to a VBO based design. I had to throw out fixed function stuff and write shaders instead. I must not use that SELECTION/FEEDBACK stuff anymore… etc. Even those mighty CAD companies WILL have to rewrite their stuff some day. And I bet, they’ll use DX that day.
It would have been just honest to draw a line and introduce an all new API instead of what we got now.