Year of the Linux Desktop

It's closer than you think!

Microsoft has decided to turn into Apple, and will be moving towards closing their OS ecosystem and focusing on making their own hardware/software products:
http://www.infoworld.com/t/technology-business/microsoft-pc-and-tablet-makers-youre-not-our-future-195877

Valve is releasing Steam and Source Engine for Linux, allowing 3rd parties to release for Linux as well:
http://www.extremetech.com/gaming/127475-valve-confirms-steam-and-source-for-linux-signals-low-confidence-for-windows-8

Valve is developing an open game system/common platform based on Linux and PC hardware:
http://www.develop-online.net/news/40592/Valve-confirms-console-and-mobile-hardware-plan

Wayland 1.0 release this summer, finally something to replace X11/X.org:
http://www.phoronix.com/scan.php?page=news_item&px=MTA4MzQ
http://www.phoronix.com/scan.php?page=news_item&px=MTA5OTY

Furthermore, the continued economic recession/depression will drive more and more businesses to adopt Linux, and this will increase spread to user's homes. As consumer's budgets become smaller, they will adopt Linux in increasing numbers as they become aware of it through the grape vine and wish to keep their old computer hardware running without relying on unsupported and out-of-date software.

Those with money will choose Apple over Microsoft.

Microsoft's business model is dead.

Meanwhile Cho Jong Weng from a town of Su-hong finally adopted linux.  Truly it is a year of linux on desktop!!

why Linux sucks
http://www.youtube.com/watch?v=Sh-cnaJoGCw&feature=youtu.be
why it sill not be the year of the Linux desktop for anytime soon

I don't understand why game developers insist on using DirectX. OpenGL is a superset of Direct3D and has almost identical performance when doing the same thing on any decent implementation¹. DirectX is a bit more convenient because the hunt for entry points is easier and the helper libraries don't suck as much as GLU, but isn't portability more important?

<sub>__________________
1. All currently used drivers but Intel's for Windows.</sub>

Microsoft should have stuck with making mice.

>>43
Game programmer here. You are wrong. Direct3D11 is actually a superset of OpenGL 4.3, although they are almost at feature parity. OpenGL lacks support for building command buffers/display lists from other threads, where as D3D11 has deferred render contexts which can handle this. There are no OpenGL extensions from any vendor which solves this. Direct3D11 implements everything that OpenGL 4.3, plus vendor extensions, implements minus the deprecated stuff in OpenGL like the immediate mode functions and fixed-function pipeline.

Direct3D11, if you look beyond the fact that it uses COM and has that OOP feel to it, has a better object model than OpenGL that results in less call overhead when mutating render state. Render state changes are batched far better and the API has a better fit to how driver implementers do things internally.

John Carmack even admits this now.

That said, it doesn't matter what you use. Game programmers ultimately have to build code paths for whatever is best supported and has the best performance on each of the targeted platforms. There is no OpenGL support on the XBox 360. On the PS3, only OpenGL ES 2.0 is supported, so most developers just bypass the API and go right down to the metal and program the GPU via IO ports and memory mapping, and then offload a bunch of processing onto the Cell SPU cores on the CPU.

Which API has a better design doesn't matter at this point. Shipping code that can beat the competition and deliver a superior game and visual experience is what matters.

Furthermore, 3D graphics APIs are going to be almost irrelevant for this next console generation. Developers are moving back to pure software rendering that uses the GPU as just another general purpose processor cluster, and it looks like OpenCL will be the biggest player here. OpenGL is just used for the framebuffer. OpenCL has interop capabilities with both OpenGL and Direct3D as part of the specification, for resource sharing.

Even on the next XBox, where MS won't support OpenCL, because AMD is open sourcing their OpenCL stack and Clang/LLVM already compiles OpenCL Kernel C for Power and AMD's GPU ISA, it will probably only take a couple of man months to build your own OpenCL implementation for XBox. Spending two months getting OpenCL working on XBox Next is better than spending 10 man years building an entire DirectCompute + Direct3D render code path.

>>45
OpenGL lacks support for building command buffers/display lists from other threads, where as D3D11 has deferred render contexts which can handle this. There are no OpenGL extensions from any vendor which solves this.
What about the wiggle ShareLists function and the shareList parameter to GLX CreateContext? If I'm right OpenGL has been supporting this for years!

Direct3D11 implements everything that OpenGL 4.3, plus vendor extensions, implements minus the deprecated stuff in OpenGL like the immediate mode functions and fixed-function pipeline.
What about NVIDIA's bindless, GL_AMD_pinned_memory and the very new GL_AMD_sparse_texture (http://renderingpipeline.com/2012/03/partially-resident-textures-amd_sparse_texture/)?

>>45

I don't mean to be a an OpenGL fanboy or anything, but what would be a use case of multithreaded display list building? Why not have the threads submit requests for display lists to a master thread that uses the OpenGL API? If it all had to go over the bus anyways, I don't see the point of using threading other than convenience for the programmer, and convenience can always be obtained by abstraction within the application code. I could be off though.

Your post makes me want to get into the games industry.

>>47
YOU FANBOY

>>46
>What about the wiggle ShareLists function and the shareList parameter to GLX CreateContext?
Display lists were deprecated in OpenGL 3.1, and they don't work with vertex/index buffers anyway which is pretty much how all rendering is done these days. Display lists were meant for capturing immediate mode rendering calls only. They need to resurrect the display list idea and make it work for everything.

>NVIDIA's bindless, GL_AMD_pinned_memory
This is admittedly a problem, mostly because there's no work-around within shaders when the GPU does not support this, which is why you won't see it a part of the core API of either Direct3D or OpenGL. There's no standardized fused memory model across the various vendors yet, although AMD's FSA is good step in this direction. On the XBox 360, the memory model is already merged and there are proprietary extensions added to Direct3D9 to allow you to do this, but on the desktop, you are SOL.

>GL_AMD_sparse_texture
Direct3D 11.1 allows you to discard and page in mipmap levels through resource views, which can be used for sparse 1D, 2D, or 3D texture maps. It's equivalent to GL_AMD_sparse_texture.

http://msdn.microsoft.com/en-us/library/windows/desktop/hh404616%28v=vs.85%29.aspx

Final Verdict:

You: +1 Me: +2 Sussman: +∞

>>47
In games or simulations, when rendering large scenes, hidden surface removal is an important part of the rendering pipeline in order to make it perform adequately. The fastest polygons are the ones that are never drawn. Typically, you need to traverse some sort of spatial tree representing the world and cull geometry that isn't inside the view frustum or that is occluded by other geometry, and then build a final draw command list that you then sort based on certain criteria. On systems with enough spare CPU cores, you can farm out this work to multiple cores and buid a command list for each render stage.

>>49
Sorry for the sloppy quotations. I actually know how to properly quote
but I was lazy and didn't double check,

>>49
Display lists were deprecated in OpenGL 3.1, and they don't work with vertex/index buffers anyway which is pretty much how all rendering is done these days.
Implementers don't actually care about deprecation and display lists do capture client-side arrays.

but on the desktop, you are SOL.
Not with OpenGL.

>>47
You're absolutely right; Microsoft just went for building it into the API. Frankly I think it's fine, but it's by no means a new thing or a feature that's terribly important. For the most part, programmers who needed to, would implement this in their application code anyway.

bampu pantsu