Developers Voice Concerns About OpenGL 4.1 State Tracker

[pingufunkybeat]

So he is going to develop OpenGL state tracker? ... from scratch? ... over summer? ... all alone? Is he some kind of superhero from outer space? How come I've never seen his BIG achievements before? Why it's taking so long time for team of skilled developers like: Alex Deucher, Dave Airlie, Marek Olšák, Brian Paul etc. to write OpenGL 3 state tracker when one inexperienced student from Belgium could do it alone and probably overnight ? Maybe he was on a trip to Holland recently and overdosed ?

To be serious: I think that when someone says BIG words, he should have THICK portfolio behind his back. I think that words of Denis aren't credible and are only nutrition for dreamers.

That's because a pure OpenGL 3 state tracker (software only) is considerably simpler than Open GL 1-1.5 and 2-2.1 + extensions plus all the needed changes to Mesa, which is sometimes not easy to update for yet newer extensions.

Still, it's extremely ambitious. Best of luck, and hopefully some of his work can be re-used if it doesn't work.

[plonoma]

Somebody needs to shake khronos awake.
Tell the ARB what version numbers are for.

I mean If I make libs that implement an api I do the following.

Start with lib<api name><api major version>.
This way I can install multiple versions of the same api in one directory.
Use multiple versions of library in one project without confusion.
(doing use for one major version and writing the fully qualified name for the others)

This is easy but you have to be consistent with keeping the version numbers to distinguish things. This isn't very complicated and much simpler to implement robustly than adding profiles and other special things.

This way compatibility can be broken while old apps can still function.

[discordian]

plonoma: indeed, and that was initially the plan with OpenGL 3.0, then it was a year late together with total radio silence and out came a release that merely added a few features to 2 decades old base.

IMHO, I would actually turn things around (if I had infinite time at hand, cared enough and knew its 100% possible) - write a wrapper that runs on a clean core OpenGL 3/4 and provides all the legacy crap for apps that need it.
That way driver developers (FOSS and companies alike) just need to write a way simpler core OpenGL 3/4 driver. Quite possible apps using the legacy stuff would run a bit slower through the wrapper, but who cares... and if a new OpenGL 5.0 comes around with changes that break compatibility, just use this as base for the wrapper. ie. there is always just 1 or 2 clean and simple versions to write drivers for.

If thats done then driver-writers wont hesitate to switch to the latest core OpenGL ASAP!

[V!NCENT]

So he is going to develop OpenGL state tracker? ... from scratch? ... over summer? ... all alone?

Let me illustrate how this sounds to me:

So he is going to build a device that can make people fly? ... in the heavens? ... without God's help? ... all alone?

[marek]

I -- and most other tech-oriented games devs I've spoken to -- are totally cool with stripping the compatibility profile. All that crap is garbage. Yes, it means rewriting some small portion of a larger app to port. So does moving from DirectX 9 to DirectX 10.

This is a good thing. The baggage is _confusing_ for developers. Almost nobody knows how the new versions of OpenGL actually work. I've been working on an OGL3 tutorial for a few months, and it's crazy how little documentation there is and how many people are still mixing in old OGL2 functions.

Plus the old stuff is slow. The matrix stack alone is a source of inefficiency and confusion.

Burn that stuff with fire.

The games industry devs -- and many other graphics professionals -- wante Khronos to totally break the API/ABI for OpenGL 3 anyway. We're still upset and disappointed that the CAD wienies got their way and retarded OpenGL's progress by years, and pretty much sealed the fate of Direct3D being the overwhelmingly superior API (which just unfortunately is not cross platform).

I agree with your point that the old features should be burned with fire. But they still exist and we can't ignore that. No matter what game devs or tech folks say, they only care about themselves and yeah, they don't really need any of this crap. But there still are tons of apps which are using deprecated features, and like or not, drivers must support them all. This is not only about future apps, it's especially about existing apps people use now. I wouldn't be surprised if 100% of the GL apps in the PTS used deprecated features.

[popper]

Denis Steckelmacher the GSOC student that proposed a GSoC : OpenGL 4.1 state tracker however after getting very little support or engagement for that, and not even being asked to write one of the missing [not started] Mesa routes on the GL3 http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt to-do list as a qualification task as all potential students probably should if things are to progress this year, and why doesn't that GL3.txt list have direct URLs to the routines anyway to save time and effort hunting the definition data down ?

he has now stated on the [Mesa-dev] list he want's to try a GSOC : OpenCL over Gallium3D driver instead.

"Denis Steckelmacher:
Hello,
After some messages on this list, I reconsidered my GSoC proposal and decided
to give a try at an OpenCL state tracker. I will base my work on the Clover
branch of Mesa.

I read its code, which is very well-done and clean"

[NSLW]

he has now stated on the [Mesa-dev] list he want's to try a GSOC : OpenCL over Gallium3D driver instead.

And that affirms my opinion about him: He isn't worth anything but words.

[popper]

"Denis Steckelmacher:stated on the [Mesa-dev] list he want's to try a GSOC : OpenCL over Gallium3D driver instead."

And that affirms my opinion about him: He isn't worth anything but words.

well it early day's yet, give the guy a chance, who knows he may become a prolific coder, and dont forget it's primarily a learning experience designed to produce code and grow the new developer base for a given project as old dev's get tired, slow down and move on.