More pages: 1 2 3
4
OpenGL 3.2
Saturday, August 8, 2009 | Permalink
Having been on vacation I'm a bit late to the party, but OpenGL 3.2 has been released and the specs are available
here.
I like the progress OpenGL has made lately and it looks like the API is fully recovering from the years where it was falling behind. If Khronos can keep up this pace OpenGL will remain a relevant API. I hope the people behind GLEW and GLEE get up to speed though because neither have implemented OpenGL 3.1 yet. In the past I rolled my own extension loading code, but was hoping to not have to do that and use libraries like the above. Looks like I might have to do my own in the future as well just to be able to use the latest and greatest.
Overlord
Monday, August 10, 2009
@Sopyer&Kyle: one have to remember the ultimate goal they are trying to achieve to understand why they removed immediate mode, display lists and so on.
They want to create a slim, pure and powerful graphics API, that means VBOs and shaders only.
Both immediate mode and display lists are for all intents and purposes software, so the plan is to have those put in another library like glu, or have people write their own, i know it would only take me a few hours or so to write something that emulates it, in fact i already did replace all matrix translations.
Kyle
Monday, August 10, 2009
@Overlord: well, dl are pretty as sw as VAOs are - none can be implemented on top of GL for performance resons, immediate mode could (and can be), but unless Khronos provides it, everyone will write their own version of that (or wont bother). BTW, im all for the ideo of gl toolkit branded by Khronos putting all that good stuff on top of GL.
Humus
Monday, August 10, 2009
Sopyer, I've implemented deferred shading, post process and UI without the need for any immediate mode or code to emulate it. If drawing quads is too cumbersome then perhaps graphics isn't the right field for you. It's easy to create a static vertex buffer containing the four vertices and reuse. Or better yet, generate the coordinates directly in the vertex shader and don't use any vertex buffer at all. This is what I usually do these days. It's easily as convenient as any immediate mode rendering.
Sopyer
Tuesday, August 11, 2009
@Humus well I daily work with deffered renderer and I can see how things like display lists and immediate mode could simplify code and make it more readable. The point of my complaints is not that it is not impossible to implement such things on top of OpenGL(even display lists - performance is another question) but that:
1) every developer should do this (if such stuff is implemented already it will reduce error count)
2) readability - immediate mode is very readable, but I can not say this about writing vertices and indices to some buffers and then doing DIPs with that buffers
3)simplicity - give beginers some simple API to start with, without need for 3rd party API
And about generating coords in shader - it's easy and handy, but as far as I remember every IHV says - if you can do some computations on CPU - do it here, to speedup shader code. Immediate mode just eliminate the need for such hacks.
And one more point XHTM2.0 was a failture because it was so simple and academic, and HTML5 succeeded because it was more practical and more usable in real world.
App
Tuesday, August 11, 2009
> 2) readability - immediate mode is very readable, but I can not say this about writing vertices and indices to some buffers and then doing DIPs with that buffers
You can hae readable code by writing a good wrapper for OpenGL 3.x API calls.
> 3)simplicity - give beginers some simple API to start with, without need for 3rd party API
Use OpenGL 2.0.
Both immediate mode and display list requires CPU to GPU transition. Which requires CPU time and bus bandwidth.
It is no longer fit with the current GPU hardware model, a powerful processing unit that can work alone without the help of CPU.
Not to mention that a wrapper over the OpenGL API can provide the syntax sugar you required. (If the demand of these features is high, the library provides such functions will be as popular as GLEW.)
And for beginners, it is more confusing to provide multiple ways to do the same thing. immediate mode vs Display list vs VBO
> 2) readability - immediate mode is very readable, but I can not say this about writing vertices and indices to some buffers and then doing DIPs with that buffers
You can hae readable code by writing a good wrapper for OpenGL 3.x API calls.
> 3)simplicity - give beginers some simple API to start with, without need for 3rd party API
Use OpenGL 2.0.
> And about generating coords in shader - it's easy and handy, but as far as I remember every IHV says - if you can do some computations on CPU - do it here, to speedup shader code. Immediate mode just eliminate the need for such hacks.
Using immediate mode is no faster than using VBO properly. Immediate mode is a syntax sugar only. Why don't provide syntax sugar in a library, but messing with the low level API that communicates with hardware?
Overlord
Tuesday, August 11, 2009
>"Using immediate mode is no faster than using VBO properly."
exactly, VBOs are in fact way faster, back when i first started working with VBOs i converted my shadowing code(stencil shadows) that used immediate mode to use vbos and even though it remade the vbo for each frame that part ran almost twice as fast.
for static meshes it can be over 10 times as fast.
So if i where to re implement immediate mode or display lists in some form it would be used to build VBOs.
DrBalthar
Wednesday, August 12, 2009
I don't know I wonder how relevant OpenGL will be in the future anyway OpenCL will sort of make it even less relevant than before. Larabee with it's own native code layer and other vendor GPUs more and more moving away from graphics API to more general and open APIs. I think the days for OpenGL and DirectX might well be over in a couple of years time.
FMoreira
Wednesday, August 12, 2009
And we will be back to software renders, this time supported by extremely powerful cpu(s)/gpu(s)!
yay
More pages: 1 2 3
4
