Direct 3D 11

Re: C# and DirectX 11

mfc — Sat, 29 Aug 2009 08:23:20 GMT

Promit:
I also just noticed that the code pack as written only supports export interop, and not import interop. That is, you can get the internal pointer of a D3D11 object in the code pack to provide to something else, but you can't create a code pack object from an external pointer. (Yes, I made these terms up.) I don't think that this is an omission that affects very many people, and it is probably relatively easy to rectify if you don't mind dipping into the source. But SlimDX supports both export and interop, so it's just another way that the code pack falls short, albeit a minor one.

P.S. I have verified that all of the issues I mentioned are still valid in the latest code pack release, version 0.90. On the bright side, their Direct2D implementation at least uses value types for its structs. The D3D 11 code, however, has nothing that fixes these problems.

I have been using the code pack for a while now.

Actually, it does support both export and import interop. For import, just look for the "DirectHelpers" class. It's the first thing in their documentation file. They've probably separated the export in a different class, in order to separate the more advanced scenarios (i.e. interop with other wrappers), from the regular ones.

Also, I don't see the point about structs, as all of their native struct "wrappers" - at least the ones I've seen in D3D10, D3D11 and D2D - are managed value types.

By the way, I'm talking about v1.0 of the code pack.

Re: C# and DirectX 11

mfc — Sat, 29 Aug 2009 08:18:30 GMT

Promit:

The code pack, on the other hand, has some major problems that I noticed. First of all, all of the D3D 11 structs that it wraps are represented by a reference type that contains a pointer to a native type. Anytime you use or instantiate one of these, you get both a native and managed allocation -- that's TWO total which you pay for. Worse still, because they own unmanaged memory, they are all disposable and finalizable. Every time you work with one, you have to remember to dispose it or it will end up queued for finalization.

Then there's the problem that all of the functions and properties that return a managed object instantiate a NEW managed object. Worse still, this new object needs to be disposed separately or it will also end up queued for finalization. That means that if you access the same property get three times (say, DeviceChild.ParentDevice), you have three instances that need to be disposed now. SlimDX doesn't suffer this problem; you will get the same instance back every time.

I'm not sure what you mean in your comment about the need to finalize all D3D wrappers.
I guess you didn't really understand how the code wrappers work. From the library code and samples they have, the Windows API Code Pack does allow for both determinitic (via Dispose) and undeterminstic (via the garbage collector).
Basically, for every code pack wrapped DX COM interface, if a user doesn't keep a wrapper object alive; i.e. if it goes out of scope, it'll be automatically collected by the garbage collector, which will call the finalize method, which in turn "dispose" the object.
In addition, because the dispose pattern have the same code path as the finalzie method, the user can also dispose an object desterminitsically, i.e. use Dipose() or "using {}". So, the user DOES have the choice - unlike SlimDX where the user must call dispose every time.

And, apparently, you miss a point about the "slimness" of the managed wrappers, both the code pack and "Slim?"DX. In the native code, users will also need to get an object everytime they need the device child parent for example. However, the native API will not really create a new object, it'll just increment a reference counter. In SlimDX and Windows API Code Pack, the wrappers are so thin; they only have a reference to the internal native object, so I don't see the point at all in keeping a huge cache of objects, like what Slim DX does. If a user missed disposing some, that would be a BAD memory leak in my opinion.
As you've mentioned, managed code is supposed to make development easier - not more complicated.

Re: C# and DirectX 11

Charl van Deventer — Fri, 03 Jul 2009 15:37:59 GMT

As a followup, mangling XNA to support DX11 the way I needed to has given me a mark on my forehead.
Additionally, I've been somewhat distracted by the problem of tiling spherical planets with hexagons(aligned for triangular LoD) for a game concept I'm working on, but I'll likely return to this once I'm done with that. Hope at least my OP and Promit's input has been helpful to some people.

Re: C# and DirectX 11

legalize — Wed, 01 Jul 2009 02:12:44 GMT

I would be interested in contributing the remaining DirectWrite support needed. How would you like to proceed?

Re: C# and DirectX 11

MikePopoloski — Tue, 30 Jun 2009 15:31:45 GMT

Direct2D support is done, and has been for a while now (ever since we were able to grab headers for it, basically). We have DirectWrite support, but it's not complete, and nobody has asked for more so it's fallen on the priority list several times.

Re: C# and DirectX 11

legalize — Tue, 30 Jun 2009 14:57:33 GMT

