Multi-Threaded Rendering
Multi-threaded rendering? "But," you’re saying, "we’ve had multi-core CPUs for several years now and developers have learned to use them. So multi-threading their rendering engines is nothing new with Direct3D 11." Well, this may come as a surprise to you, but current engines still use only a single thread for rendering. The other threads are used for sound, decompression of resources, physics, etc. But rendering is a heavy user of CPU time, so why not thread it, too? There are a several reasons, some of them related to the way GPUs operate and others to the 3D API. So Microsoft set about solving the latter and working around the former.
First of all, threading the rendering process seems attractive at first, but when you look at it a little closer, you realize that, after all, there’s only one GPU (even when several of them are connected via SLI or CrossFire, their purpose is to create the illusion that there’s only a single, virtual GPU) and consequently only one command buffer. When a single resource is shared by several threads, mutual exclusion (mutex) is used to prevent several threads from writing commands simultaneously and stepping on each others’ feet. That means that all the advantages of using several threads are canceled out by the critical section, which serializes code. No API can solve this problem—it’s inherent in the way the CPU and GPU communicate. But Microsoft is offering an API that can try to work around it. Direct3D 11 introduces secondary command buffers that can be saved and used later.
So, each thread has a deferred context, where the commands written are recorded in a display list that can then be inserted into the main processing stream. Obviously, when a display list is called by the main thread (the “Execute” in the “Multi-threaded Submission” diagram below) it has to be ascertained that its thread has finished filling it. So there’s still synchronization, but this execution model at least allows some of the rendering work to be parallelized, even if the resulting acceleration won’t be ideal.
Another problem with the previous Direct3D versions had to do with creation of resources—textures, for example. In the current versions of the API (9 and 10), resource creation had to take place in the rendering thread. Developers got around the problem by creating a thread that read and decompressed the texture from the disk and filled the resource (the Direct3D object), which itself was created in the main thread.
But as you can see, a large share of the workload was still on the main thread, which was already overloaded. That doesn’t ensure good balance, needed for good execution times. So, Microsoft has introduced a new interface with Direct3D 11: a programmer can create one Device object per thread, which will be used to load resources. Synchronization within the functions of a Device is more finely managed than in Direct3D 10 and is much more economical with CPU time.
So, is the tesselation stage similar to AF or bi/trilinear filtering?
Tesselation, from what I've seen, takes a simple model intended for say a 4650 and "upgrades" it in memory making it more complicated and details for higher end cards. If I understand this correctly it will drastically reduce development time and costs while increasing visual quality.
Hmm, not sure about "upgrading" in memory. I looks like it just lets you pass in the control points that define your geometry rather than passing in all vertices for the mesh, which you yourself would probably have defined in a similar manner anyway.
Direct3D remains utterly irrelevant to me as a Linux user.
Direct3D remains utterly irrelevant to me as a Linux user.
But it is relevant to a lot of GNU/Linux users as the Wine programmers have to compatiblise what M$ implements in their 3D API... Currently they are making a dogs dinner of DirectX 9.0 support. However Windows games are generally well supported if they have an OpenGL option... Far Cry for example will not render under Wine in DirectX mode but when switched to OpenGL it works very well.
It is sad to hear about the difficulties OpenGL is having therefore.
Bob
Tessellation as far as I'm aware is adding more triangles to a model to give smoother surfaces over curves. It does not add any visual details but does add to the complexity of the model.
It breaks down the existing geometry into smaller triangles. (most 3d models are built out of triangles to begin with)
Very good aricle, thanks! I'm an OpenGL developer as well, and I wish it the best. I think that now, OpenGL needs money and commercial support - unfortunately these are the rights of current world. It would be a shame to have only one modern 3D API...
"the professional market, where OpenGL is the standard"
what market are you talking about? Please detail. Your readers are mostly common computer users, not specialsts knowing in-depth details about the computer graphics market.
"Since the ARB—the group in charge of ratifying the API’s development—included many different, competing companies.."
What are the most important members of this ARB? Whose words have big weight in that group? The readers might be curious - who are the people generating the conflicts that slow down the OpenGL evolution?
And by the way, why ATI and nVidia don't just take care about OpenGL and ignore that silly ARB? If they can't because of patents and such, they should make a new API from the scratch. Im pretty sure they are more than capable of it.
The problem with OpenGL is that industry users (e.g. CAD and scientific users) are opposed to change in the API which is blatantly against the ethos of the games development community. Industry users have already spent a lot of money on the OpenGL apps, so naturally they don't want the features they use to die. I think that what Khronos has done to date is the most logical route to take given the constraints they are working within.
The ideal solution would be to cut any ties that lead to a conflict of interest and pursue untainted API refreshes as they had originally promised.
As a cross-platform developer I want OpenGL to be a true competitor to D3D, I don't use anywhere near the full feature set of what current versions provide but if it looses at the top end, support will dwindle and the bottom end will also be affected.
If OpenGL even have a chance of competing against DirectX 10, then I'm more than impressed! OpenGL is the way to go for Linux and I and many others with me would like to use Linux as an gaming platform instead of Windows.
I'm very tired of using Windows and I don't like the operating system. It works, but it isn't very fun, unlike Linux which IS a enjoyable experience and feels fast even on old computer hardware, unlike Windows which never get the power it needs.