[QUOTE=Alfonse Reinheart;31467]I explained how it was irrelevant, but you failed to show relevance. Declaring it to be relevant doesnât make it true.
You said: âSo unless the software vendors found something marginally better and it can significantly make a difference in terms of performance, stability, reliability, development resources, and ease of maintenance, they will not going to switch to it or even try waste time implementing a new graphics path.â
Reality said: âMany high-performance software vendors are rapidly adopting Vulkan and similar APIs, which do not have many of the features you cite.â
Thatâs a contradiction; your statement and reality cannot both be correct. And since reality is, well, real, it is your statement that must be incorrect.
Thatâs how logic works. If âsoftware vendorsâ are supporting Vulkan and other APIs, even though those APIs do not offer the qualities you claim, then âsoftware vendorsâ clearly do not need those things in order to support an API.
Bwa ha ha ha ha! Man, thatâs a good one.
⌠oh wait, youâre serious. Let me laugh even harder: BWA HA HA HA HA!
Even among 3D modelling applications, OpenGL is not âthe industry standardâ, as many of them do support D3D as well. So only in exceptionally narrow fields is this statement even remotely true.
You can quote marketing slogans all you want, but reality is always correct. âThe industryâ does not consist only of CAD developers.
Only with regard to OpenGL ES in the mobile space is it âthe industry standardâ. And, as Ratchet pointed out, itâs only because itâs the only game in down, not because itâs better than the competition.
Letâs take your analogy at face value. Iâm also going to pretend that you said âCâ instead of âC++â, as many programmers reject C++ as a viable alternative to assembly (note: I donât necessarily agree, but itâs a semi-widespread opinion). Whereas C is generally considered the lowest level that most reasonable programmers are willing to go.
So letâs ask a simple question. Why do most programmers, when seeking performance, choose not to reach below C? Why do they avoid directly writing assembly, except for certain very specific cases? There are many reasons, so letâs contrast these reasons against Vulkan v OpenGL.
Compilers are really smart; they are very good at taking C-like code and turning it into something efficient. They can do this for disparate architectures. Itâs also generally clear from looking at C code whether or not it will perform reasonably well when compiled.
The equivalent in the OpenGL analogy to a C compiler is the OpenGL driver. So⌠have you actually used any OpenGL drivers of late? Theyâre rock stupid. They are terrible at taking rendering commands and turning them into something efficient. Even ignoring the minefield of bugs that most drivers contain, getting optimal performance often requires doing things a certain way. And OpenGL as an API makes it very difficult to know what that way is. Small batches, for example; itâs certainly not apparent why thatâs a bad idea, if you just look at the API.
C is well-designed for efficient compilation. It gives the programmer high-ish-level constructs that they can build on, while not over-burdening them by abstracting the machine too far. The constructs it provides are useful, but the abstraction is close enough to the metal that little if any performance is lost.
Back to OpenGL. It is not well designed in this regard. The old glBegin/End stuff is absolutely atrocious, an abstraction that serves only to inhibit performance. Even buffer objects and texture objects are high enough levels of abstraction that they usually cause problems. Many drivers often have to shuffle buffers and textures around in memory, just to find the most efficient memory pool for it based on how you use them. Drivers sometimes have to readjust a textureâs format if you write to it with an FBO, since not all formats are able to be used as render-targets. And there are plenty of other places where the abstraction gets in the way of performance.
Different CPU architectures are different, and assembly that can be incredibly fast on one architecture may be excessively slow on a different one, even if both CPUs consume the same instruction set. As such, compilers are able to take high-level constructs and compile them to be most efficient for the expected platform. And the C programmer doesnât have to be burdened to know these limitations.
Back to OpenGL. Here, the analogy works a bit better, as the buffer/texture memory abstraction allows different implementations to have different arenas of memory, without burdening the OpenGL programmer with knowing about them.
However, if performance is an issue⌠the OpenGL programmer must know about them anyway. Take unified memory architectures, for example. I can develop a rendering algorithm that is fast on these architectures, because I know that mapped pointer access to buffers will be basically no different from just (uncached) CPU memory. I know that mapping the pointer will likely be free in cost, and I can build my entire algorithm based on that knowledge.
But on multi-tiered memory architectures, that algorithm may become unusably slow. Under Vulkan, Iâd be able to tell which hardware Iâm working with and adapt my algorithm accordingly (perhaps turning that feature off on inappropriate hardware). With OpenGL, the best I can do is query the vendor string and only active it based on the results. Hardly a portable solution, if someone comes out with a new unified memory architecture processor that Iâm not aware of.
So while your analogy might seem to hold, under any significant examination, they are not analogous at all. Thatâs why the Fortran v C parallel worked much better. Fortran is the higher-level; its abstractions inhibit the user or otherwise make certain performance gains impossible. C gets out of the programmers way, and puts abstractions in place that are just high enough to be usable, but no higher.[/QUOTE]
My final words:
You are full of it. And you are the troll of the OpenGL forums as some one said. You always try to argue and manipulate facts with maybe âniceâ sentences but they are far away from reality.
Direct3D will die. No Direct3D 12. âVulkanâ will never see the light.
OpenGL will role as the industry leading standard of accelerated graphics for the next 100s years or until computer graphics die.
Finally,
Hereâs the middle finger to everyone betting on OpenGL death!
