This is huge, really huge for anyone who write DirectX games and want to make them run on OSX/Linux.
This is basically what a part of Wine do, am I wrong?
But yeah, this is awesome. As a side note, developers who want to make games run on OSX and Linux should just stop targeting DirectX. This is good for already-existing games and port them over, but in 2014 if you're still writing games in DirectX, you're most likely doing it wrong.
No, you are not. There is no wrong and right, it's just a stupid statement. OpenGL is years behind D3D (not DirectX, it's not comparable!) in many areas, and writing using the whole DX stack can be much nicer than setting up a GL stack with a lot of different libraries.
I'm not a video games programmer, but judging by the benchmarks it seems the most efficient graphics stack is based around AMD's Mantle: http://hothardware.com/News/AMD-Mantle-vs-DirectX-Benchmarks...
John Carmack suggests the OpenGL extensions that NVidia have developed give comparable performance to Mantle: http://n4g.com/news/1376571/john-carmack-nvidias-opengl-exte...
Explain please?
You can practically issue render commands only from one thread. And there is no way to save bunch of commands anymore as display lists were deprecated. Also it's still very much state machine based. So you have to do a lot of individual calls to set everything up for actual draw call.
I personally love OpenGL and use it on my work. However this is one of the biggest drawbacks on OpenGL currently.
OpenGL has context sharing, which means several contexts in different threads sharing the same objects. You can issue commands as long as you synchronise access to objects yourself. In practice, that means filling buffers, rendering to an off-screen framebuffer, etc. from other threads.
If it works on Windows, then I wonder if it really matters. I've seen a lot of games (e.g. Team Fortress 2) still offer multithreading as an option in the UI, so there's already two code paths there.
D3D multithreading works (even, to a lesser extent, with D3D9!), and this is one of the reasons why our D3D9 renderer is dramatically faster than our GL one - we can offload a subset of rendering work to helper threads instead of keeping it all locked on the thread that owns the window.
TF2/etc do offer a multithreaded rendering option, but IIRC on Windows their engine still uses D3D. Also, note that it's an option, because the feature used to be very unstable (still might be, actually) - I suspect people using the GL version of those games may have to disable it on certain hardware/driver configurations.
In D3D it works as OpenGL display lists would, except with arbitrary commands. So you have multiple threads composing the scene and then a single thread just issues few commands to replay the command buffers created by the other threads.
It would be rather simple to implement the same in OpenGL as we already have the display list concept, even if it originally was made to reduce the amount of glvertex3f calls.
"complete lack" was maybe bit of an exaggeration, however in practice it is true.
This leads to developers pursuing various less optimal solutions that all involve more startup time for users and less predictable performance and robustness for developers (at least when compared to the solution D3D has offered for more than 10 years). So when people say OpenGL is years behind D3D this is one of the things they mean. D3D isn't perfect here either. There is a fair amount of configuration-specific recompilation going on, but the formats are more compact than the optimized/minimized GLSL source formats people are pursuing on OpenGL and while the startup time (shader create time) is still too long, it is still much better than OpenGL. Shader robustness is generally more predictable and better on D3D but it's hard to disentangle shader pipeline issues from driver quality.
To be fair multicore is also an issue for OpenGL, but D3D isn't great at that either. The current spec for D3D11 includes a multicore rendering feature called "deferred contexts" but performance scaling using that feature has been disappointing so it isn't a clear win for D3D. Other APIs (e.g. hardware-specific console graphics APIs) expose more of the GPU command buffer and reducing abstraction there allows for a real solution to the multicore rendering problem. There should be a vendor neutral solution here, but so far neither of the APIs has delivered one that is close to the hardware-specific solutions in performance scaling.
Which is kind of understandable - I use Mesa as my "assumed" OGL level, and it just hit 3.3. So you absolutely can't assume anything from the 4 line.
Though I still couldn't use geometry shaders as an assumption, because as recently as Sandy Bridge Intel GPUs didn't support it. Add on if you want to port to mobile you need to refactor to GLES2.
http://programmers.stackexchange.com/questions/60544/why-do-...
But this lib is for those countless DX9 games already in existence. Valve is making SteamOS ports as easy as possible.
Of course, if you are targeting Windows XP... you got to think back a lot further than that. In some ways theres some elegance in how you can write GLES2 shader code and have it run everywhere, including on mobile, and just check extensions for everything else you use.
Personally I use the ES3 subset of 4.3 right now. Same code works perfectly on ES3 mobile HW and 4.3 desktop HW. The only features it lacks are geometry and tesselation shaders.
I'm also using compute shaders right now, even though they are not supported in ES3 they are going to be supported in the ES next update. And that gives me effectively everything geometry shaders etc can ever bring.
By using those I'm saved from checking any extensions. And there is not much they could even bring to the table.
fp64, draw_indirect, multi_draw_indirect, shader_buffer_load, bindless_texture.
These are all killer features in writing fast renderers.
It is better if the game does GL directly, which is why something the game can link in works better.
Wine is a reimplementation of the WinAPI on Linux, so Windows applications can use the same functions in WinAPI even if they are on Linux.
Also, most AAA engines (such as Unreal Engine) already have an abstraction layer for OpenGL and DirectX so their games can run independently of which one is missing.
i have to say its good to see this but i'm mildly disappointed too... DirectX --> OpenGL is one thing, but a properly cross platform rendering interface that will work with DX, its flavour on 360, the novelties of Win8 and Xbone as well as PS3 gcm and gx/gx2 on nintendo platforms whilst dealing with the quirks of desktop vs. es gl? that would still be a pretty run of the mill technical achievement of no particular note.
aside from that i don't like the code. singleton class instance? why not use the static keyword so the compiler knows what you want and can optimise accordingly and save you the potential to shoot yourself in the foot. and when did 2500 lines become an acceptable file size for a header? also did we forget that you can nest folders, or name files with modern 1990s style filenames...
i need to open source my stuff...