The Siggraph class "OpenGL: What's Coming Down the Graphics Pipeline" on Wednesday should be interesting. Anyone going?
Printable View
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.Quote:
Originally Posted by Jan
<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.Quote:
Originally Posted by HenriH
On the topic of "SM4 proper", do you have some sense of what you think is missing ?Quote:
Originally Posted by modus
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...ate_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.