I wanted to place this text in previous post, but that was hard to do logical division, so I devided into two posts. This post will store my thoughts about graphics APIs and their evolutions/revolutions. In discent times we programmed GAPI ourself, that gave as direct-to-metal access: sounded good, but it was impractical and there were much problem in case of porting to another hardware. So Microsoft made Direct3D for such graphics abstraction, then SGI made IrisGL which was opened later and transformed to OpenGL. Both of them are gold standard for graphics. They do a lot to make it easier to program graphics, and we can see the richest graphics in games today(like CrySis by CryTek or Battlefield by DICE). Anyway abstraction is made for simplification, but graphics made richer and now we have another problem: huge CPU usage in high numbers of draw calls.
That's why there is Mantle by AMD and Metal by Apple(only for iOS for now), also is Direct3D12 on the way. They are made for dropping out this overhead of draw calls by moving more work to programmers. It is really funny to see that the idea of "low-level" Direct3D12 is back to Direct3D1: we are making command buffer, then we are making commands and then driver consumes this buffer. The same we might say about Mantle and Metal - the are too "low-level" with somewhat "same" functionality.
Alex St. John has written a good post with comparison of Direct3D and Metal, and thoughts about OpenGL. Also, I'd like to talk about OpenGL too... It's stuck. Literally. I know Khronos Group tries to push OpenGL to the top of graphics industry, they are making a good job(but OpenGL is still lacking some cool features, like context-independent concurrency), but the main problems are IHVs. Every IHV is making it's own implementation, because OpenGL is only the specification and it doesn't have run-time component like Direct3D has. That's really bad that no one in Khronos who could bang the table and say "that must be as I say!" to stop this noncense of varying OpenGL implementations. I don't want to talk too much about this, because thare a lot of negative posts that already have the same opinion about OpenGL. Anyway, I'll still wait for OpenGL NG, I believe that Khronos Group will make it.
That's enough of "void" talking, let's consider my thoughts about modern graphics API. First of all, API must provide one view of resource as raw memory. This means that we will work with it like in our programs via malloc/realloc/free, just like in CUDA. Second thought is continuation of the first, we must control allocated chunk of memory by ourselves, making needed memory barriers or doing sequental consistency read/write operations and etc. Third is that API must provide controlling interface of GPU scheduler. That would bring us continous kernel execution like in CUDA, where we can write kernel that has ability to launch other kernel functions. The third means that we will not be CPU-bounded. Ideally it would be the greatest thing to do programming of GPU like CPU. The best reference to this approach is CUDA. Also it's good to see something
That's all what I want to say. This is the last useless post, next time I'll write about our engine.
