PTaylor's WebLog : D3D10

Friday the 13th is here, and so is the 2nd FSX-DX10 progress report

Phil Taylor — Fri, 13 Jul 2007 23:21:00 GMT

With this blog post, I have likely run out of snarky dates to make a post on. Ides of August anyone? J. So on with the show

First, this is not the FSX-DX10 feature discussion. Nor is this the “what will be in the DX10 release for DX9 users” discussion. Why not you ask? Because that work is still in flight. And we could still find something that would necessitate us dropping a feature or fix before the final FSX-DX10 release. My current plan is to make a feature disclosure post in public in mid-August when we should know with much more certainty what DX10 features will ship and what fixes we can fit in around the edges.

How could it be possible that we don’t know what we are doing? Well, that’s a bit of a strong interpretation. Of course we have a plan. But like the old saying “no battle plan survives contact with the enemy”; software project management has the same issue. Events happen and require adjustments to the plan. Some are minor, and are akin to tacking a sailing ship down a course. Some are major and are equivalent to having sails blow out and losing the lead. You just cannot predict; and with that being true I tend to remain conservative in what I say to not build any false expectations.

So what can I say? I can talk to the general organization of the project so you get a sense of what needs to be done and where we are. And a 2^nd set of screenshots.

Practically speaking, we broke the work into 4 phases:
1)Device and Infrastructure bring-up
2)Geometry Pipeline bring-up
3)Pixel Pipeline bring-up to "rough DX9-level comparability"
4)DX10-specific feature work.

The 1st 2 phases had to happen before the last 2 phases could even start. And the 1^st public post on FSX-DX10, roughly 3 weeks ago, showed we had essentially finished those phases.

The last 2 phases, though, can be done somewhat in parallel once enough of the Pixel Pipeline is operational for a specific feature. Because we are doing things in parallel; while that does provide the opportunity to speed up the work - it also introduces risk that integration of the features together will show something unexpected. So that is how we could have a feature that looks pretty good now, but might not make it later. And why I want to remain conservative and not show my feature cards yet. J.

Why does it work that way? We have a tight timeframe to make our Fall release schedule and move off onto the next set of projects. And we dont want to mis-set expectations.

So now on to what I can report at this time.

We have some progress on the Pixel Pipeline. Okay, okay, maybe that was too obvious. J.

Here is some more detail.

The first thing we did was bring up what we call the “fallback material” which gave us a solid color for every triangle, here.

So what is next? Well, textures, materials/shaders, and effects. D3D10 changed the texture formats, so we have to write conversion code to swizzle the textures on the fly. That means each and every texture format requires code to be touched. Except for DTXn textures. So that was the first to be brought up, what we call the basemap, here. So you can start to see some definition in the world, but lots of objects are still black rectangles.

Is that it? No, we actually have swizzled texture formats working; but they still require material/shader and effect support to reach DX9-level visuals and thus appear a bit flat. Here is a shot off the edge of the Trike, showing ground textures, tree textures, the sky, and gauges. And a VC shot here. Note a couple of things that highlight the lack of shader and effect support. The edges of the rectangles around the tree textures show black – lack of alpha material support for transparency. The sky shows the stars as black dots, again lack of material/shader support. And all the cockpit materials aren’t working as the lack of glare across the bar and the lack of alpha in the windscreen shows. Here is another cockpit shot, and it looks similarly flat; an indicator the textures are there but not the shaders/materials.

No more? Just a final shot in multi-mon mode, to show the value of the infrastructure bring-up.

Unimpressive looking overall in general, unless you map it to the plan I outlined above with its phases and use that to gauge our progress. So we are making good, steady progress since we came off SP1 roughly 2 months ago.

To set expectations, I may or may not make one more interim screenshot post like this before talking features. The current plan is to have that discussion in mid-August, but that discussion could always slip to early September as there is a lot more to be done before any feature is "final" and "committed".

