DirectX 9 December 2005 SDK available (Including Direct3D 10 December CTP)

J

JHoxley

Regular
Evening all...

The latest release of the SDK is now available: http://msdn.microsoft.com/directx/sdk/..

Of primary interest is likely to be the Direct3D 10 December 2005 Technology Preview. Direct3D 10 rocks, and if you want to know why then you best go download this SDK :D

Main SDK Download (~325mb), End User Runtimes (~47mb) and Symbol Files (~37mb)

This release of the Microsoft DirectX SDK includes the Direct3D 10 Technology Preview – an early pre-release showcasing the newest set of graphics API's for games and other high-performance multimedia applications on next-generation graphics hardware. This technology preview also provides reference material, conceptual content, developer libraries, tutorials and samples that demonstrate how to use Direct3D 10. Additional documentation, tools, API’s, samples, and other content will be provided in upcoming DirectX SDK releases.

Samples and applications built with the Direct3D 10 December 2005 Technology Preview require the Windows Vista operating system December 2005 Community Technology Preview (CTP) to run. The Windows Vista December 2005 CTP will be available to MSDN subscribers.

Instantiating a Direct3D 10 hardware device requires Direct3D 10-capable graphics hardware with a Windows Vista Display Driver Model (WDDM) driver. As of the release of this Technology Preview, such hardware is not publicly available. A software fallback (the Direct3D 10 Reference Rasterizer) is provided. Pre-rendered versions of Direct3D 10 samples have also been provided.
Click to expand...

However, note (emphasis mine) that you'll be needing the latest Windows Vista CTP to experience it... which might well be a sticking point for some.

Enjoy!
Jack
 
Very Nice. Although I have to say, some of the new HLSL syntax extensions look sloppy/ugly.

Since the HLSL compiler has finally been moved into the DLL, does this mean IHVs supplying device drivers can now plug in their own optimizer heuristics and code generation for the compiler (e.g. partially or fully override compiler backend), or is it still using assembly language output underneath (hidden from view)?
 
DemoCoder said:
Very Nice. Although I have to say, some of the new HLSL syntax extensions look sloppy/ugly.
Click to expand...
Any particular examples? I've not had enough spare time to dig into it recently in order to form a final opinion on whether or not I like it.

Also worth noting that (according to the release notes) there will be some API-syntax changes. Could well also mean some changes to HLSL.

DemoCoder said:
Since the HLSL compiler has finally been moved into the DLL, does this mean IHVs supplying device drivers can now plug in their own optimizer heuristics and code generation for the compiler (e.g. partially or fully override compiler backend), or is it still using assembly language output underneath (hidden from view)?
Click to expand...
You can still view the assembly code that the compiler produces, but it's more for sanity checking and debugging - you can't modify it and/or resubmit it.

The compiler will still be owned by the D3D runtime, I don't think theres any plans to move it (or allow it to be moved) to the driver. With the added verification of the compiler (it does create-time and linkage checking on semantics) as well as the drivers knowledge that any incoming assembly byte-code is from a reliable source it should still be able to do it's normal optimization tricks.

Given the IHV's track records with "optimizations" I'd rather they didn't get too close to the HLSL compiler ;)

Jack
 
I just downloaded it and I'm about to install it. It has been quite a while since I paid any attention to D3D and I was surprised to find the PIX performance tool.

Someone could have told me a few months ago that MS had already implemented a full D3D trace capturer tool :eek:.

From what the MSDN documentation says it seems like it already supports capturing and reproducing the full D3D command trace, included buffers. I wonder if someone has already reverse engineered the trace file (MS calls it run file).

If MS was so nice to give me the classes for reading back those trace files the development of the D3D framework for the simulator would speed up quite a lot :LOL:.

May be I will give a try and ask them.
 
RoOoBo said:
I just downloaded it and I'm about to install it. It has been quite a while since I paid any attention to D3D and I was surprised to find the PIX performance tool.
Click to expand...
There is no denying the fact that PIXfW rocks. I love the thing!

RoOoBo said:
Someone could have told me a few months ago that MS had already implemented a full D3D trace capturer tool :eek:.
Click to expand...
Don't have any dates to hand, but I think it's existed for over a year in one form or another :LOL:

RoOoBo said:
From what the MSDN documentation says it seems like it already supports capturing and reproducing the full D3D command trace, included buffers.
Click to expand...
Quite simply you can look at *everything* that happens with Direct3D whilst your application runs.

RoOoBo said:
I wonder if someone has already reverse engineered the trace file (MS calls it run file).

If MS was so nice to give me the classes for reading back those trace files the development of the D3D framework for the simulator would speed up quite a lot :LOL:.
Click to expand...
I'm a little confused as to what you're trying to do? you writing a simulator for the Direct3D pipeline?

Jack
 
We have written a GPU simulator. But we have only implemented the OpenGL framework. So now we want to start the D3D framework.

Framework:

+ trace capturer (GLInterceptor)
+ trace player (GLPLayer)
+ library (our own OpenGL library which internally is OO)
+ driver (should be generic for OGL or any other API, but currently is just some cover for the GPU low level commands and a limited memory manager)

