IGLX capabilities versus current OpenGL (Seeking straight dope)

Then you’ve misunderstood my point.

The “write once, run anywhere” moniker was originally coined for Java, representing the hypothetical ability to just code against the Java APIs and your bytecode could be run on anything that supported Java, sight unseen.

The reality of Java development was that a more appropriate moniker would have been “write once, test everywhere”. Because, while you may be writing under the same API, the stuff behind those APIs can be very different depending on platform specific issues. And you can’t ignore those issues if you want your program to run well.

OpenGL is similar; you cannot just write applications against the specs and expect them to run on platforms you haven’t tested them on. You never know what driver bugs are lurking out there. So if someone wants to “satisfy as many users as can be”, if they are writing a serious application, then they will have to test on any platforms that they intend to support.

That’s a hefty investment. “Relatively portable” is in the eye of the beholder.

This section seems like it was written when Vulkan was just released, rather than now, when Vulkan has become a pretty clear success. User adoption is about as widespread among serious developers as one could hope at this point, and it’s only growing from there.

If you want proof that Vulkan is doing just fine, consider this: CAD developers want to get on-board the Vulkan train (as evidenced by them asking for certain line drawing extensions). You know, the guys who helped torpedo the real OpenGL 3.0 Longs Peak because they didn’t want to rewrite their code slightly? I’d have thought you’d have to pry OpenGL 1.1 out of their cold, dead hands.

Vulkan is successful because it isn’t as “straightforward”. This is the API that professionals wanted: one that exposes the low-level details so that they can tinker and get the performance they need. That is not, and never will be, “straightforward”.

Intel has plenty of Vulkan implementations. Indeed, it seems like they’ve been keeping their implementations pretty up-to-date with Vulkan releases.

What they neglect is old hardware, and they always have. You may not consider 10 years to be old, but Intel certainly does. They routinely stop supporting hardware after a certain point. As far as Intel is concerned, such hardware it’s outdated, unsupported, and irrelevant.

So it’s wrong to presume that there is some widespread issue of Vulkan support from the fact that Intel doesn’t do things from older hardware.

EDITED: The above QUOTE markup seems to be broken. It might be of concern to staff. I don’t know if I want to report it.

It depends where your priorities are. If your goal is raw power maybe program another pathway to satisfy commercial users. But professionals can also be noncommercial, and not have their backs up against performance constraints too.

Splitting the baby is very different from testing for feature support, etc. I program mainly Direct3D. It has straightfoward feature tests. Whereas OpenGL cannot say if it support Non-power-two textures or not (Non Power of Two Textures · Aras' website) I learned recently. I started out programming with OpenGL decades ago, as it’s tempting, but it’s today more of degrading chore one does when your hope is to be fair to Apple and Linux communities, in theory. If your concerns are big business then Apple can look like customers, but if not, it’s just a matter of be inclusive in principle. For that, Vulkan is not (yet) very attractive, unless you need it. Programming Vulkan means that you either have a fallback, or don’t care about some people who have different PC setups. So, the latter option can be an ethical dilemma even if not seen as practical. And looking bad too, is the same as being bad.

You may not consider 10 years to be old, but Intel certainly does. They routinely stop supporting hardware after a certain point. As far as Intel is concerned, such hardware it’s outdated, unsupported, and irrelevant.

I depends on how you measure 10yrs. Like 10yrs from purchase, that is older than most PC products are expected to work… 10yrs from release, can depend on if you are purchasing expensive hot off the presses hardware of not. Software moves very slowly, 10, 20yrs, it doesn’t really register. If it were otherwise Vulkan would have come much further by now, C++ would have come much further, older people can see how slow events unfold, younger people (I know you’re not young because your name has been around forever) see all of the new things and can’t wait to jump onto the new wagon, but technology is really a slow moving ship, and most new products will not stand of test of time, and those that do will probably not be overnight successes.

If Intel is neglecting old (really current) hardware, it’s because it’s begrudgingly hedging its bets, afraid of being behind the curve one day. It doesn’t represent that it feels pressure from its customers.

I use my workstation to do VR with PlayStation VR. It’s not like it can’t do great things with 3D software. It should be able to do Vulkan too. It’s not ancient. But I’m not going to replace it as long as it works, because it does everything I need it to. I prefer to own chipsets that are built into the mainboard with the CPU. That doesn’t mean it’s second-rate or shouldn’t run Vulkan or something. The current gen video game consoles are integrated chipsets too. Vulkan just doesn’t have the purchase (yet) I think enthusiasts want it to, and that probably boils down to the split between it and OpenGL, and the fraught history of OpenGL casting a shadow over Vulkan. Open graphics libraries need to be easy (and worthwhile) to use whether by large firms or small private developers. When Vulkan is mature it will get wider adoption. If it doesn’t work on all systems that OpenGL does, it’s immature, simple.

It’s not broken, but rather just a quirk of the Discourse forum software we’re now using. You have to put tags like [quote] and [/quote] at the beginning of a line. Appending them to a line of text results in Discourse not parsing the tag as a tag. @khronos, just FYI.

I’ve fixed this in your post for you.

Thanks for the explanation Dark_Photon.

It should be escalated to the Discourse team. The QUOTE tags were generated by buttons, but it’s possible I trimmed the quote and then patched it on the end. Or more likely I mouse selected the body and pasted in the quote text I wanted. Either way it can’t be so brittle.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.