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

[Humus]

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.

The base framework for something like that is fairly easy to get running. You could use GLTrace or GLIntercept as a starting point and go from there (GLTrace has less features, so it may be easier). Remapping stuff may be more complicated though.

 

[psurge]

DemoCoder - have to agree with you. Particularly weird is the syntax for [flatten] [branch] [loop] and [unroll].

 

[DemoCoder]

Yeah, I didn't like the "annotation" aspect. Why not just use new reserved words for unrolled loops and flattened branches? I also thought cbuffer/tbuffer awkward naming. Also, are the docs bugged? It says to use syntax like vector &<type, num>!?!? What's the & for?

 

[JHoxley]

Yeah, I didn't like the "annotation" aspect. Why not just use new reserved words for unrolled loops and flattened branches?

The release notes do say that the syntax is likely to change before final release. Could be worth dropping them a note directx@microsoft.com and see if they'll take it into account...

I also thought cbuffer/tbuffer awkward naming.

The cbuffer/tbuffer part keeps throwing me - I've been trying to get my head around it for months now. Each time I work it out I end up finding something else that confuses me.

Also, are the docs bugged? It says to use syntax like vector &<type, num>!?!? What's the & for?

It is a 'technical preview' remember - its not even a formal beta yet

Jack

 

[RoOoBo]

The base framework for something like that is fairly easy to get running. You could use GLTrace or GLIntercept as a starting point and go from there (GLTrace has less features, so it may be easier). Remapping stuff may be more complicated though.

GLTrace was what we used at first but later we decided to start from scratch using automatized code generation. We found too difficult to keep adding new API calls by hand and dumping buffers and textures were not supported and required major changes.

GLIntercept looks really interesting (our traces are text based too, but not xml) but we already had our own framework working by the time we noticed it.

 

[psurge]

DemoCoder - they also claim that & | etc.. are logical operators (should be bitwise, no?), and that &&= is left-shift equal. I suspect/hope the docs need a proof reading or two, because those operators would be confusing to say the least... BTW, if I do the full install do I get access to any low-level SM4.0 docs? The chm so kindly put online by RoOoBo references SM4.0 without ever really describing it....

Serge

As for annotations - they honestly look like an adhoc feature-add which somehow didn't get cleaned up. Even if they didn't wan't to introduce keywords, they could have used pragmas.

 

[ector]

The annotations look .NET inspired, it has a really nice attribute system where you can define your own attributes and attach to basically anything with a very similar syntax.

 

[DmitryKo]

if I do the full install do I get access to any low-level SM4.0 docs? The chm so kindly put online by RoOoBo references SM4.0 without ever really describing it....

I'd guess low-level model is not needed anymore, now that HLSL is the only way to program shaders. It would be of interest to hardware makers only, so maybe a future DDK will talk about it...

 

[JHoxley]

they also claim that & | etc.. are logical operators (should be bitwise, no?)

The information I have indicates they are bitwise operators (as expected). I've not found anything to indicate that they are actually logical - both high and low level coverage refers to them as bitwise... Guess that could be a mistake in the previews docs. Which page was it on?

I'd guess low-level model is not needed anymore, now that HLSL is the only way to program shaders. It would be of interest to hardware makers only, so maybe a future DDK will talk about it...

Quite possible - from the application side of things, the only contact with the assembly instructions is for debugging. Having said that, the low-level instruction reference could be useful when going over the compiled output.

Cheers,
Jack

 

[psurge]

JHoxley, go to Reference - HLSL Reference - Function Declaration Syntax - Statement Block Syntax. Then scroll down to the Bitwise operators section - there is a table there which lists them.

ector - my objection to the annotations in HLSL is that they aren't consistent - i.e. you have shader semantics, the flatten/unroll/loop stuff, and finally #pragma pack_matrix (or row_major, col_major keywords). IMO all of these things should be addressed with a consistent annotation syntax.

That said, I freely admit that I'm being nitpicky. I can't wait to get my hands on some DX10 HW .

Serge

 

[ector]

psurge, I didn't intend to defend the annotations, I'm just pointing out where the inspiration for them most likely comes from. I agree with you that they don't really fit in in HLSL

 

[JHoxley]

JHoxley, go to Reference - HLSL Reference - Function Declaration Syntax - Statement Block Syntax. Then scroll down to the Bitwise operators section - there is a table there which lists them.

Thanks for pointing that out.

In all fairness, it seems to be more of a "writing" issue than a technical one. Everywhere else in that same article it's "bitwise" - the only references to "logical" are in the table itself.

Jack

 

[DmitryKo]

http://www.gamedev.net/reference/programming/features/d3d10overview/
Excellent preview!

 

[JHoxley]

http://www.gamedev.net/reference/programming/features/d3d10overview/
Excellent preview!

Thanks

Time permitting, I'm going to try and add some "spin off" type articles focusing on individual areas.

Jack

 

[DmitryKo]

There's a February 2006 update already - has anything changed in regard to D3D10?

Considering SM4.0, I have a word that D3D10.h contains some definitions for the (unified?) assembly language:

4096 registers (temporary??!)
128 constants (??! less than SM3??!)
16 textures per shader (used to be no limits??!)
65536 instructions (or slots??!)
64 level nesting for loops
32 level nesting for subroutines
16 input registers for VS
32 input registers for PS
8 output registers for PS (render targets)

Looks like there are very slight changes comparing to SM3 ... Cannot confirm the numbers t as I have't downloaded the full SDK yet

 

[db]

corrections:

16 x 4096-element constant buffers
128 texture inputs
16 texture samplers (samplers are decoupled from bound textures)
shaders can be arbitrarily long, but 64K instructions is a pragmatic test limit

 

[JHoxley]

There's a February 2006 update already - has anything changed in regard to D3D10?

They've been feature complete for a while now (requirement of Windows Vista). I gather a few small things have changed...

I don't have all the details to hand, but there is some pretty cool new D3DX resource loading stuff in the Feb CTP. Makes use of the common "worker thread" multiprogramming model for loading resources. Should be a pretty neat "straight out of the box" toy :smile:

Considering SM4.0, I have a word that D3D10.h contains some definitions

d3d10.h contains loads of goodies

However, without the documentation and the functional specification they're not necessarily useful/meaningful...

Jack

 

[emacs]

other than downloading the SDK, is there another means to acquire the docs for Direct3D 10? thanks.

 

[JHoxley]

other than downloading the SDK, is there another means to acquire the docs for Direct3D 10? thanks.

No, you've gotta get them via the SDK. Strictly speaking any individual/website redistributing parts of the SDK is violating the EULA and is hence bad!

(not that doing illegal stuff with software seems to bother people in these parts )

Jack

 

[emacs]

No, you've gotta get them via the SDK. Strictly speaking any individual/website redistributing parts of the SDK is violating the EULA and is hence bad!

okay. i dont have any intention of coding anything at the moment; i just want to read the docs. i guess i'll grab the SDK at some point.