As nvidia doesn’t have Direct3D 10.1 compatible hardware yet it isn’t a surprise that PerfHUD doesn’t support this updated Version. This includes the case were the Direct3D 10.1 runtime is only used to create a 10.1 techlevel device. Therefore it is necessary to create Direct3D 10.0 devices with the Direct3D 10.0 runtime if you still want to use PerfHUD. This might not a big deal anyway as the same code is required if the application should run on Vista without installed Service Pack.

But there is another problem. If you use DXGI to enumerate over the adapters and pass them to D3D10CreateDevice1 to check if Direct3D 10.1 is supported you risk an access violation.

IDXGIAdapter* pAdapter;

int AdapterID = 0;

while (m_pFactory->EnumAdapters (AdapterID, &pAdapter) == S_OK)

{

      D3D10_DRIVER_TYPE driverType = D3D10_DRIVER_TYPE_HARDWARE;

      DXGI_ADAPTER_DESC Desc;

      if (pAdapter->GetDesc (&Desc) == S_OK &&

         (wcscmp(Desc.Description, L"NVIDIA PerfHUD") == 0))

        driverType = D3D10_DRIVER_TYPE_REFERENCE;

      ID3D10Device1* pDevice1 = NULL;

      //Expect this to crash if run with PerfHUD

      if (D3D10CreateDevice1 (pAdapter,

driverType,

NULL,

0,

D3D10_FEATURE_LEVEL_10_1,

D3D10_1_SDK_VERSION,

&pDevice1) == S_OK)

      {

            pDevice1->Release ();

            OnAdapterSupportD3D10_1 (pAdapter);

      }

      ID3D10Device* pDevice = NULL;

      if (D3D10CreateDevice  (pAdapter,

driverType,

NULL,

0,

D3D10_SDK_VERSION,

&pDevice) == S_OK)

      {

            pDevice->Release ();

            OnAdapterSupportD3D10 (pAdapter);

      }

AdapterID++;

}

As PerfHUD hook Direct3D 10 and DXGI the returned adapter interfaces differs from that one that an unhooked DXGI returns. The Direct3D 10.1 runtime assumes that the adapter interfaces are unmodified and therefore doesn’t check them very well.

An attempt to work around this limitation would be to ignore the PerfHUD adapter when it comes to the Dirtect3D 10.1 test creation.

IDXGIAdapter* pAdapter;

int AdapterID = 0;

while (m_pFactory->EnumAdapters (AdapterID, &pAdapter) == S_OK)

{

      D3D10_DRIVER_TYPE driverType = D3D10_DRIVER_TYPE_HARDWARE;

      DXGI_ADAPTER_DESC Desc;

      if (pAdapter->GetDesc (&Desc) == S_OK &&

         (wcscmp(Desc.Description, L"NVIDIA PerfHUD") == 0))

      {

        driverType = D3D10_DRIVER_TYPE_REFERENCE;

      }

      else

      {

            ID3D10Device1* pDevice1 = NULL;

            if (D3D10CreateDevice1 (pAdapter,

                                   driverType,

                                   NULL,

                                   0,

                                   D3D10_FEATURE_LEVEL_10_1,

                                   D3D10_1_SDK_VERSION,

                                   &pDevice1) == S_OK)

            {

                  pDevice1->Release ();

                  OnAdapterSupportD3D10_1 (pAdapter);

            }

      }

      ID3D10Device* pDevice = NULL;

      if (D3D10CreateDevice  (pAdapter,

driverType,

NULL,

0,

D3D10_SDK_VERSION,

&pDevice) == S_OK)

      {

            pDevice->Release ();

            OnAdapterSupportD3D10 (pAdapter);

      }

      AdapterID++;

}

But this would still crash at the same place. The reason for this is that PerfHUD modifies all adapter interfaces and not only add an additional one. This lead to a working solution

// Test all adapter once to look for PerfHUD

bool PerfHUD = false;

int AdapterID = 0;

IDXGIAdapter* pAdapter;

while (m_pFactory->EnumAdapters (AdapterID, &pAdapter) == S_OK)

