http://bugs.winehq.org/show_bug.cgi?id=12516
--- Comment #59 from Robert Wm Ruedisueli esd45@earthlink.net 2010-07-14 18:56:30 --- What I meant to say was not this limitation was interfering with Direct X performance, but the larger limitation it is symptomatic of.
Basically Wine's entire memory mapping and memory access capabilities on all modes is entirely limited by the Host OS.
While this is fine for now, it will not be good in the long term, as this limitation puts Wine at the mercy of the host OS when choosing how programs see memory, and what shared memory methods are used.
While this is all fine if the host OS is providing optimal methods for doing things. Wine should create a universal means to direct the OS on how to handle memory remapping for Wine, and a variety of transparent fall-backs for when the Host OS is incapable of doing what is necessary to properly match bug for bug Win32 specifications. Without this, bug for bug matching of the memory mapping of all access modes used by drivers and programs will be literally impossible.
Basically, I'm saying it's better to stomp one big bug, than stomp out all it's children. We have the first small bug here that is symptomatic of a much larger limitation. Making plans to defeat that limitation in the long run, could save us hassles down the road, and greatly improve performance.
As of how this relates to Direct X. The current Direct X drivers are greatly limited by Wine's shared memory access. By improving the memory mapping methods used in all segments of Wine, we can pave the way for improvements in that department. It's basically that some of the limitations on how Direct X is implemented are limited by memory mapping capabilities as well. Just like this bug is caused by those same limitations, even if the limitation is impacting a completely different subsection.