I hope that makes sense. And now, perhaps, the pacing of progress reports make sense too.

Sorry to be long-winded. I hope this is useful.

DX10 on XP: Round 2

Phil Taylor — Thu, 28 Jun 2007 23:11:00 GMT

Today on AVSim.com, in this thread http://forums.avsim.net/dcboard.php?az=show_mesg&forum=121&topic_id=406460&mesg_id=406460&page= the “DX10 on XP” issue came up again, with renewed discussion about what FallingLeafSystems is doing.

I covered this in Feb 2007 in my blog at http://blogs.msdn.com/ptaylor/archive/2007/02/14/why-dx10-wasnt-created-on-xp-and-why-it-isnt-in-xp.aspx, and before me David Weller, DirectX Community Lead discussed this on his blog at http://letskilldave.com/archive/2006/10/17/DirectX-10-for-Windows-XP_3F00_--Repeat-after-me_3A00_-No.-No.-No_2E00_.aspx back in October 2006.

However, that seems to not have been enough debunking. So I took a look at this again and investigated in some detail what is actually available in the FallingLeafSystems release, and what the limits of the possible are on XP.

FallingLeafSystems is claiming to enable DX10 on XP, and further, to quote the AlkyProject blog at http://alkyproject.blogspot.com/2007/04/finally-making-use-of-this-blog-i.html “No longer will you have to upgrade your OS and video card(s) to play the latest games”.

So they are claiming to make DX10 work without DX10 hardware.

Holy schmoly Batman, can they make that work?

Not at all.

And I will show why with just a few off-the-cuff comments based on reading their web site and readme documentation, and reading a few other sites and documents – no detailed code analysis is required.

The FallingLeafSystems approach is to write a wrapper around the OpenGL extensions for DX10 class hardware that are already available on XP. And to claim this can work without proper hardware.

That by itself means this isn’t some monumental hack, but merely some clever coding ala the Quake on D3D demo we did years ago.

No reverse engineering of DX10 is involved. What is involved is eyeballing the D3D10 API and mapping those calls to their OGL equivalent. For reference, an intern wrote the QuakeD3D wrapper.

On to details.

The coverage of D3DX is limited to 1 version, so only games compiled against D3DX10_33.DLL have a chance of working. There are at least 15 versions of that DLL, and if you don’t have the full set, then some games just plain wont load at all with a "DLL not found" error. That is a wonderful user experience isn’t it? Not!

The coverage of the DX SDK is weak. Right now the readme recommends running 1 tutorial out of how many? And admits there are lots of issues with the tutorials, much less the samples. That indicates how much work is left to complete this, but more on that later.

Then there is the wrapper performance cost and wrapper functionality issue raised by MauiHawk in the AVSim thread.

So let us take a moment to consider those two issues.

Once someone benches this, we will see what the basic performance cost is, ignoring new features. Last I looked, OpenGL required an extra copy of textures in memory, so there used to be some inefficiencies in the OGL stack as well. And just the extra call, which flushes the I-cache on the CPU, exacts some cost.

So this is sure to exact some performance cost in the best case, where DX10 hardware is available and thus the features map 1:1.

What about where there is not DX10-class hardware? How does that work?

Not so well. And let me show why.

The blog posts mentions running Geometry Shader code on the CPU if there is no GS unit. That is going to be a dog, and is contrary to the purpose and existence of the GS unit.. One key purpose of the GS unit is to be able to emit vertices on the far side of the bus, to enhance geometry without CPU intervention. Bye-bye to that feature. Another key feature of the GS unit is to be able to generate all 6 faces of a CubeMap texture ( used for perfect reflections amongst other effects ) in 1 pass instead of the 6 it takes today. Bye-Bye to that feature.

One poster on the FallingLeafSystems forums notes there is no shader support in the initial release. If that is true the initial code value is low and the remaining work is large. How does one take unlimited shaders and 16x4k constant buffers and map those to 1k shaders ( SM 3.0, SM 2.0 is even more restrictive and that’s all the 1st generation of DX9 cards can do ) and