{

      DXGI_ADAPTER_DESC Desc;

      if (pAdapter->GetDesc (&Desc) == S_OK &&

         (wcscmp(Desc.Description, L"NVIDIA PerfHUD") == 0))

        PerfHUD = true;

      pAdapter->Release();

      AdapterID++;

}

while (m_pFactory->EnumAdapters (AdapterID, &pAdapter) == S_OK)

{

      D3D10_DRIVER_TYPE driverType = D3D10_DRIVER_TYPE_HARDWARE;

      DXGI_ADAPTER_DESC Desc;

      if (pAdapter->GetDesc (&Desc) == S_OK &&

         (wcscmp(Desc.Description, L"NVIDIA PerfHUD") == 0))

      {

            driverType = D3D10_DRIVER_TYPE_REFERENCE;

      }

      If (!PerfHUD)

{

            ID3D10Device1* pDevice1 = NULL;

            if (D3D10CreateDevice1 (pAdapter,

                                   driverType,

                                   NULL,

                                   0,

                                   D3D10_FEATURE_LEVEL_10_1,

                                   D3D10_1_SDK_VERSION,

                                   &pDevice1) == S_OK)

            {

                  pDevice1->Release ();

                  OnAdapterSupportD3D10_1 (pAdapter);

            }

      }

      ID3D10Device* pDevice = NULL;

      if (D3D10CreateDevice  (pAdapter,

driverType,

NULL,

0,

D3D10_SDK_VERSION,

&pDevice) == S_OK)

      {

            pDevice->Release ();

            OnAdapterSupportD3D10 (pAdapter);

      }

      AdapterID++;

}

Finnaly don’t forget to remove all PerfHUD code in your release version if you don’t want that others can run your application with PerfHUD.

Time runs fast if you are busy. It’s is more than a month since my last entry and at least two months to wait for the next DirectX SDK.

In the mean time I am doing some work on my codeplex project. The biggest hole is still the Direct3D9 part but it gets some updates lately. But I am although adding some code for Direct3D9Ex and the upcoming Direct3D 10.1.

An interesting aspect of Direct3D 10.1 is that you can create a D3D10.1 device even on Direct3D 10.0 Hardware. The new functions will not work and therefore we got some kind of a caps system back. But instead of many bits and values there is only a global enumerator. The D3D10_FEATURE_LEVEL1 value that need to provided during device creation  select the feature set .

Currently there are two values: D3D10_FEATURE_LEVEL_10_0 and D3D10_FEATURE_LEVEL_10_1. There is no D3D10_FEATURE_LEVEL_9_0 but from the technical point of view it would not impossible to write a Direct3D 10 runtime that works with older Direct3D 9 level hardware. It need to provide an additional interface to query the caps but beside of this it would simplify the development of applications that need to scale over a large  range of GPUs. But to make it useful this runtime need to be part of the redistributable DirectX components and work on Windows XP too.

I don’t expect such a solution from Microsoft but as it could build on top of Direct3D it can be done as an community project. 

Update: I was wrong.

You, only you.

This answer sounds strange as in the world of COM reference counting there can be more than one single owner. With Direct3D 9 the device becomes a second owner of your texture as soon as you call SetTexture. You may already read that this is not longer true for Direct3D 10. For nearly every application this change would make no difference as they hold a reference to the resources anyway.

But with Direct3D 10 most times you assign a view instead of a resource to the pipeline. This could lead to the idea to keep only a pointer to the view and not to the resource itself. Especial in the case when the resource is immutable.

You may use code like this one:

Device->CreateTexture2D (… , &pTex);
Device->CreateShaderResourceView (pTex, NULL, &m_pView);
pTex->Release ();

It locks right but as soon as you assign this view to the device strange things would start to happen. The reason for this is that the Release call destroy your texture as the view doesn’t add a reference during creation. But the view will still point to the now invalid texture resource. Maybe the pointer becomes valid again after you create another texture. But even if this happen the result on the screen will not be the expected. To avoid this you should never ever release a resource as long as there is a view attached to it.

