Toward Version 4.3

But is not the case that CAD developers are already moving to Direct3D?

Just to add something.

I looked at the way context creation is done.

The application should be able to
a) get major, minor and core or compatibility profile (this is done and good, please make this kind of a thing consistent across all khronos api’s so you only have to develop it once.)
b) when an application wants to exist let it present a version and profile to the driver.
The driver then decides to execute it or gives an error with does not have <needed version> for application: <application name>.

(There seems to be inconsistencies between the GL and GL ES about this.
Also I’m not sure if I read correctly
but please allow for a general api mechanism where the application can just do a call with the version and profile it wants.)
This can be useful for all the api’s, dealing with changing specifications.
Making a general thing across all khronos api’s benefits from only having to develop it once.

old applications will be recognizable by new drivers because of the calls.
New applications can just work on new drivers since the drivers can have a very good idea of what is asked. You can theoretically even break the api constantly and still have old and new applications running on new drivers without problems related to compatibility.
(Provided that the driver writers can keep up implementing everything.)
No danger for legacy + able to change everything without problems related to the way changing something could mess up expectations between applications and drivers.

Consider yourself a business with existing application code. If you have a choice between doing something that costs you profit and something that “makes” you profit, which do you think is gonna win? …assuming you’re sane.

It’s simple cost/benefit. And no, I’m not a CAD dev or driver guy. Just someone that realizes that what is theoretically/aesthetically/academically desirably doesn’t always pass muster when it hits the real world.

That said, with new application code, it makes more sense to target the purely new stuff of course. But why waste time/money/people rewriting older applications that work just fine.

