Please support DirectX
- Thread starter conalho
- Start date
Agreed
I am trying to 'remove' myself from a Windows based laptop I use for aviation, and many aviation simulators use DirectX programs. An example is the Garmin G-1000 simulator. When I try and run it under Windows XP and Parallels, I get a DirectX error.
I am exposed to hundreds of people a year while teaching aviation ground and flight school and Parallels would be a big hit for me and my students if it handled DirectX.
Thanks so much for a great product - looking forward to DirectX support
I am trying to 'remove' myself from a Windows based laptop I use for aviation, and many aviation simulators use DirectX programs. An example is the Garmin G-1000 simulator. When I try and run it under Windows XP and Parallels, I get a DirectX error.
I am exposed to hundreds of people a year while teaching aviation ground and flight school and Parallels would be a big hit for me and my students if it handled DirectX.
Thanks so much for a great product - looking forward to DirectX support
mymindwideopen
Bit poster
I Agree
I thing parallels is just about the coolest program ever. I am so happy with it, except for this one issue. Please support direct x soon.
I thing parallels is just about the coolest program ever. I am so happy with it, except for this one issue. Please support direct x soon.
shaneblyth
Member
Yes DirectX is very important
David Corrales
Hunter
Dual boot... emulated software runs slower by definition and even moreso games.
David Corrales said:
Duel booting defeats the purpose... if we wanted to duel boot, we wouldn't be using Parallels to begin with. Now, to correct your misunderstanding. Parallels is not EMULATING. The only limitation of Parallels is the virtual drivers giving access to all features of the real hardware... VIRTUALIZATION is not EMULATION!
Emulation would be true if Windows and Intel Macs did not run on the same architecture. For instance, the Atari 2600 emulator allows the running of Atari, which does not use x86 architecture, to run on Windows/Mac/Linux which does use x86 architecture.
Since Parallels is virtualizing the hardware, it is not having to recreate the x86 environment, but rather extend that environment to allow two operating systems to simultaniously utilize the same hardware at the same exact time. The speed difference between Emulation and Virtualization is like comparing Apples and Oranges. Not an Issue!
Finally, you may personally have limited RAM, so that the virtual environment is slow, but some of us have decent RAM and with the ability for up to 16GB on Pro machines, DirectX support would run great! I personally have 2GB of RAM and I have NO slow down problems on anything I run, even the most demanding software.
Last edited:
The processor is being virtualized. Everything else is being emulated. The video card being emulated is not the same as the hardware card, and is the same emulated card regardless of hardware platform. Video, keyboard, and mouse, MUST be emulated because they are shared with the host (and other VMs that may be running)
There's nothing wrong with asking for a 3D capable card to be emulated, and they might do that at some point, but it still must be emulated.
There's nothing wrong with asking for a 3D capable card to be emulated, and they might do that at some point, but it still must be emulated.
David Corrales
Hunter
jbardi said:
In your own words, to correct your misunderstanding.
VIrtualization -is- emulation. You're presenting the guest operating system with a full virtual machine. The video driver is emulated, that is, all calls to the Parallels video driver are handled by a module installed in the host. That's why you need to install the tools in the first place or you get horrible performance. You can't access the video memory directly from the guest OS.
The same happens with the mouse, sound, ram (which belongs to the parallels process, which in turn manages it), etc.
The NIC is bridged through an emulated driver also. You might get an ip from your dhcp server, but you wouldn't be able to modify the real driver parameters. You can do as much as your emulated driver allows you, not what the real hardware is capable of. You probably can't unify bridged NIC for load balancing for example.
The processor is one of the few parts which doesn't need to be emulated since the operating systems are compiled to run for the same instruction set.
You're probably referring to paravirtualization, like the Xen hypervisor which doesn't abstract the physical layer as much. You lose some flexibility, but obtain lots of performance gains. The difference between paravirtualization and virtualization (emulation) is like comparing Apples and Oranges. Check out for the following page: http://www.cl.cam.ac.uk/research/srg/netos/xen/performance.html
First of all DirectX is not at all RAM bounded. It's bounded by the GPU and it's architecture/memory. Since virtual machines don't have real raw access to GPU's, you could have 1Tb ram and DirectX or OpenGl performance would suck.
I personally have 1.5gb of ram, and while virtual machines use 384/512RAM, the perceived speed is sucky because there's no tools for linux hosts. Also, 2Gb ram would be a joke for a high concurrency transactional database with a large record set.
I think you need to do some more research, so here's a couple quick links for you:
http://en.wikipedia.org/wiki/Hypervisor
http://en.wikipedia.org/wiki/Paravirtualization
Finally, before you think I'm a troll. Search for my posts and you'll see what kind of poster I am.
Last edited:
David Corrales said:
Wow, I didn't know the NIC card was emulated too, I thought it would have been direct. Course I'm not a computer expert by any means. I created a thread addressing the issue of direct video card support and was hoping a guy like you could answer my questions about an idea I had.
Please read my thread here to see my questions: http://forums.parallels.com/thread5304.html
I know I've been told this is impossible, not feasable at this time, etc. but you seem like a smart guy and I'd like to know WHY it's not possible.
Since the processor is being virtualized (not emulated), could the video card processor be virtualized too? Isn't the video card just a mini computer that only does video? Seems like one could run a layer on top of that processor and get direct access to its ram just like on the main processor.
You say the tools are installed in order to allow the VM to access the video resources.
>"all calls to the Parallels video driver are handled by a module installed in the host"<
Since Mac and Windows can use the same video cards, just like they can use the same processors, is it possible to make a direct path from the virtual processor to the virtual auxiliary video card? Could you present a full virtual video card using the same type of programing that is used for the processor?
The processor can be virtualized because Intel and AMD provide specific hardware support for doing so. Currently, the processor is the only component that can be virtualized because it's the only one with hardware support. If hardware support for virtualization appears for other components, they can be virtualized too, but at the moment, any component other than the processor that must be shared must be emulated. There is no way around this no matter how badly we would like there to be.bgose said:
2+2=4, never 5, not even for large values of 2.
David Corrales
Hunter
Bridging means direct access to your network layer through the emulated NIC. It's having 2 logical cards using just 1. In linux, they're called alias (you might've seen something like eth0:1 which is the first alias for the real network card, eth0).bgose said:
I'll try to explain the situation about the accelerated video cards.
First of all, the processor is easily virtualized because the operating system provides all the necessary interfaces and they're standarized. Windows, Linux and now MacOS provide all the necessary drivers, with full functionality and to the Parallels process, it's simply a matter of passing instructions as if they belonged to it. That also means, that the guest operating system has the necessary drivers to handle the processor they get reported, so it's a 1:1 match.
With the video cards, the situation's different. Ati, Nvidia and Intel don't publish their exact specifications and drivers. They have strategical reasons not to do it. For example, some optimizations are done in the driver, not hardware. Also, there's hardware bugs not caught during testing, and those get workarounds inside the driver code.
A typical accelerated call to a video driver goes like this:
- Program->DirectX/OpenGL->Video card driver->GPU
If you were to virtualize it, it'd be like this (maybe a real direct access someday?):
- Program->DirectX/OpenGL->Virtual video card->(host OS)->DirectX/OpenGL->Video card driver->GPU
or
- Program->DirectX/OpenGL->Virtual video card->(host OS)->Video card driver->GPU
You can easily tell about the added complexity of the first implementation. Imagine if both, host OS and guest OS, have different graphic libraries. That'd be a nightmare.
The second approach, which goes straight to the driver inside the host, implies catching every call to an accelerated function and then mapping it to a corresponding driver call. Since the driver specifications are not open, it's even harder to create the proper "hooks" to implement this behaviour.
What virtual environments use now is the VESA driver. It's been a standard implemented for some years now but it's slow. You could think of it as "software acceleration". Works on all of them, but slowly. Besides, the usual process is copying the whole buffer to the guest OS card.
The VMWare video driver is an exception, because it's somehow of a middle ground. It's not VESA, but rather an optimized way of transferring the buffer to the host OS.
Another problem concerning video cards is the fact that they need a context to write to. You don't have to worry about this with the CPU, because the host OS provides this execution context. With the video cards, it's not as easy. There's different video architectures for the different OS's. Windows handles the video inside the kernel, Linux and MacOS use different client/server architectures.
I'm not a deep down expert in these matters but that's a starting point.
Last edited:
Ummm... yup.David Corrales said:
It's a hardware issue. The latest intel and AMD processors provide hardware support for virtualization, and it really has nothing to do with driver specs. The VT-X spec is published, and there are no video cards with hardware virtualization support today (AFAIK -- at least nothing in the mainstream). Peripheral virtualization support in hardware is, no doubt, coming some day, probably soon, but when it does, we will have to buy new hardware with the feature installed.
David Corrales
Hunter
The latest Xen allows unmodified windows to run if your processor has virtualization extensions, AMD or Intel.
David Corrales
Hunter
joem said:
I wanted to help lolDavid Corrales
Hunter
It'll be eventually solved, that's 100% sure, but we'll have to wait a while.
If you want me to explain one of those parts a bit more, just tell me. I love the implicit learning process you go through when helping others.
If you want me to explain one of those parts a bit more, just tell me. I love the implicit learning process you go through when helping others.
David Corrales
Hunter
It's not only a hardware issue. For example, all the processors that don't posses the virtualization technologies are fully virtualized in VMWare, Parallels, etc. It's about their specification being fully disclosed and therefore, it can be properly implemented as low level kernel drivers in all OS's.joem said:
The virtualization extensions are to virtual machines what MMX, SSE's and 3DNow are to multimedia.
This may be a semantic issue. Without hardware support for virtualization, the processor must be emulated, which accounts for the reduction in speed when VTX is turned off. Slowing down graphics by emulating 3D would, AFAIK, produce such a low frame rate that it wouldn't be sworth doing, since it would require either doing all the 3D calculations in software, or saving and restoring video context frequently. Further, the hardware approach (with current devices) would only work full screen.David Corrales said:
The bottom line is that 3D isn't going to work in Parallels for a while now. On to other things.