But this behavior of the view objects could hit you on another place, too. There are three D3DX10CreateShaderResourceViewFrom methods that give you a newly created shader resource view. As this view haven’t call AddRef for the resource it contains it will not call Release for it during its own destruction. Therefore you would have leaked a resource when you only release the view. Instead you have to do the following.

ID3D10Resource* pRes;
pView->GetResource (&pRes);
pRes->Release(); // GetResource have called AddRef.
pView->Release ();
pRes->Release();

You can use the same code if you want to store only the view of your own created resources. But it could be tricky to remember which view can be released direct and which one need this special handling.

But even if I got some Direct3D 10 applications working it would, as any other wrapper project, never a 100% replacement for the original Direct3D 10 on Vista. With every new D3D10 game it could fail again. The original version would never have such problems as this games we developed used it. Another problem would be the mapping of functions that have no OpenGL counterpart. And finally as any other emulation layer it would need some CPU time. Therefore a CPU limited application would possibly run faster with the original.

A blog entry from Cody Brocious about the Alky Project this week had let me think again about the possibility to run Direct3D 10 games on Windows XP. Some euphoric people have already called this a world saver or something like this. I am although have read comments that call this solution a back port. Something that many people had said is not possible at all. First of all this is not a back port it is an wrapper or to more exact an Direct3D API to OpenGL API translation layer. You may ask why something that could run D3D10 applications is not a back port. Well it may or may not run applications that make use of the D3D10 API but you still can’t use Direct3D 10 GPU drivers on other systems than Windows Vista. A full back port would required this and as I had written before this would requires a huge amount of work that is practical impossible for someone outside Microsoft. Maybe this Windows clone ReactOS would someday handle Windows Vista drivers but this would not made Direct3D 10 games playable on Windows XP.

You may say I should go away with this technical stuff as you only want your Direct3D 10 applications run on Windows XP and these guys will made it possible for you. They even talk about the unnecessary to update your video hardware. All this for only $50 that you have to pay to become a member of their Sapling Program. Doesn’t this remember on the bussines model of Cedega? Well Transgaming Technologies want $5 per month and I haven’t see any word about Direct3D 10 but at least you get more than simple promises for your money.

Talking about promises get us to the question: “Could the Alky Project successful?”

It is not impossible but in its current state this software is far away from giving you bank for your bucks. Not a single Direct3D 10 application I tried with it works correct. Most of them doesn’t even start at all. The rest produce not the correct visible result. Many Direct3D(X) 10 entry points are missing and even the functions that work are only stubs. Somebody mention in the comments to their blog entry that the wrapper use only the fixed function OpenGL pipeline and doesn’t care about the shader code. I don’t know how long they have need to put this together but hopefully not that long. Anyway I don’t expect that they are ready when the first game with Direct3D 10 support hit the shelf.

Does this mean that all hope is gone? Well the Wine team has started working on Direct3D 10, too. But natural they are focusing on Linux and their summer of code is more about building the basic infra structure. But with this there are only one step behind the Alky Project. Well anybody who starts with a Direct3D 10 to OpenGL wrapper today is only one step behind.

With at least two projects on the way we could though that the future of Windows XP gaming looks bright. But how long would it take until these approaches can show us some real results like running a game like it was meant on Windows XP instead of Windows Vista?

I don’t know the answer and therefore I had to wait and see.

After the April SDK still doesn’t contain a piece of a managed Direct3D 10 I decide to update my own solution again.  If you look at the new assembly you may notice that there is a Direct3D 9 namespace, too. The code behind this is not ready to use for more than simple device enumeration but I was too lazy to remove it from this build.