256 constants? Inquiring minds want to know. http://static.tigerdirect.com/pdf/NVIDIA_Microsoft_DirectX-10_Technical_Brief.pdf talks to the vastly expanded resource limits for DX10, and

http://www.behardware.com/articles/631-2/directx-10-and-gpus.html has a great table that shows some of the resource limit changes I am talking to; for those of you who want to see how challenging this will be.

Another key feature of DX10 hw is that FP16 floating point formats are filterable. Not having filtering on HDR textures meant huge artifact problems in DX9. So it’s unclear how that feature maps to DX9 hw without an obvious quality disadvantage independent of the obvious performance issues.

I haven’t exhausted the DX10 feature list yet, just picked off three features off the top of my head. So you had better have DX10 class hw or else this wrapper won’t run very well at all.

I can keep going.

A couple key parts of the Vista kernel-WDDM driver work are GPU interruptability and GPU memory management. Yes, in Vista the OS is managing the GPU to make applications play nice, as opposed to the DX9 style "last application in owns the card" style. And 10.1 and 10.2 will expand on those capabilities with more fine-grained interruptability and GPU memory paging behaviors. It seems pretty clear from this article on the OpenGL.org site at http://www.opengl.org/pipeline/article/vol003_9/ that without WDDM you don’t get those features, which is what I have been saying all along about DX10 and Vista. Nice to see it confirmed by the OpenGL people J.

And there are others questioning this work, even on FallingLeafSystems's own forums, see http://www.fallingleafsystems.com/forum/index.php?showtopic=53 and these include WINE developers who are some of the most knowledgeable about cross system emulation.

So there is a lot of work left to do before this is anything like ready for prime time. And it should be pretty clear that without DX10 class hardware this approach is doomed to failure. So that limits it out of the box.

This quick analysis partly validates what I said back in Feb 2007. The OpenGL.org page validates more of what I said.

Clever hack, maybe. Godsend for XP, unlikely due to so many compromises. End of the world and time to sell MS stock, not at all.

I still stand by the fact that full DX10 support requires Vista. There is no such thing as a free lunch.

Summer is here, and so is the start of info about FSX-DX10

Phil Taylor — Thu, 21 Jun 2007 21:22:00 GMT

So it’s the first day of summer! As part of the celebration, I wanted to talk about and show progress on FSX-DX10.

First, though, let’s talk what I can show and when, as well as requirements for FSX-DX10.

I am not here to talk features. Not yet anyways. I am going to show progress on bringing the engine up on the DX10 pipeline before I talk features. So there are going to be 2 to 3 posts on progress before talking to FSX-DX10 specific features. Expect those every 2-3 weeks until mid-August or so, when I can take our famous screenshots, deconstruct them, and talk to features. Ok?

Now, what does FSX-DX10 require? First - Vista, a DX10 graphics card, and a DX10 driver. Second - FSX and SP1. Yes, SP1is a pre-req. More on that in a later post.

On to where we are with FSX-DX10.

We have all FSX geometry going thru the DX10 geometry pipeline. We have the entire child view/window system up, including docked and undocked windows. We have multimon working in windowed mode, but not fullscreen yet.

So what does that mean? Two things:

1)The device and view infrastructure is up and functional, we just need to finish it off with the fullscreen support. FSX with its view and multimon support is *the poster child* for multimon so that’s a key piece of infrastructure and non trivial. Early DX10 SDKs had no multimon sample code, so digging for information on how to do multimon in DX10 was hard and it is very good that part of the port is largely past us.

2)The geometry pipeline is up and functional; including loading vertex data, packaging vertex data into vertex buffers and index buffers, and submitting Draw calls. That is another key piece of infrastructure.

Here are some screenshots that show pushing geometry thru the pipeline in wireframe:

The World

Seattle and the Space Needle

Chicago and Meigs Field