Is anyone doing a wrapper around Direct2D and DirectWrite for SlimDX?

Re: C# and DirectX 11

Promit — Tue, 30 Jun 2009 05:01:26 GMT

I also just noticed that the code pack as written only supports export interop, and not import interop. That is, you can get the internal pointer of a D3D11 object in the code pack to provide to something else, but you can't create a code pack object from an external pointer. (Yes, I made these terms up.) I don't think that this is an omission that affects very many people, and it is probably relatively easy to rectify if you don't mind dipping into the source. But SlimDX supports both export and interop, so it's just another way that the code pack falls short, albeit a minor one.

P.S. I have verified that all of the issues I mentioned are still valid in the latest code pack release, version 0.90. On the bright side, their Direct2D implementation at least uses value types for its structs. The D3D 11 code, however, has nothing that fixes these problems.

Re: C# and DirectX 11

legalize — Tue, 30 Jun 2009 04:08:41 GMT

Thanks Promit for that detailed response. I had a feeling that this was going to be a nightmare as soon as I heard about it. MS would do better to endorse SlimDX instead of trying, once again, to make a managed API. I know they say this one (unlike Managed DirectX) will be open source, but that makes you really wonder why they are really doing it at all since SlimDX is already open source, debugged and working in the community. Whenever someone mentions managed code with DirectX, I always send them towards SlimDX, if only to eliminate that stupid "loader lock" problem with the debugger!

Re: C# and DirectX 11

Promit — Tue, 30 Jun 2009 03:30:29 GMT

I'm the lead author on SlimDX, and I was surprised by how many severe flaws the code pack seems to have. Keep in mind I am a biased source, but I've been doing this for a lot of years now and I'd like to think that I'm something resembling an authority on the matter. It's possible that I am wrong about what I'm about to say though, and I welcome dissent or discussion.

SlimDX's subversion code has full DirectX 11 support, as I detail in this blog post. It's built on our tried-and-true architecture, with fairly sophisticated debugging and leak tracking facilities. The memory management is also very effective, and it took us a lot of work to get right. I'm extremely confident that it's a very powerful and effective design. It's in use in multiple production environments and shipping with several products, so it's been run through the gauntlet quite a bit. Granted the DX11 code is new, but it's built on solid foundations. It will be available in built beta form with our next release, which is probably July 09 sometime.

The code pack, on the other hand, has some major problems that I noticed. First of all, all of the D3D 11 structs that it wraps are represented by a reference type that contains a pointer to a native type. Anytime you use or instantiate one of these, you get both a native and managed allocation -- that's TWO total which you pay for. Worse still, because they own unmanaged memory, they are all disposable and finalizable. Every time you work with one, you have to remember to dispose it or it will end up queued for finalization.

Then there's the problem that all of the functions and properties that return a managed object instantiate a NEW managed object. Worse still, this new object needs to be disposed separately or it will also end up queued for finalization. That means that if you access the same property get three times (say, DeviceChild.ParentDevice), you have three instances that need to be disposed now. SlimDX doesn't suffer this problem; you will get the same instance back every time.

The end result of these problems is that the code pack is basically a performance nightmare. Unless you write your code very carefully, with an unbelievable number of using statements, you're going to end up with very, very long lists of objects to finalize. It's true that they'll be cleaned up eventually, but it's going to create huge problems when it comes to garbage collection. That's a lot of allocations, which is going to mean rather frequent gen0 collections. And of course those collections won't be able to proceed properly until finalization of all those leaked objects happens. It looks like an unbelievable mess, to me.

Last but certainly not least, there's no math library in the code pack. Or any D3DX at all, for that matter. What are you going to do, reference XNA for just its math sections? Grab them out of SlimDX? It makes no sense. Last I checked, people use managed code to make their lives easier, not harder.

Re: C# and DirectX 11

legalize — Mon, 29 Jun 2009 20:39:01 GMT

Given that the XNA assemblies are going to directly reference D3D9, I'm not sure how you're going to be able to make this work.

C# and DirectX 11

Charl van Deventer — Mon, 29 Jun 2009 13:29:54 GMT

Lets start off with the state of the art when you want to develop Managed DirectX 11.

First of all, DirectX 11 HAS NOT been released yet. The technology preview has however been packaged with the DirectX 11 March 2009 SDK. There is a high possibility that it might still experience significant changes before it is released later this year, though the Technology Preview allows people to play around with it. DirectX 11 is a Superset of DirectX 10/10.1, supporting previous functionality while adding new features. It has been planned to be released with Windows 7, though a version for Vista will apparently be made available.