In comparison to Direct3D 9 there is no general object for hardware enumeration in Direct3D 10. But Vista supports another API for this purpose. DirectX Graphics Infrastructure (DXGI) is the way to go. This short example shows how to use DXGI to look for a Direct3D 10 compatible graphics adapter.

     IDXGIFactory* pDXGIFactory; 

      HRESULT hr = CreateDXGIFactory (__uuidof(IDXGIFactory), (void**)&pDXGIFactory);

      if (hr != S_OK) 
            return -1;

      int AdapterIndex = 0;

      IDXGIAdapter* pAdapter;

      // Loop as long as DXGI returns valid adapters.

      while (pDXGIFactory->EnumAdapters (AdapterIndex, &pAdapter) == S_OK) 
      { 
            DXGI_ADAPTER_DESC AdapterDesc; 

            if (pAdapter->GetDesc (&AdapterDesc) != S_OK) 
                  continue; 

            std::wcout << L"Name:                    " << AdapterDesc.Description << "\n\r"; 
            std::wcout << L"D3D10 support:           "; 

            LARGE_INTEGER version; 

            if (pAdapter->CheckInterfaceSupport (__uuidof (ID3D10Device), &version) != S_OK)
                  std::wcout << L"NO\n\r"; 
            else 
                  std::wcout << L"YES\n\r"; 

            pAdapter->Release (); // Don't forget to release when you are done 
            AdapterIndex++; 
      } 

      pDXGIFactory->Release ();

Be aware that the key method CheckInterfaceSupport will not work with interface GUIDs of older Direct3D version.

Another week another Vista build (5728-16387 to be exact) and as the original RC1 build it is public available. But as with other builds beside the big releases (Beta 2; RC 1) Direct3D 10 is out of Sync again. Fortunately I haven’t override my RC 1 installation with this new build.

But this is something I could life with but the WDK (Windows Driver Kit) updates that are released with every new Vista build too starts to make me angry. As I want to make my SSE D3D10 software device compatible to the IDXGIFactory::CreateSoftwareAdapter method I need the WDK that contains the driver interfaces that the D3D10 runtime use to talk with a driver. Software devices are nothing else than D3D10 User Mode driver that although “emulates” the kernel mode part of the driver.

I haven’t counted the number of WDK updates but every time it’s the same game. The necessary D3D10 headers are still missing and the documentation is crap. Therefore I could not work on the SSE Software device and the same is partial true for the D3D10 to D3D9 layer.

I am really hope they include this headers real soon.

Beside of these downs at least the managed D3D10 layer is near finalization but October and a new SDK is near. Maybe the API is already stable and we will not see any future changes.

Last night I spend some time on my managed layer for Direct3D 10. It’s nearly complete and therefore I start playing with some advanced features. One thing I never really like since Direct3D 9 was the need to define your vertex structure twice. One time for the compiler and then for Direct3D again. It’s still the same for D3D10. The name has changed from vertex declaration to input layout. Some other details have changed too but the pain to do it twice is still there.

C++:

struct SimpleVertex

{

    D3DXVECTOR3 Pos; 

    D3DXVECTOR4 Color;

};

To create and set the input layout for this structure the following code is necessary.

// Define the input layout

D3D10_INPUT_ELEMENT_DESC layout[] =

{

    { "POSITION", 0, DXGI_FORMAT_R32G32B32_FLOAT, 0, 0, D3D10_INPUT_PER_VERTEX_DATA, 0 }, 

    { "COLOR", 0, DXGI_FORMAT_R32G32B32A32_FLOAT, 0, 12, D3D10_INPUT_PER_VERTEX_DATA, 0 },

};

UINT numElements = sizeof(layout)/sizeof(layout[0]);

// Create the input layout

D3D10_PASS_DESC PassDesc;

g_pTechnique->GetPassByIndex( 0 )->GetDesc( &PassDesc );

hr = g_pd3dDevice->CreateInputLayout( layout, numElements, PassDesc.pIAInputSignature, PassDesc.IAInputSignatureSize, &g_pVertexLayout );

if( FAILED(hr) )

    return hr;

// Set the input layout

g_pd3dDevice->IASetInputLayout( g_pVertexLayout );

This can easily be ported to C#:

struct SimpleVertex

{

    public SimpleVertex(DXGI.R32G32B32Float position, DXGI.R32G32B32A32Float color)

    {

        this.position = position;

        this.color = color;

    }

    DXGI.R32G32B32Float position;

    DXGI.R32G32B32A32Float color;

}

