If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
I haven't worked with OpenGL all that much, but while the attitude of "throw legacy away" makes sense in a way, on the other hand it makes me think it might overcomplicate things... My card game uses OpenGL 2 commands, instead of shaders, because I literally need only textured squares. Doing the same thing with shaders would be more complicated than just calling functions that do it. And yet the function pipeline is considered legacy.
Of course, that could be solved by making a library in which those functions create shaders and whatnot, but at the moment I'm not aware of such libraries...
I haven't worked with OpenGL all that much, but while the attitude of "throw legacy away" makes sense in a way, on the other hand it makes me think it might overcomplicate things... My card game uses OpenGL 2 commands, instead of shaders, because I literally need only textured squares. Doing the same thing with shaders would be more complicated than just calling functions that do it. And yet the function pipeline is considered legacy.
Of course, that could be solved by making a library in which those functions create shaders and whatnot, but at the moment I'm not aware of such libraries...
If you only need textured squares, why are you using OpenGL at all? Couldn't this easily be achieved without a GL API on any even slightly modern hardware? My programming experience is limited, but I've at least made basic colored and textures shapes in my limited experience with C/C++. Wouldn't that leave OpenGL for more high performance 3D applications, then?
I do not think many people use 20 year old hardware, and even if they do, they could use an older version of openGL.
Or am I thinking to simple ?
I think that's the point, modern OpenGL still has support for that old hardware. And by "support", I mean a lot of legacy cruft in the codebase, not that it'll actually run on that old hardware. Rich wants to dump said cruft in favour of a modern, simpler API. Remove all the old, "legacy" stuff, the "compatibility" modes and so on to create a leaner, simpler API.
Having to deal with some of those issues, I must admit he is right.
What would be interesting now, is to know what is the action plan from Khronos board members to overcome this with the next openGL API.
Making a global simplification, and having a bindless API will be the minimum requirements to compete with D3D12 and Mantle in 2015.
If you only need textured squares, why are you using OpenGL at all? Couldn't this easily be achieved without a GL API on any even slightly modern hardware? My programming experience is limited, but I've at least made basic colored and textures shapes in my limited experience with C/C++. Wouldn't that leave OpenGL for more high performance 3D applications, then?
Or just use SDL2 or some other OpenGL accelerated 2D library? On another hand, rewriting your program to use shaders instead of fixed pipeline would probably take you a handful of hours, since the shaders you need are extremely rudimentary.
I agree with much of that, but the only elephant in the room is Khronos' lack of certification. It's pretty much the only thing that could give Intel's Windows and AMD's Catalyst teams a much-needed kick in the ass.
As much as a single crash or misworking API when running heavy multithreaded torture tests? No cert for you.
Comment