The only SIMD we use is SSE/SSE2 I think, which goes back a million years. SIMD isn’t going to be that useful to us because most SIMD-friendly code lives in libraries we use (e.g. OpenGL) and not in native sim code. Native sim code tends to be bottlenecked on L2 bandwidth and possibly branching.

There are a few things OpenGL does that the DX guys can’t get access to. For example, in OpenGL you can use immediate mode vertex attributes as a quick way to do batching. (On many systems, attribute changes don’t need to be validated and simply get pushed into the GPU’s registers; this is faster than a uniform update, which requires some validation, possibly a buffer operation and changing some or all of the uniform window. The trade-off is that you lose some register space to the GPU, which can hurt fps if done too much. But the option is useful.) I am sure there are some DX tricks that OpenGL cannot do. But in the end the very fastest code paths are available to both.

The GPU isn’t particularly well suited for some of the CPU-centric tasks that can limit X-Plane’s framerate; they have to be solved by changing how we use the GPU.

While portability in general is something that could hurt performances, in this particular context I think it is not really the case. Despite of different OSes, we are basically speaking about the same hardware (all of the mentioned systems – MacOS, Linux and Windows – run on the same x86 CPUs). If we wanted to have a software that is required to run on different hardware platforms things would obviously be different, in the sense that either the developer does NOT exploit hardware-specific optimizations to keep the code portable and gives up on performance front, or he/she duplicates the hardware-specific part of code for each targeted platform, at the expense of increased maintenance burden.

Concerning DirectX vs. OpenGL, this is a loooooong debate. All I can say is, while it is true that the recent GPUs are “crafted” around DirectX requirements, it is also true that feature wise OpenGL is not (any more) inferior to D3D, as Ben said.

All of this makes me think that supporting multiple platforms does not really hurt performances in X-Plane.

Best regards,
Filippo

Thanks for clearing this out.
Since you talk about CPU limits… why not use GPU partially for that role too? I mean it’s the trend now with CUDA, OpenCL and DirectCompute… Actually for our case only OpenCL (which is both VGA and OS “agnostic”). I don’t know if I am saying something stupid.

It does not impact optimization; OpenGL and D3D are at feature parity right now. There was a while during GL 3.0 where the GL spec fell behind the hardware; the GL 4 roll-out (which matches DX11, roughly) has been a lot more aggressive, probably due to pushback from the community regarding the GL 3 lag. This is all moot for us; we aren’t on the bloody edge of feature use, so even with minor latency we wouldn’t see an impact.

I am not aware of any driver paths that are better in D3D than OpenGL; they both have hot paths and cold paths, and in the end you always end up batch limited on the CPU side.

Plane Maker – Miscellaneous Objects

That is covered in the articles linked to in the post!