Think of it this way, Maui - I'm no programmer myself, but here's my attempt at it...You have TWO assistants working for you, but only one of them is really being used. Right now, business policy says that all jobs are given to assistant #1. We have this task called D3D that is always being done. To make things a little better in the office, we write a policy that requires assistant #1 to quickly look at the jobs you give them, and if the task relates to D3D, give it to assistant #2 to be worked on. This task assessment probably takes much less time than actually working on the D3D task, so even though we spend a bit of time assessing the situation, it will free up assistant #1 to do his other tasks faster. Hopefully by the time assistant #2 is done with the D3D job, assistant #1 is passing another one it's way. This gets the assistants working more efficiently, and speeds up the process! IN the FS world, perhaps we can draw it this way...AS IT IS TODAY, absurdly simplified of course...Core1 FSX does location calc.Core1 FSX does weather calc.Core1 FSX does a AI traffic calc.Core1 FSX does a what's visible calc.Core1 FSX calls D3DCore1 D3D set up geometryCore1 D3D set up texturesCore1 D3D push to video cardwe start over!AS IT MAY BE "TOMORROW"...Core1 FSX does location calc.Core1 FSX does weather calc.Core1 FSX does a AI traffic calc.Core1 FSX does a what's visible calc.Core1 FSX calls D3D ---> intercepted! We split tasks!Core1 FSX does a new location calc / Core2 D3D sets up geometryCore1 FSX does a new weather calc / Core2 D3D sets up texturesCore1 FSX does a new AI traffic calc / Core2 D3D pushes to video cardCore1 FSX does a new what's visible calc / Core2 idleCore1 FSX calls D3D again ---> intercepted! We split tasks!Lather, rinse, repeat. Even though we spend a moment deciding if it's a D3D call or not, by splitting things off, Core1 gets to go back to the dirty work of FSX while Core2 finally puts in some time and does more work.Of course, this depends a lot on the architecture of the software. I could be ENTIRELY incorrect in this simplification of it all, but that's how I imagine it would function. There are probably tons of interconnections and dependencies that make this supremely challenging, but hey - it's worth the shot!

I understand BOPrey says that if he is not too busy he may design it to produce 50% gain. But also he mentioned that his time on that trivial project was getting less and less (very busy with business) so I understand there may well be no any gain at all unless Aces fix something in the next patch.

I am a programmer, though I haven't done anything with 3D graphics since college, and even then it was OpenGL. I'm not insisting that means I'm right and you're wrong since I'm not sure my knowledge applies all that well to this situation... still, I'm sticking by my suspision.I have done some limited work with multi-threading. And I have found (as is often reported) that synchronizing data between threads can be a pain not just code-wise, but efficiency-wise as one thread waits on data from another.That being said, if it can be assumed that all D3D interactions are one-way (ie, CPU provides data to GPU and never the other way around**) that would remove a lot of the headaches with code, and also a lot of the inefficiencies. Still, regarding these steps:Core1 D3D set up geometryCore1 D3D set up texturesCore1 D3D push to video cardIf you are going to avoid the data synchronization issues between threads, Core 1 must be the one to organize this information. In other words, either Core2 must be made aware of most critical game data which involves a lot of the headaches of multi-threading, or Core1 must organize all the necessary info (geometry, textures). At that point, I'm not sure it would be any more efficient to let tell Core2 "Here's what I want to draw, and here is the data you need" than to simply tell the GPU itself.** In the DX10 thread from the general FSX forum, Phil mentions how some graphical effects are accomplished by making 2 rendering passes and incorportating the data from the first pass into the second pass. It is my understanding that DX10 will allow this sort of thing to happen entirely on the GPU. But with DX9, I'm fairly certain the rendering from the GPU must be passed back to the CPU before the CPU orders the second pass using the data from pass one. With this sort of operation, I'm not sure everything would happen within d3d dll itself. In other words, I think there's a good possibility FSX code itself would need to get involved between pass1 and pass2, so unless his work would somehow allow this data to get back to Core1 from Core2 (and I feel like this could be quite difficult) I think either whatever efficiency of this solution would lost for these operations or (more likely) multi-pass rendering would not render correctly.

You are partially right. There will be some small over head move the data from thread A to thread B. However, the over head in machine cycles comparing to the D3D function execution time is minmum. Something like 5%. While we are at it. I did some more profilings. What I found is that the scen details (autogen and custom autogen) does not affect the time spent on D3D function much. However, it does have a huge impact on CPU time. That means the patch the ACES team is working on (reducing D3D function calls) might not help at all. Of couse, that depends on the graphics card used. As I am using a very fast graphics card. I will have to assume the performance gain on my system will be less than the same system with a slower graphics card.