Here is a screenshot showing multiview:

Multiview

And here is a screenshot showing multiview and multimon:

Multimon

So how did we get here so fast, just 5 weeks after SP1? We had help :-). We had one developer work on DX10 in the background while the rest of the team was engaged on SP1. He was the newest member of the Graphics and Terrain team, so this was his learning and trial by fire. He did all of the device, view, and multimon infrastructure code. And because he was in "learn-mode" and we had good coverage already for SP1 tasks this seemed like a smart deployment of resources. The progress so far bears out that call.

So what remains?

Quite a bit. We still have all the pixel pipeline work to get parity with DX9, and then the feature work. So the next progress report will be about the pixel pipeline. In 2-3 weeks you can expect another progress report. And at least one progress report past that before I talk features, maybe two.

So with all that, let me state that we are still on track for a Fall 2007 delivery of FSX-DX10.

Optimized for Vista does not mean DX10

Phil Taylor — Sun, 04 Mar 2007 02:30:00 GMT

There is a common misconception that "Optimized for Vista" equates to DX10 support.

“Optimized for Vista” from a platform perspective means your application qualifies for the logo. It’s a technical marketing term and the logo requirements define it.

From a business application perspective that means following the Windows Vista Logo requirements here. From a game application perspective that means following the “Games for Windows” Vista Logo requirements here.

So let’s see what those requirements are. As we drill down into the “Games for Windows” requirements list, we see they contain:

· 1.1 Games Explorer Integration

· 1.2 Support Parental Controls

· 1.3 Support Rich Saved Games

· 1.4 Support the Xbox 360 Common Controller for Windows

· 1.5 Support Multiple Aspect Ratios and Resolutions

· 1.6 Support Launch from Windows Media Center

· 1.7 Direct3D Support

Seven requirements, one that talks to 3D support. When we go to the details on that requirement we see that:

1.7 Direct3D Support

If the game uses Direct3D, then the minimum version supported must be Direct3D 9, and Direct3D must be the default for any display configuration option.

So by the numbers supporting DX9 is the baseline.

I understand the expectation for DX10, but by the numbers that isn’t part of what an application has to do to get the “Games for Windows” logo. And that is what the term "Optimized for Vista" is all about on our end. Yes, people can redefine the term to mean whatever is convenient for the argument at hand but that isnt what we mean ( and other publishers mean ) when they talk about "Optimized for Vista".

So with all that, what does FSX do?

We almost fully comply with this list, which in and of itself is no small feat when you consider the date of the document I link is Oct 2006. We authored Setup in Aug 2006 and RTM’ed in Sept 2006 so this document and these requirements where still churning after we shipped. Even considering the requirements where still changing, we hit them all except having Setup add the application to the Media Center 10’ experience.

And we are a DX9 title; we have no other rendering interface.

This is not to minimize the desire for DX10 from the community or our desire to implement it. This is just to point out that strictly by the numbers FSX does comply with the platform requirements.

So now let’s look at what Shawn said and when he said it. The link that is quoted on AVSIM.com, http://www.flightsim.com/cgi/kds?$=main/feature/firming.htm, dates from a post-CES interview. That’s Jan 2006. The last Vista slip was announced after this, in March 2006. The quote of

“Flight Simulator X is still on track for a holiday 2006 release and will be optimized for Windows Vista when Vista is released," according to Shawn."

is slightly out of context, since the next sentence says

“Expect to see a Windows XP version released first followed by an update for Windows Vista sometime after that”

So from that it is quite clear that our release plans changed when the Vista slip was announced. At that time we took a look and rolled basic Vista support with DX9 into the RTM release; and started making plans for DX10 as a separate release to upgrade our Vista support.

So now let’s discuss how our DX10 plan has evolved.

In Aug and Sept, as we lacked DX10 hardware at all (much less production quality hw) we realized we couldn’t simul-ship with Vista in Jan 2007 since we believed we needed at least 6 months with production quality hw. Getting early hw in Oct, and production hw at the G80 launch in early Nov meant at a minimum May 2007for release of DX10 support; given a 6 month schedule and a perfect world.

However, as FSX Launch occurred Oct 17 and we began to get feedback from the community we realized we needed a service pack to address performance issues and a few other issues. So we started a dialog with the community and made a commitment to delivering a service release. The work on SP1 and DX10 is being performed by the same team of people (the Graphics and Terrain team) and thus delivering SP1 has delayed DX10.

Given the state of the NV drivers for the G80 and that ATI hasn’t released their hw yet; it’s hard to see how this is really a bad plan. We really want to see final ATI hw and production quality NV and ATI drivers before we ship our DX10 support. Early tests on ATI hw show their geometry shader unit is much more performant than the GS unit on the NV hw. That could influence our feature plan.

As far as goals, we have stated a goal for delivering DX10 in the recent PR about the XPack, which is “Fall 2007”. We are going to meet that goal, bank on it. And I have made a commitment to discuss in more detail our feature plan. So far, I believe I have made good on each and every commitment I have made right?

Just as an aside, the work on the XPack is largely done by a separate team so SP1/DX0 has little or no impact on XPack and vice-versa. There are no new missions, no new models, and no new scenery in SP1 or DX10; nor is there any update to multi-player like there is in XPack. From the feature perspective, there is little overlap and is why we can plan and deliver all 3 releases this year.

In closing, we hope the community appreciates our openness in sharing our roadmap and discussing the various trade-offs we have made. Early in 2007 you have a view to all of our commitments this year. I don’t believe we have ever done that.

Timeline Update:XP,DX9,DX10

Phil Taylor — Fri, 16 Feb 2007 20:58:00 GMT

Now that my blog is all over arstechnica and digg, I need to correct something that is being misconstrued in my post about XP and DX10.

XP shipped in 2001 with DX8.1.

DX9 shipped Dec 2002. At that point the DX9 bits were final and could be used to make the desktop window manager and Aero. So that is the code branch I am talking about, and that is when DX10 wasnt "baked". Not back in the XP timeframe.

With the public demo of GPU memory management at WinHEC 2004 in April, thats roughly 2.5 years from the end of XP to a workable DX10.

One of my points, that what engineers enlisted into and checked code into ( the code branch ) was well beyond XP is made stronger and not diminished by me making clear this timeline.

Why DX10 wasnt created on XP and why it isnt in XP

Phil Taylor — Wed, 14 Feb 2007 22:15:00 GMT

Lets consider the software development lifecycle, the DX10 lifecycle, and the history of Vista,

The first step taken is to create a code branch for the new OS. XP RTM'ed in August 2001. I remember the ship party and still wear the t-shirt.

As changes go in to the new branch, it no longer resembles the thing that it was before.

DX10 itself wasnt fully baked when the initial branch was taken. DX9.L to support Aero and desktop composition took a bit of time. And the design if DX10 itself went thru a process with the IHV community where feature asks went back and forth, and features made the cut and missed the cut. Features miss the cut for a variety of reasons but that all takes time. Negotiations with the IHVs didnt conclude until late in 2003. This resulted in simplifications to the original MS Input Assembler design request. I worked at ATI in this timeframe as Director of Strategic Relationships and owned the ATI-MS relationship so I have 1st hand knowledge. I was in the meetings.

Given XP shipped in 2001 and it was late 2003 when the DX10 design solidified - it should be obvious that "what the OS was" was well beyond XP before serious DX10 work commenced. Heck, the Longhorn reset was in 2004 and DX10 wasnt done until later. The build that was demo'ed at WinHEC 2004 with the texture memory management was a very fresh build and wasnt feature complete - and that was April or May 2004. The 1st DX SDK supporting DX10 didnt appear until Dec 2005 here, http://www.microsoft.com/downloads/details.aspx?FamilyID=7d29004e-7a8d-4f0a-b199-6a740d8f27bb&DisplayLang=en. Further validating these points.