Sampler objects are also semi-DSA/bindless, but they miss one important piece of functionality. You can’t bind a texture to GL_TEXTURE0 then sample it once with clamp/linear and a second time with wrap/point, for example. This can be very useful for encoding complex functions in textures, the hardware is capable of doing it (and has been since at latest 2002 or thereabouts), but GL doesn’t expose that capability so far as I can see - separation of textures from samplers remains incomplete (see further discussion point 4 at http://www.opengl.org/registry/specs/ARB/sampler_objects.txt).

There’s no reason why GL 4.3 (or 5.0 with 4.3 being the “expose as much functionality…” version) can’t make a clean break. Freeze the spec at 4.2 for existing programs, build a new spec that makes a complete break with the legacy cruft, let those who have to maintain apps for older versions continue with the older spec, let those who want to move forward use the newer. Yes, hardware vendors will need to maintain 2 sets of GL drivers as a result, but is that really any worse than the current scenario where both newer stuff and ancient crap must be maintained in a single driver (and all the pain and suffering that comes from that)? How sustainable is the current situation? Something has to break, the only question is what is going to break first.

Probably. I don’t know.

What surprises me is that they (CAD) care about backwards compatibility in GL 3.0, 3.1, 3.3, 4.0, 4.1 and future versions.
It seems to me that the features added are more usable in gaming situations rather then CAD.
That said, even most games don’t utilize all that functionality.

Which CAD program uses geometry shaders or tesselation shaders or sampler objects or floating point formats for textures and FBO?

So, overall, it doesn’t make sense.
The industry is run by FUD = Fear Uncertainty and Doubt.
Whenever a clean break was mentioned, people panick that old CAD programs and games would not run anymore.

Direct3D is a whole other world. It is a changing API. If CAD people want to move to it…I consider that moronic because it is a changing API. Something that they don’t like.

There’s no reason why GL 4.3 (or 5.0 with 4.3 being the “expose as much functionality…” version) can’t make a clean break.

It would be for the same reason that 4.2 couldn’t make a clean break. That 4.1 couldn’t make a clean break. That 4.0 couldn’t make a clean break. That … that 3.0 couldn’t make a clean break.

The fact that us people on a forum don’t see the reason doesn’t mean the reason doesn’t exist. And even if it doesn’t exist, that also doesn’t mean it’s going to happen.

Really guys, don’t get your hopes up.

[

Direct3D is a whole other world. It is a changing API. If CAD people want to move to it…I consider that moronic because it is a changing API. Something that they don’t like.

You should read this:
http://archicad-talk.graphisoft.com/files/autodesk_inventor_opengl_to_directx_evolution_788.pdf](http://archicad-talk.graphisoft.com/files/autodesk_inventor_opengl_to_directx_evolution_788.pdf)

Thanks. The whole thing is funny but specially this part

OpenGL uses an older technology called sphere maps for reflections, which means you use the image of
your environment taken from the perspective of a perfectly reflecting sphere.
Direct3D uses a newer technology called cube maps for reflections which means that you supply six
textures as the faces of a cube surrounding your model. Direct3D does the reflection computations using
the cube.

and that was from 2007, so GL 2.1 was already around. LOL.

In spite of the fact that we do not use any new fancy OpenGL extensions and
use OpenGL almost on the level of 1997 graphics HW technology, we routinely encounter OpenGL
graphics drivers that do not work correctly and as a result[…]

You don’t even need to read past the first page to get stunned by massive amounts of irony. Of course, it’s always better and easier to write and maintain more than 40 workarounds for crap that most likely has been redeemed by later GL revisions… :doh:

I really, really hope that the team at Autodesk developing the product is the only one with that policy. Otherwise I’d have to find a new desk to compensate for the hole I smashed into it with my head.

The next has to be GL 5 and must be a clean break from all previous versions. And as mentioned, if CAD dady is favoring D3D, then why bother with backward compatibility profiles, and as someone mentioned, maintaining too much in a single driver???!!! Games use D3D already and D3D is not stable either. So again why bother?

I predict, that we will hear a lot more ‘Version N+1 has to be a clean break’ demands before there will acually be a clean break (if ever)…

The only reason I could see why the ARB might consider making a third try for a new API (and again: they’ve tried it twice before) is because graphics cards aren’t getting that many truly new features that require API extension.

DX11.1 hardware features are… scant:

[ul]
[li]Shader tracing and compiler enhancements: Not a hardware feature. Not really.
[/li][li]Direct3D device sharing: Not a hardware feature.
[/li][li]Check support of new Direct3D 11.1 features and formats: Not a hardware feature.
[/li][li]Create larger constant buffers than a shader can access: Welcome to the party, D3D; glad you could make it :wink:
[/li][li]Use logical operations in a render target: Ditto.
[/li][li]Force the sample count to create a rasterizer state: Ditto.
[/li][li]Process video resources with shaders: Not a hardware feature, per-se.
[/li][li]Extended support for shared Texture2D resources: Not a hardware feature.
[/li][li]Change subresources with new copy options: Not a hardware feature.
[/li][li]Discard resources and resource views: Not a hardware feature.
[/li][li]Support a larger number of UAVs: Hardware feature yes, but only because D3D doesn’t provide a query and a flexible count of these…
[/li][li]Bind a subrange of a constant buffer to a shader: Welcome to the party, D3D; glad you could make it :wink:
[/li][li]Retrieve the subrange of a constant buffer that is bound to a shader: Ditto.
[/li][li]Clear all or part of a resource view: It took you that long?
[/li][li]Map SRVs of dynamic buffers with NO_OVERWRITE: Welcome to the party, D3D; glad you could make it :wink:
[/li][li]Use UAVs at every pipeline stage: Welcome to the party, D3D; glad you could make it :wink:
[/li][/ul]

Most of these have little to do with actual hardware. Basically, since D3D11, standardized cross-vendor hardware features have been fairly few and far between. Sure, we’ve got AMD pushing virtual texturing. NVIDIA’s pushing “bindless” textures. Other than that? No.

One of the cited reasons to abandon Longs Peak was that it was taking too long, that OpenGL wasn’t being responsive to new hardware. There isn’t any right now. Or at least, not much that’s cross-vendor.

Again, I remind you: Do not get your hopes up! This will not happen, no matter how much you want it. The sooner you accept this, the better.

What do you mean by GL revisions? AFAIK, newer versions don’t change much of the basics that these CAD programs are using (line rendering and non textured polygons).

The stupidity I see is that they say OpenGL doesn’t support Cubemap and that was posted during 2007 while GL 2.1 was around.
The other big stupid thing is that they are using the software renderer (probably for preview and printing purposes) instead of using FBO. Again, we are talking about the GL 2.1 era when FBO support was available on ATI and nVidia. The FBO extension had been around since 2004 (GL 2.0).

They are stuck in the stoneage of GL 1.1 obviously but I’m sure that they have discovered quite a few bugs which pisses them off.
Someone should teach them how to use GLEW at least so that they can move to GL 2.1.

What I wanted to say is that they would have easily profited by incrementally leveraging newer features and spec revisions which are usually acompanied by improved drivers which expose new features and, at least for the most mainstream features, reach pretty good stability at least on Windows after a few weeks or months. That’s what I meant by redeemed. So I fully agree that their problems would probably just have gone away by turning their brains on and moving to 2.1. Furthermore, if a company like Autodesk can’t convince AMD and NVIDIA to get their stuff working then I don’t know who could.

This whole development strategy blows my mind. Another thing I find very disturbing is the accuracy argument. If GL implementations from 1997 worked for them, how could they state 10 years later that the GL accuracy wasn’t enough for their needs anymore? Didn’t I read that part correctly?

This is called the Direct3Dization of the graphics software industry. Prety much like the DOTNetization of software.

[QUOTE=V-man;1237420]They are stuck in the stoneage of GL 1.1 obviously but I’m sure that they have discovered quite a few bugs which pisses them off.
Someone should teach them how to use GLEW at least so that they can move to GL 2.1.[/QUOTE]

You are being pretty harsh here. Its not like CAD’s are standing in the same place entire time. Yeah, they have loads of legacy code (ive seen some pretty crazy stuff in various cads) and switching overnight (or at all) is silly when they have something working (probably with shitload of workarounds and whatnot).

Most arguments against clean API break are bullshit though. There is only one thats valid imo.
If driver vendors were to commit to GL5.0 that has nothing to do with old GL, fixing old bugs will probably be lower priority (those same teams wont suddenly develop two drivers instead of one).

We are now 2012, therefore 15 years have passed. During that time, they (Autodesk) never considered rewriting their renderer?
But wait, they have decided to rewrite it! Except that it is in Direct3D. They are just assuming that it will be less troublesome than GL.

To me, it doesn’t make much sense.
Direct3D 10 isn’t going to last forever. At some, point Microsoft will stop releasing updates and just move on. It happens to all their products.

Furthermore, if a company like Autodesk can’t convince AMD and NVIDIA to get their stuff working then I don’t know who could.

I don’t understand it either.

But wait, they have decided to rewrite it! Except that it is in Direct3D. They are just assuming that it will be less troublesome than GL.

To be quite honest, it probably will be.

They won’t have to deal with GL driver bugs. If they’re going to start using advanced, shader-based features, then they will likely run into GL driver bugs quite quickly (just as many people on this site do). D3D implementations don’t have nearly as many bugs. D3D even works on Intel hardware, where trusting in any OpenGL version beyond about 1.4 is foolish.

They don’t need cross-platform support.

In short: given the stability differences, and given the fact that they need to rewrite their rendering system… which would you choose? Why would you choose OpenGL for a Windows-only program that you are basing your company’s survival on?

Can you think of even one reason to do so?

Direct3D 10 isn’t going to last forever. At some, point Microsoft will stop releasing updates and just move on.

They will likely have planned for that. With a new codebase, rewritten from scratch (or near-enough), it’ll likely be easier to switch API functions as they change. Besides, it’s not like D3D10 is so massively different from D3D11 in terms of the basic API.

Nope, not me at least. However, an interesting question would be how many major companies out there think the same way and have already or will abandon their GL rendering code in the foreseeable future. If the amount was significant that would mean one major reason gone for not revamping the GL. (Which I too believe won’t happen but I still maintain a glimpse of hope. :wink: ) Another question would be, why aren’t any of the CAD guys running around the forum anyway? Have there been encounters in the past?

If i was a major company i probably wouldnt care for OpenGL at all (and i do like it, kind of). That is of course assuming i (as a company) dont care for mobile & mac or linux, which may not be true.

Another question would be, why aren’t any of the CAD guys running around the forum anyway? Have there been encounters in the past?

How do you know that :slight_smile: