D3d10 porting Thoughts

After a long time, we finally finished the d3d10 migration. The overall feeling is good, and the performance has improved a lot. Basically, there is a feeling that we don't want to go back to the chaotic d3d9 era. The new API is very streamlined and there is no redundancy, and the relationship between operations and performance is clear, fully fit with the hardware.

Of course, this also means that it is completely different from the design direction of d3d8 and 9, but a set of underlying APIs. In the early years, d3d apis were controversial. Most PC developers thought it was too low-layer and too difficult to use, A few people from the game host development background think that the abstraction level is too high to impede optimization (the game host's API should be more underlying ). Of course, PC developers' opinions form an overwhelming advantage, so d3d keeps moving toward ease of use, reaching its peak in versions 8 and 9, and even winning over OpenGL's reputation at a time. Unexpectedly, however, the rapid development of programmable pipelines has changed the direction forward, especially for top-level game manufacturers. Their Pursuit of performance and flexibility far exceeds ease of use. It is difficult for a set of APIs to meet different needs at the same time. At this time, OpenGL also encountered the same problem. game developers think that Gl APIs have been significantly different from today's hardware acceleration models and need to be adjusted and streamlined, while CAD developers think that they do not need them at all, compatibility is the most important. The result of N years of debate is divided into two profiles.

In this case, d3d10 is designed as a new underlying API for high-end users. In general, the demand for business 3D is met by high-level WPF, and the gap between the two is filled by xNa. Both WPF and xNa are based on. NET, while for d3d10, Microsoft does not even have official. Net packaging. This positioning also makes it very difficult to use d3d10. If it is not for top-level performance and flexibility, there is no need to waste your youth. In half a step back, Microsoft has worked hard on ease of use, in addition, xNa also makes sufficient preparations for the transition to the d3d10 architecture in the future (xNa is still cross-platform and supports windows, Xbox, Windows Phone 7, and Zune ).

As the underlying API, d3d10 is not suitable for writing the app directly-transform. No version of d3d is suitable for writing the app directly. every few years, the API becomes completely invisible, always wrap a layer. However, the packaging layer has to be changed because the change is too large. At the same time, the d3dx extension library is greatly reduced, and a large number of pre-processing functions are no longer available during design, while the d3d11 extension library has almost nothing left. Because high-end developers are not familiar with d3dx, they all have their own better implementations. Since d3d10 has been positioned as the underlying API for high-end development, there is no need to spend time maintaining a large d3dx. It takes a lot of effort to write these features again.

In the new architecture, there are only three core rendering APIs: the input stream (vertex data), the State object that is not programmable in the configuration pipeline, and the shader. The role of shader is greatly amplified, and Alpha test, clipping, and fog are all implemented by shader. Therefore, skillful use of shader is a prerequisite for upgrading to 10. It is best to convert all of these into shader implementation before the upgrade.

However, since d3d11 has been around for a long time, the 10 documents are still so thin. A lot of things should be tried out by yourself. For example, inputlayout must match the vertex shader input parameter, but it only needs to match the position with semantic. The vertex shader input parameter can be less than inputlayout. For example, if the current version of effect pool contains a non-shared cbuffer, the compilation is correct and an error occurs when the pool-dependent effect is loaded. For another example, does d3dx10filtertexture () process the staging texture or the texture in the video display, such as CPU processing or GPU processing? There is only samplerstate In the API, but there is a samplercomparisonstate In the shader that does not have a document but sample. For samplecmp family functions, samplercomparisonstate must also be used. One of the attributes in the sample document appears, during compilation, an error is reported indicating that this property does not exist ......

The biggest headache is device removed. Although there is no device lost, this is not only a temporary loss of control, but a direct loss of the device. It is not easy to debug it. You have to uninstall the video card driver and reinstall it. Alternatively, you can use a laptop with an independent video card to dock, connect to and disconnect it. What can the program do when the device is removed? Wait for a new available device to appear. One may be that there will be no more available devices, and the other may be that there is a different device with different capabilities. In the past, only reset was required for device loss, and the managed resources will be automatically restored. Now you can re-create the device and re-Initialize everything. Of course, removing a device is a low probability event. Who will update the video/card driver during the game? Of course, it is still possible to connect to the docking station, and the device removal event is also possible due to wrong internal resetting of the driver ......

Another major change in design direction is the separation of design and runtime. A large number of operations, such as the creation of State objects, the transfer of parameter structure ing links between stages in the pipeline, and the grouping of shader Parameters Based on the frequency of modification, must be made clear during design, it is executed during initialization, but not during runtime. The flexible, free, and obscure combination matching of d3d9 no longer exists. This has a significant impact on the engine architecture, meaning that the vertex buffer format is related to the shader. For example, the shader of a shadow map cannot be combined with vertex buffer of different formats.

An interesting discovery is that the d3d10 API not only inherits the features supported by the left and right hand series of d3d9, but also is closer to the right series. The descriptions of d3d10_box and other bodies are based on the axis direction of the right hand system. d3d10_rasterizer_desc also provides OpenGL-based cullmode and independent frontcounterclockwise parameters to define the positive winding direction of the plane. In the case that WPF and xNa both use the right hand system, it is also a matter of course that d3d turns to the right hand system. Of course, the texture coordinate system is still top-down rather than GL bottom-up. In fact, this is irrelevant to the left and right hand series. 3dsmax is the top-down texture coordinate, the top-down mode of 2D texture coordinates is quite in line with the 2D processing habits (it is better to say that the bottom-up texture coordinates of GL are a little more different ). 3D texture coordinates are based on the 2D coordinate system from X to Y, plus the Z in the depth direction forward, which is exactly the right hand system.

The debug information of 10 has greatly improved compared with the previous one, and its details exceed the document. However, it is hard to find out that to enable debug information output, you must not only create a debug layer, but also add the program path to the DX control panel. The debug information is output to the IDE output window. However, for a managed project, you must check the unmanaged code debugging option on the debug page of the project properties. For free Visual Studio Express, C # and VB do not have this option. You need to use other tools, such as debugviewnt.

Finally, I believe you will have this question. Why not upgrade it to d3d11 directly. I did think about this, but considering the difficulty, it would be too difficult to get involved. From 10 to 11 is relatively easy, and from 9 to 10 there are many problems. When debugging is very difficult, it is easier to solve problems one by one. On the other hand, it is not a long time before the 11 shopping holiday. There are not many video cards and few users. The solution is hard to find when there is a problem. In addition, Microsoft's attitude towards the 11 API is somewhat experimental, and it is better to "dare not be the first in the world.