DX10 Patch and the geometry pipeline

[Guest MauiHawk]

To any ACES members perusing the forum:I know its early on in the DX10 patch development so its impossible for you to say what features it will include, but I was wondering if you could comment more generically on possiblities for the geometry pipeline of DX10.Specifically, is there any work currently being done that could thoeretically be moved to the GPU via the geometry pipeline? If so, would you consider doing it (please?), or would you say that its likely the geometry pipeline would be used only for new features/effects (if at all)?

[PhilTaylor 45]

What are you referring to by the geometry pipeline? Vertex pipeline or geometry shader?

[Guest MauiHawk]

The Geometry shader that is new to DX10 (the vertex pipeline is nothing that DX9 and earlier doesn't have, is it?)Many of the articles on DX10 have discussed the possibility of using the DX10 for physics-type calculations that are currently done by the CPU.(Such as the particles demos here:http://msdn2.microsoft.com/en-us/windowsvista/aa905008.aspx)So my question is, is there any work being done in FSX that could be realistically ported to a shader program instead? I was thinking along the lines of clouds, jet trails, and maybe less possibly AI aircraft and ground/water traffic? (I'm guessing any sort of calculations that require communication with the terrain system, etc would be difficult/impossible to move to a shader program). Maybe there are other possibilities I haven't thought of?

[PhilTaylor 45]

The DX10 patch is focused on making FSX render using DX10 so no we arent looking outside of the graphics engine. Within the graphics engine, we are looking at features that could use the geometry shader ( as well as achieving the same effect using a different technique, I believe I mentioned this on my blog ) and moving work from the CPU to the GPU, we just have to get there to see where things end up.We do make extensive use of shaders today, I think many people mis-understand where our CPU bottleneck is.

[GHarrall 494]

On that note Phil, for the un-educated amongst us, where IS the CPU bottleneck in FSX?Thanks for any insight....Glenn

[Guest MauiHawk]

Ok, fair enough.Sidenote: While investigating a problem with my own coding, I ran across a usenet post of yours from many years ago in the thread I was reading last week... which was an odd clash of worlds for me considering I don't do anything graphics related. Weird. Any any case the original poster there found you helpful, so: good job!

[PhilTaylor 45]

One source of bottlenecks are the per-frame number of D3D API calls. Which can cause a block in the driver on the CPU-side.Part of the SP1 work is to reduce these calls. The DX10 release will give additional reductions due to the better instancing, and due to the reduced per-API call overhead.

[Guest MauiHawk]

>One source of bottlenecks are the per-frame number of D3D API>calls. Which can cause a block in the driver on the CPU-side.So what would you say is the primary difference between FSX and most other games which are more GPU limited? It seems the possibilities are:1) FSX is asking the GPU to do less per D3D call-- ie, lighter on the shader programs, heavier on the number objects2) The CPU workload outside of the D3D calls is much lower in other games vs FSX so that the D3D overhead becomes more of an issue.>The DX10 release will give additional reductions due to the>better instancing, and due to the reduced per-API call>overhead.I'm happy to hear you expect overhead to be reduced futher with DX10. Would you expect a performance improvement comparable to SP1? (assuming one didn't compensate for the efficiency with extra eye-candy) Let me guess... too early to tell?

[Guest tcable]

This an excellent discussion :) meaty too without being too geeky.Thanks again Phil. at least I appreciate your comments.DX10 is not a golden BB, but part of a whole. I do understand that there are fairly dramatic lessening of restrictions in the rendering pipeline with greater efficiencies over similar calls under DX9.I hope that some of the DX10 hardware rumors are true on teh R600's- programmable shaders etc. It would be very cool if they could be very quickly changed from one type to another, but that's hardware, not software- at least for game designers.The new Ruby demo is amazing, and I've only seen it online off of a camcorder. If what I saw is infact a real time render on a desktop PC, Wow. It has surpassed Toy Story.

[Guest MauiHawk]

Part of the point of DX10 was to force uniformity of directX implementations. Up to now, card makers a lot of flexibility to implement the features they wanted and to leave out the features they didn't want. While that may have been nice from a GPU manufacturer standpoint, it sucked for developers having to take into account all the different implementations.Therefore, as a matter of principle enforced by DX10, R600 cannot offer any features that any other DX10 card does not have. The only difference between various DX10 cards will be the speed at which the D3D calls are executed (and the quality of the rendering). One exeption: both AMD and Nvidia are hoping that their cards get used by applications that can take advantage of streaming FPU operations by using entirely seperate APIs from DX10 such as CUDA: http://developer.nvidia.com/object/cuda.html. But I highly doubt ACES would even consider looking at either CUDA or AMD's solution at this point.As far as performance, I had high hopes for R600 too, but I'm afraid the long string of delays the R600 has had means it hasn't been performing like AMD wants it to. And the problem is even assuming R600 does grab the performance lead from Nvidia, NVidia's 8900 line will very quickly follow and I would have to think it would have a good chance of taking back the lead.... sorry, I think I may have crossed the "too geeky" line...

[PhilTaylor 45]

The primary difference is the sheer amount of things we render, given a 120+km viewing distance and trying to render the visible portion of the planet and not some hand-tuned level.Once you establish that as the fundamental difference, it isnt meaningful to talk about "light on shaders" vs x, or "CPU workload" vs x. For instance, every one notes that water 2.x is a heavy cost, that is because the 2.x shaders require a 2nd pass on the world and as you go 2.low to 2.med to 2.hi we increase what gets rendered thru the shader on the 2nd pass. So there the shader use is intense. And that has a direct impact on performance. Water 2.lo with high autogen is much better than any other water 2.x because 2.lo doesnt render the autogen. You have to understand FSX and its performance as a Socratic, holistic thing across all the subsytems and how they interact. Its really hard to try a simple Aristotelian breakdown of the parts.Trying to do more with each D3D call isnt easy given the engine architecture around terrain cells which is one of the reasons SP1 has taken time. Knowing what the other cell contains is clearly not as clean an architecture. But that is one of the ways to "batch up" similar objects.Yes, you guessed it, its too early to tell about DX10 perf boosts. We expect there to be some, yes - but I cant talk to a percentage yet.

[Guest MauiHawk]

That's really cool (and useful) to know exactly what is going on with the different water levels. Maybe if you are really bored at some point, you could write an insider's guide to what all the different settings are doing under the hood? ;) Thanks for your feedback. I think its extraordinarily unique to get this kind of feedback from a developer. Kudos to you.