// Define the input layout

D3D10.InputElement[] layout = new D3D10.InputElement[]

{

    new D3D10.InputElement ("position", 0, DXGI.Format.R32G32B32Float, 0, 0, D3D10.InputClassification.PerVertexData, 0),

    new D3D10.InputElement ("color", 0, DXGI.Format.R32G32B32A32Float, 0, 12, D3D10.InputClassification.PerVertexData, 0)

};

// Create the input layout

inputLayout = new D3D10.InputLayout(device, layout, technique.Passes[0].InputAssemblerSignature);

// Set the input layout

device.InputAssembler.InputLayout = inputLayout;

Clever usage of propertys save some lines of code but the main problem is still the same. Let’s add some reflection magic.

// Create the input layout

inputLayout = new D3D10.InputLayout(device, typeof(SimpleVertex), technique.Passes[0].InputAssemblerSignature);

// Set the input layout

device.InputAssembler.InputLayout = inputLayout;

This new construtor I add last night use reflection to analyse the vertex structure and create the nessary layout on the fly. If you change the structure the layout will be automatically in sync.

Finally most people that have something to do with whole GPU stuff should hear the message “No Direct3D 10 for Windows XP”. No surprise after so many news sides has spread the word. After the first wave of curses against Microsoft some people starts to believe in “The smart guys” that will magical bring Direct3D 10 to Windows XP. Maybe some remembers that Direct3D does not work with Windows NT but these smart guys solve the problem and we don’t need to buy Windows 2000 with the new driver model that was needed for Direct3D. But wait a minute. Let’s remember what this “hack” had done. It allows you to use the Direct3D runtime and the software devices but you were still not able to install a new Windows 2000 driver on Windows NT to get full hardware accelerate 3D. Today a software device would not be an option for a whole game. More work for our smart guys but we still believe in them.

Let’s look at the way Direct3D will be distributed. It will be part of Vista and is contained in some DLLs. Nice! Just let us copy these files to a XP system and we will have Direct3D 10 there. At first this is not legal but let us ignore this for a moment and try to start a Direct3D 10 application (only as experiment in our mind). It will not work and using your favorite DLL dependency viewer will tell you why. The Direct3D 10 runtime is linked against a Visual C runtime that was linked against versions of system DLLs that contains function that only exist on Vista. So there will be no lucky user with a simple file transfer. But as our guys are really smart they can use the Direct3D 10 documentation and implement the whole runtime for Windows XP. As the shader compiler and the effect framework are now part of the core this will take some time and will only lead to the next problem.

Implementing the user mode part of Direct3D 10 only solve half of the problems. There is another runtime in the kernel. But as we already have gone that far we can implement this piece of software too. The WDK will be our friend and tell us how. Another huge amount of time pass away but finally Windows XP will load Vista drivers and the screen went black. Unfortunately the new driver model does not only change the rules for Direct3D it changes them for the GDI too. Without a working GDI most Windows applications will not work. And the desktop is an application too.

Let’s implement a new GDI for Windows XP that can work with a Vista driver and hopefully we can work with our XP again. But gaming would be a little hard. Sure we had a running Direct3D 10 now but there are still many games that use older versions of Direct3D, DirectDraw or OpenGL. Some more runtimes that need to be written form someone for XP again.

In the end the “smart guys” we believe in have to touch every single part of Windows XP that has something to do with graphics. If they are such smart to do this without any help from Microsoft they should be smart enough to not waste their time with this.

But there is still some hope for some kind of Direct3D 10 for Windows XP. Looking over to some other smart guys that prefer to use Linux and try to solve the gaming problem there. Both Wine and Cedega provides DirectX support for Linux. Unfortunately it is still limited but I am sure that somewhere in the future they will support anything that the original version supports today. At the same time they offer Direct3D 10 for Linux the necessary code should be portable to Windows XP. The only question left is: How many people will still use Windows XP at this time?

Warning: Could contain rants.