The purpose of the framework is to capture high level 3D API commands from real applications (games) and translate them into low level GPU (simulated) commands.

In a CPU simulator you don't need all that complex stuff, at least if you are simulating an existing ISA, as you only need the compiled binary. But there are no binaries for GPUs.
 
Have you had a look at Muhammad's D3D hooking example? Sounds like it could do a lot of what you want.

If you do get a simulator for Direct3D running i'd be very interested. PIX is very much for performance (possibly debugging in the future), but an offline simulator for a class of Direct3D algorithms would be nice.

I can imagine coding a scenegraph and biasing it's weights/priorities and then seeing what difference it made by firing some test data at it. I can do a lot of analysis using PIX, but I'd imagine a full-blown simulator would be able to give much more detail.

Jack
 
JH, thank you very much for that link. Very very useful.

RoOoBo, is it easy to make a GL wrapper?
 
Last edited by a moderator:
Ages ago i started writing a program with associated hooks to intercept and records all the D3D Commands and buffers... oddly enough at exactly the same time Microsoft was developing the Windows version of PIX.

Linked in my sig a D3DBench. Also got the source available here if you want to have a peek: http://www.users.on.net/~triforce/d3dbenchsrc.zip (GPL License)

You can't do much with it, but it might be useful to see how it all works.
 
Last edited by a moderator:
Before I FUBAR my system by installing this - are the D3D10 docs/specs installable/viewable without having the Vista CTP? I'm on Win2000 Pro atm,
with a really crappy gfx card.

Cheers,
Serge
 
We were going to base the D3D capturer on Colourless D3DBench. I had asked him for the code when it was first released a year ago and he gave me the link below to the source, for which I thank him. The stall (we have been sitting on the D3DBench source for a year) is because the OpenGL framework wasn't anywhere near finished at that time and we didn't had anyone else that could work on D3D at the same time we were implementing the OpenGL framework.

At first we thought of just modifying D3DBench but now we are more into building our own capturer and use D3DBench just as a reference. We want to use the same automatic code generation approach that we used with the OpenGL capturer and prepare at the same time the implementation for D3D10.

Demirug, who has also implemented a D3D hooker, has been commenting me some of the issues that we will find too.

Of course if we could get MS to publish the format of their PIX run files we would save this work and we would have an up-to-date bug free capturing tool ;)

Mintmaster, what do you mean with a GL wrapper? D3D to GL? I doubt it is easier than implementing a D3D library from scratch, but just ask the guys from Transgaming, it's part of what they have been doing for running win32 games on Linux. Also I would personally want to avoid the artifacts produced by this artificial translation layer.

If you mean the GL capturer the fact that we still have problems correctly capturing traces from games using vertex arrays (vertex buffers are way more easy to capture) would prove that it isn't that easy to implement a good one. In any case I think the last version that is currently being finished seems that will solve the problem. Not that I have any interest on simulating Quake3 or older games anymore ... they aren't even good as embedded benchs anymore now that even embedded GPU are going to implement true shaders.
 
RoOobo, by wrapper I mean something to intercept GL calls and modify them if desired before sending them to the OpenGL driver. For example, creating a wrapper to allow NVidia demos to run on ATI hardware though a remapping of some functions.

I suppose for your purposes, though, GLTrace and GLInterceptor did exactly what you needed, so you didn't have to make many changes to the source code.
 
Mintmaster said:
RoOobo, by wrapper I mean something to intercept GL calls and modify them if desired before sending them to the OpenGL driver. For example, creating a wrapper to allow NVidia demos to run on ATI hardware though a remapping of some functions.

I suppose for your purposes, though, GLTrace and GLInterceptor did exactly what you needed, so you didn't have to make many changes to the source code.
Click to expand...

Because it's partially automatized and we also wanted to obtain statistics from the games without requiring to output a trace the framework is quite flexible right now. There is a new tool, that I haven't tested yet (I'm not the one implementing the OpenGL framework), that is like a reduced version of GLInterceptor that is used only for gathering statistics and instrumentation (GLInstrument). You only need to implement instrumentation code that is attached to the GL API calls that you want to analyze. I don't have the exact details at hand but I guess you could build the kind of wrapper you are asking for with this tool.

In any case if someone wanted to implement a stand alone wrapper it should be easier than implementating a trace capturer because you only need to pass most parameters to the real OpenGL dll, not interpret them and store the buffers. Of course you would have to implement the NVidia to ATI translator. Most of the complexity is in creating cover functions for the thousand of GL API calls. And that is what our automatic code generator does.
 
I'm having trouble figuring out something. If there are no more CAPS bits and D3D10 only supports SM 4.0 why the need for D3D10GetShaderVersion ?
 
You must log in or register to reply here.

Similar threads

P
GeForce Windows 10 Driver - 355.60 WHQL
Replies
3
Views
2K
pharma
P
L
LUXrender 1.5 available
Replies
0
Views
3K
lanek
L
N
DirectX 11
Replies
13
Views
2K
Demirug
D
L
Gamefest 2008 console edition
Replies
19
Views
7K
cullenskink
C
P
XNA Game Studio Express 1.0 and DirectX SDK December 2006
Replies
0
Views
3K
pcchen
P
Back
Top