XNA does not and propably will not support DX10/10.1/11 anytime in the future. XNA is a development environment for both XBox and Windows, but DirectX 10 and 11 were both released after the 360. As such, the 360 hardware does not support DX 10/10.1/11.
It may change in the future that XNA may support later versions of DX, possibly with a Windows only target, but is unlikely and will impede programmers ability to port their games, so we will likely have to wait for a next generation XBox before DX11 support will be released.

Additionally, Managed DirectX has died a few years ago and since then XNA has been the ONLY Microsoft provided managed DirectX wrapper (till now, more on that later). This has resulted in a significant hurdle for enthusiast developers that want to get their hands dirty with newest technology, but also want to avoid getting their hands dirty with C++.

What can DirectX 11 do that DirectX 9 (XNA) cant??

Compute Shaders - GPGPU http://gpgpu.org/ - World has been in a GPGPU craze for the last few years, but this marks the year that both Microsoft and Khronos(the folks behind OpenGL) with OpenCL, are getting into it. What this means for game developers is offloading expensive parralizable computations like Physics, influence maps and water effects to the graphics card. In addition, performance benefits can be realised by offloading the generation of vertexes (particle systems, terrain) or textures to the GPU saves on memory bandwidth since you dont have to transfer them from system RAM. Not always a good idea for all games however, since games tend to be GPU limited with the CPU sitting idle. Doing these calculations will cost you frames and eat up more GPU memory, a concern esp for lower end cards. You dont need a DX 11 card to access many of the Compute Shaders features.
Tesselation - New DX11 cards will include a new hardware shader specifically for tesselation. In current generation games, there are often many different versions of the same model, high polygon for close, low polygon for far. Quick Tesselation will allow the artists to create only low polygon models, with detail stored as displacement maps. The hardware will tesselate the models for you, providing beautiful high detail models on the fly.
Shader Model 5.0 - Shader Model 4.0 was introduced with DX10, so XNA currently only supports Shader Model 3.0. This new shader model greatly increases the instructions at the Shader Writer's disposal. In addition, it allows you to play with whole new shaders, the Geometry Shader, Hull Shader, Tesselator, Domain Shader(The last 3 all deal with Tesselation) and Compute Shader. The possibilities and changes given by these new toys are beyond the scope of this post however.
Multi-threaded Rendering - Allows multiple threads to call the renderer, allowing such things such as one thread dealing with terrain, one thread with characters and one thread the GUI, with the SDK deciding how to serialize it. I am not entirely sold on this since the demo has quite noticable artifacts with my hardware, but as hardware and software improves this could grow to be the new way games are coded. At the very least, SDK improvements in asynchronous resource loading is worth a look.
Several other toys such as improvements for writing ubershaders and new texture formats.

The above is a non-exhaustive list, but is sufficient to make me drool over what is now possible.
Currently, in order to write C# DirectX 11 applications you need a wrapper. If you are like me and dont fancy writing your own, there are 2 notable contenders:

SlimDX http://slimdx.org/ - Currently the most fully featured wrapper you can get for C# DX, and comes with my stamp of approval. It was created by the community and does quite well from a performance standpoint as well. For best DX11 support however, I suggest you download the subversion repository version, since that part is in active development and is improved daily.
Windows 7 API Code Pack http://code.msdn.microsoft.com/WindowsAPICodePack - Return of Managed DirectX? Almost, but not quite. The Windows API Code Pack is a wrapper library developed by Microsoft itself. Its targetted at the upcoming Windows 7, though many of its features also work on Vista. It's still under heavy development so is anything but fully featured at the moment, but in addition to DirectX it provides access to much of Windows functionality such as the Taskbar, shell and explorer, as well as many of Microsoft's new APIs.

So? Where do I come in?
I love XNA, but I also love DirectX 11. In the next few days I'll be attempting to create a DX11/XNA hybrid experimentation project. The task is to allow XNA to render using the WindowsAPICodePack(because I like a challenge) WITHOUT throwing away many of XNA's features such as Avatars, animation and resource control, a task I'm not entirely sure is possible. I'll be giving updates on milestones in this project, real life permitting, and possibly create a tutorial out of it.

If there is anyone who has some experience with a task like this and has some hints or resources I should look at, I'm more than willing to listen.