Many people are angry that there will be no Direct3D 10 for Windows XP. I have heard more than one time that the decision making Direct3D 10 exclusive for Vista was only made to force players to upgrade as Vista will not give them any advanced beside. That’s the user side of the decision but what are about us developers?

Using only Direct3D 10 will cut not only the whole XP user base at the moment it will cut the whole user base at all. Nobody (maybe some lucky guys who work for ATI or nVidia are exceptions) have Direct3D 10 hardware at the moment and even after the launch of Vista the User base with the right GPU will be small. Isn’t this is clear stop sign for everybody who want to use Direct3D 10? It is for sure as long as your competitor doesn’t drive through and sell their newest game with “Direct3D 10 effects”. If you don’t have this effects game tester will write that your game is not “visual up to date” anymore.

At this moment the missing compatibility bites you. You have to add Direct3D 10 support to get good test results but you can’t drop Direct3D 9 support because there will be simply to much users without the right hardware or operating system to run Direct3D 10. I am not sure how many developers believe that Direct3D will always take same way of one API for every GPU out there. But everybody who does could possible face same hard work in the near feature. Migrate from a monolithic engine that was bind to only one API to a Multi API design would need some time.

I am sure that most developers are not very satisfied with this situation. I am like clean cuts that generate new grounds to start from. But this is more like building new roads where no current car can drive. Microsoft should avoid building such situations that make game developers life harder. Particularly after the have recognized that playing games is in the top 3 how people use their computers.

The XBox team found a way to make sure that games from the first XBox runs on the new too. Why can’t the responsible Windows team not offer a solution to use only one API for most 3D hardware out there? A solution that give the developers access to the newest GPU technologies but stay compatible with older. I was never a friend of the OpenGL extension system but at this point it can play its advantages.

Anyway it could have been so easy. Building an additional version of Direct3D 10 that use the same base concepts and interfaces but works with Direct3D 9 drivers. Adding an additional interface that allows checking caps that can be access with a simple QueryInterface call. Call this Direct3D 10 version the “capsed” and the version we now have the “pure” one. The could even put in only in the SDK as some kind of extension like D3DX. Developers out there will be more willing to migrate to the Direct3D 10 interfaces and will starting to build effects that require real Direct3D 10 GPUs and therefore Vista.

You may have noticed that one of my Direct3D projects on the list is such a migration helper but it would be much better if something like this comes from Microsoft with full official support. This way more people would know about it and could save themselves from the Direct3D 10 migration hell.

Someone may ask why I am working on a software device for Direct3D 10 when there is already the reference rastierizer and real hardware around the corner. This question is not that easy to answer but one of the primary motivations was the technical challenge. But this alone was not enough to fire up my compiler and write some code. The annoying slowness of RefRast was another brick in the wall. But finally the motivation comes from the idea to use Direct3D 10 for every kind of SIMD processor. As modern multicore CPUs are SIMD processors too it was natural for me to start there.

This leads to the next question. Why would someone use Direct3D 10 to make use of the CPU power? Well multicore and SSE programming is something that not everyone want to do. But nearly every graphics programmer out there know how to write code for a SIMD processor using an 3D API and shaders. Sure we have OpenMP and the SSE output from the different compilers is getting better too. But it doesn’t solve the load-balancing problem. PCs are individual configured and we never know were we can find some additional calculation power. Having a common API for every device in the system that can do SIMD math would let us move the SIMD calculations to any place without changing the code.

But hasn’t show us RefRast that the CPU is to slow to handle Direct3D 10 in a fast way. No it hasn’t. RefRast shows that is is possible to write a slow software emulation of a Direct3D 10 GPU. RefRast was build to be correct and act as a development tool it was never build to be fast. Think about shader programs as byte code like Java or .Net use. Java was not very fast as long as the byte code was interpreted but a JIT compiler can do wonders. The same is true for shader model 4 shaders and with the new Direct3D 10 features like stream out we don’t even have to pay for the rasterisation if we don’t need it.

Maybe I am wrong as many developers fears to lose direct control but for anybody who is willing to allow an additional layer between the program and the CPU a Direct3D 10 software device could be a useful extensions for the toolbox.

Ralf