After the Longhorn reset, a new code branch based on W2K3 was started. Again that wasnt XP. And again kernel changes, which had to go in before the driver layer and the API could be brought up, made it even more not XP.

DX9 was in the original code branch, and was in W2K3 - so maintaining compat is of course an order of magnitude easier then new implementation.

Given the new features in the driver model and hardware ( with GPU task switching, GPU memory management and more ) all of which require kernel support - hoisting a driver layer like that on XP is rewriting it to be Vista. FWIW, the MS hw developer page has the graphics logo requirements and it explicitly mentions these GPU features as being required. They are essentially hidden features that API programmers and end-users never see.

At some point, the question "to serve existing customers" or "to get new customers" is a question every business has to ask itself. Given XP has had a 5+ year run it is hard to see how XP customers have a strong case they were not given good value for the money. Especially when the features in question are ones that are a rewrite of the kernel and the driver layer, and require such a hw leap. Really.

I hope the community can appreciate my points about how the branch and life-cycle work to make assumptions that Microsoft developed DX10 on XP not really true.

I also hope you can appreciate the level of the change, so the community understand the ask is a non-trivial investment of engineering resources.

We can politely disagree about whether or not MS should provide this functionality to XP users. And whether or not the investment makes sense.

I appreciate the strong feelings people have over this, but ad-hominems dont help advance the discussion. Could we keep them out of the discussion, please?

What are the components of DX10

Phil Taylor — Wed, 14 Feb 2007 22:12:00 GMT

A poster on a previous thread on AVSim.com made the comment:

"DX10 is an API from what I understand, e.g. they could compile it for XP, if they wanted to, it doesn't have to be exclusive for Viata. besides I don't care about it that much it will be late and buggy you can count on it."

And I thought there are a couple of points worth making:

1)Any D3D release has 3 parts:
a)the API programmers use
b)the runtime that commmunicates with the OS kernel and driver
c)the DDI(device driver interface)and driver that manages the hw

2)DX10 is out and nVidia has shipped product that works with it.

WRT to my point 1:

It is factually wrong that "they could just compile it for XP".

The runtime and its communication with the kernel is tied to the OS. There were significant changes in the runtime-kernel interaction in Vista. That would have to be back-ported to XP ( in addition to the API work ) and changes made to the XP kernel. Its not XP at that point, it is Vista. The changes are that significant.

In addition the DDI and drivers themselves significantly changed. This would mean developing an additional DDI layer, an additional DDK, validating the DDI and the test driver that would be required to give guidance to the IHVs, having additional WHQL suites, additional logo work, and additional driver development by the IHVs. Given how much work it is to get a Vista D3D10 driver up, this is non-trivial.

None of that is easy. And thats before the additional SDK work on XP to support developers.

WRT to my point 2:

By definition DX10 is not late. It is in Vista. Vista was late. Time will tell if there are any critical bugs in DX10 but early results indicate not.

The PC Industry, Multicore, and FSX ( with a little DX10 thrown in for good measure )

Phil Taylor — Wed, 14 Feb 2007 22:08:00 GMT

This is a recap of an AVSim.com post, that I wanted to capture here.

I'd like to take the time to address 2 areas that come up often:

1)FSX designing for multicore
2)FSX designing for DX10

1)FSX designing for multicore

As I stated in a previous post last year, the switch from Ghz to Multicore took most everyone by surprise in the entire industry. Reading a little history and thinking it through is informative.

All during 2004, when FSX was still in design stage and could be easily changed, the roadmaps were still predominantly Ghz based and multicore was a "variant".

Take AnandTech, a highly regarded site and look at their reviews throughout 2004.

Q1 2004 review
http://www.anandtech.com/cpuchipsets/showdoc.html?i=1948
no mention of cores

Q3 2004 review
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2233
cores are a "variant", as in "it would make sense if the FX-57 were to come with a dual core variant"