>What I found>is that the scen details (autogen and custom autogen) does not>affect the time spent on D3D function much. However, it does>have a huge impact on CPU time. That means the patch the ACES>team is working on (reducing D3D function calls) might not>help at all. I think what you mean to say is that the total time spent on D3D calls is not affected, not that each individual D3D call is not affected, right? And what do you mean by CPU time? Certainly the CPU is going to be 100% utilized the entire time...When you are profiling, what exactly are you comparing? If you are only looking at the percentage of time doing one type of task vs another, I'm not sure the results will always be obvious. For example, if changing autogen settings from low to high doubles the amount of objects to draw but also halves the framerate, in both cases the exact same percentage of time will be devoted to D3D calls. But that doesn't mean the D3D overhead didn't change. D3D overhead should be considered per frame, not as a percentage of the total time the CPU was executing. In this case the D3D overhead doubled even though its percentage of execution time remained constant.Another question: how are you passing data to the other thread? I don't know D3D, but I have to imagine D3D accepts texture data and such by reference or pointer and not by value. So it seems you would need to copy the data to a new buffer before allowing the original D3D call from FSX to return which doesn't seem like an efficient task. If you didn't copy the data into a new buffer, that data could easily be gone by the time your separate thread tried to make use of it.

>This is a proxy of d3d9.dll. It has absolutely nothing to do>with FSX. It might as well bring multi-processor support to>other Direct3D applications. Coding has been done on the basic>architecture level. There are over a hundred functions I have>to work on, and it is going to take a while as my time on this>pet project is getting less and less (getting very busy with>business). >>BTW. My original calculation on performance gain is wrong. It>should be no more than 50% instread of 30%.Normally I agree 100% with you on this. What's different in this case is the wording of the Eula! Normally the Eula would have a clause saying you can't modify the software, in which case your assertion that this is an external fix would apply. FSX Eula though, goes further and implies a much broader limitation which says you can't work around any technical limitation. This opens up a huge gray area, and something I think you should be sure of before you release this! In any case I meant what I said, about wishing you luck and hoping you reach your stated target performance level (or better)!Tom

How about this: The operating system can take advantage of multi-cores for multi-tasked situation. So, set up a VM (virtual machine, or 2) and hook em up with WideFS. This might be a way to get (even) a quad core fully engaged for FSX ops. VMware has a beta I have been playing with (Its free. Go get it!) I have XP and OSx86 running inside a Vista installation. Darn thing's amazing. They all have their own IPs and seem to be operating as entirely independent machines.I've never played with WideFS, but it occurred that this just might be a way to more fully utilize the the duo (quad) core's potential for FS. Using VMs to tap unused CPU capacity is all the rage for servers these days. From what I understand, if WideFS can see a second (3rd, 4th, etc) independent IP address with a WideFS client onboard, it can provide its network function. So why not setup WideFS to utilize VMs so it can create a virtual network (ahh . . . "VN", right?) on a single machine? The cores will (should?)split up and drive the VMs as separate apps. (I understand this method of utilizing multi-core'd CPUs is gonna cost Intel billions in the corporate market!) What cha think?

This is how I profile. The average number of clock cycles spent on D3D calls per frame. This is acompblished by comparing the cpu clock counter (there is a way get this 64bit value which represents the number clock cycles passed since system startup) before and after each D3D call.The average number of clock cycles spent per frame. This is from beginscene() to present(). Not just by number of frames per second.This is accurate down to 1 clock cycle.I cannot answer your last question yet. Got to go.

Now. patch 1 is about to be out. I am going to wait and see before continuing.

You can't run FSX (or most/any DirectX games) inside a VMWare VM (or any of the other virtualization programs that I know of), although I believe trying to Virtualize the DirectX graphics layer is on their list of things to try in a future version, you can't do it with their current offerings (I wish we could, it would make doing Multiplayer Testing much easier to have multiple VMs instead of having to have multiple machines :-> ).Other than the DX limitation, the VM stuff is lots of fun to play with (I use several on my machines, 1 with XP setup to access Microsofts CorpNet, one with whatever Linux distro I've been playing with, one for the Browser Appliance when I just need a throw away browsing environ, occasionally play with other appliance VMs from the VMTN collection, etc).