Q4 2004 review
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2303
It is only at the end of Dec 2004, with this review, that cores have been elevated somewhat in importance but note Ghz hasnt been deprecated hence quotes like this:
"There are other areas besides the high-end multi-core arena, and we haven't seen the end of increasing clock speeds yet"

Now move to 2005, and lets look at Toms' Hardware
http://www.tomshardware.com/2005/04/05/the_pentium_d/page2.html
and this review has a section "Sorry Guys, Clock Speed Does Matter" so the fact that the technology pony had jumped the tracks from Ghz to cores hadnt sunk it, even at sites whose job it was to keep up with this.

It isnt until 2006 that it has really sunk in and permeated the community. Mainstream sites have picked it up, like http://www.informationweek.com/shared/printableArticleSrc.jhtml?articleID=175802849.

Still enthusiast sites like http://www.guru3d.com/newsitem.php?id=3620 mention:
"Now through to the end of 2006, we will see Conroe taking up roughly 20% of Intel's shipments by then end of the year while the Pentium D processor will remain the largest bulk of Intel's desktop shipments."

So from a volume standpoint multicore wasnt seen as a majority in 2006 thru the entire 1st quarter and March IDF.

So while its easy to say "why didnt you see this coming" I think when you look at the available data it should be pretty clear that it wasn't that easy to see it coming.

Given where FSX was, by end of 2005 and early 2006, when this data started to sink in the project was so far past design the team couldnt react to rearchitect within the existing plan. It wasn't really an option to ditch the existing plan.

Even with that, we do have some multicore usage today and are working to get more. We reacted as we could within the original plan. So be careful with comments like "not once did they think" as that just isnt true.

2)FSX designing for DX10

With the last slip in Vista, combined with the associated slip in DX10 hw, the new DX10 schedule put it outside of the FSX ship timeframe. We didnt get DX10 prototype hardware until after the product was in manufacturing. Well after.

DX10 is a fairly major rewrite. And without hw on a title like FSX it is a major challenge to make forward progress. So we didnt think it wise to wait and shipped on DX9. We did think about what could be done with DX10 and we do have a good plan. And many of our existing features that challenge the DX9 pipeline should get better in DX10.

So we are really looking at what can be done with cool new features like texture arrays, large constant buffers for shaders, long shaders, low overhead API calls, better small batch Draw call behavior, etc. I have promised to go thru the "artistic impression" screenshots we have released and detail what features we see in them. We need to ship SP1 first and get back on to DX10 so I can talk to what features will actually be in the DX10 update and not a wish list. So give me time on that discussion.

In conclusion, given the jump from FS2004 to FSX, I think people should be a bit more careful in making accusations about the dev team and its thought process. We were most decidedly not sitting still. And its entirely too easy to play Monday-morning quarterback.

FSX Progress Update - SP1 and DX10

Phil Taylor — Thu, 01 Feb 2007 00:52:00 GMT

Its time for another update on FSX Progress. This is largely similar to what I posted on Avsim.com.

SP1

We are working thru the set of tasks we identified for SP1, are getting closer to closure and a final test pass, and should have more to say as far as details in the next couple of weeks.

The only things I can say is:
a)we are not toning down the experience and
b)we are aiming at a targetted set of perf and content fixes.

DX10

In terms of DX10, we have continued to make progress albeit slow. So DX10 will be after SP1. How far after SP1 remains to be seen, but its not a matter of weeks after since we still have serious feature work to do. Once SP1 ships and we get fully into DX10 development and a sense of velocity then I can start to talk to DX10 timeframes. One thing I will commit to doing soon after SP1 ships is walking the community thru the FSX "magic screenies" for DX10 and explaing what features Aces sees in those. If anyone saw the FSX presentation at the nVidia 8800 launch, I did just that so repeating it here is a good thing. Its just a matter of time, as in when I find the time :-).

Fair enough?