3D Acceleration Support
-
- Volunteer
- Posts: 3342
- Joined: 10. May 2007, 16:59
- Location: Israel
mobius:
>What if the guest OS did have direct hardware access, what kind of problems could this potentially cause?
If the guest OS had direct access to host's hardware, then misbehaving application on the guest would be able to crash the host, plus viruses would be able to leak from the VM.
It would be insecure, like DOS.
-Technologov
>What if the guest OS did have direct hardware access, what kind of problems could this potentially cause?
If the guest OS had direct access to host's hardware, then misbehaving application on the guest would be able to crash the host, plus viruses would be able to leak from the VM.
It would be insecure, like DOS.
-Technologov
Hi!
I have a question.
Isn't it possible to translate the graphics instructions that have to do with the rendering and emulate the other instructions to satisfy a native guest driver?
Don't know if I'm "in the blue"? (Well, It's just a guess.)
This is how I think it works/would work. (I might be lightyears from the truth?)
first the host os checks if/what 3d accelerator it got and stores it
graphics-card -> host os
then the 3d acceleration is used by the host os
host os -> graphics-card
then my ide...
(starting vbox)
vbox tells host os to send the information to the guest os
host os -> guest os
guest os sending instructions to the graphic-card as well as the host os
host os & guest os -> graphic-card
Well, thats maybe not realistic?
Another more realistic solution is to simply (or maybe not so simple) make a translation table for ATI, Nvidia and Intel instructions.
Maybe it's possible way of solving the problem?
Another graphic related question.
Will it be possible to run windows (xp) "desktop-less" in vbox?
(Make it possible to start .exe-files in the guest from the host using the hosts window handles)? Just loading the kernel, no gui except for the graphics inside the windows?
Simply not loading the startup graphics and desktop.
Many thoughts, I guess that's what's called using the brain.
Greetings
zzarr
I have a question.
Isn't it possible to translate the graphics instructions that have to do with the rendering and emulate the other instructions to satisfy a native guest driver?
Don't know if I'm "in the blue"? (Well, It's just a guess.)
This is how I think it works/would work. (I might be lightyears from the truth?)
first the host os checks if/what 3d accelerator it got and stores it
graphics-card -> host os
then the 3d acceleration is used by the host os
host os -> graphics-card
then my ide...
(starting vbox)
vbox tells host os to send the information to the guest os
host os -> guest os
guest os sending instructions to the graphic-card as well as the host os
host os & guest os -> graphic-card
Well, thats maybe not realistic?
Another more realistic solution is to simply (or maybe not so simple) make a translation table for ATI, Nvidia and Intel instructions.
Maybe it's possible way of solving the problem?
Another graphic related question.
Will it be possible to run windows (xp) "desktop-less" in vbox?
(Make it possible to start .exe-files in the guest from the host using the hosts window handles)? Just loading the kernel, no gui except for the graphics inside the windows?
Simply not loading the startup graphics and desktop.
Many thoughts, I guess that's what's called using the brain.
Greetings
zzarr
Just another ide that might work
Creating a "NAT-Tunnel driver" to the host os.
like this...
|-> host os native driver <-> host os
graphic-card <-> "NAT" <-|
|-> guest os native driver <-> guest os
The "NAT" driver should send all instructions thst's not a replay to both/all os's. (The NAT should be a host os driver.)
This is a solution that might work (might not be 100 % native... but...).
Is it possible to implement this solution?
I can't see any problem.
edit "added signature"
Greetings
zzarr
Creating a "NAT-Tunnel driver" to the host os.
like this...
|-> host os native driver <-> host os
graphic-card <-> "NAT" <-|
|-> guest os native driver <-> guest os
The "NAT" driver should send all instructions thst's not a replay to both/all os's. (The NAT should be a host os driver.)
This is a solution that might work (might not be 100 % native... but...).
Is it possible to implement this solution?
I can't see any problem.
edit "added signature"
Greetings
zzarr
-
- Volunteer
- Posts: 3342
- Joined: 10. May 2007, 16:59
- Location: Israel
Re: Parallels Approach
This was posted some time ago, but I would like to second it...Nil wrote:AFAIK, the way Parallels does 3D support is virtualizing OpenGL then using WinE's DirectX DLLs on Windows (which are implemented using OpenGL).
By the other hand, VMware Workstation 5 and 6 support DirectX 8.1 directly, altough you have to enable it manually by editing the VMX file. VMware Fusion for the Mac also supports it and you don't need to edit any file to get it, I suppose it's the same implementation.
AFAIK, Parallels have done a very good job on their product using Wine's code (Wine3D) for DirectX (as said on the quoted post, Wine translates DirectX code to OpenGL code) instructions to achieve 3D on Windows guests.
In the VBox's SVN there is some OpenGL support code... couldn't be better... If OpenGL virtualization is taken care of, that gives even more reasons to use something like WineX to reduce duplicate work (ie. implementing DirectX too).. and Parallels Desktop serves as a good proof of concept, showing that it works..
At least, I think this is better and less work than writing a emulated graphics device for each supported OS, for each Graphic library (OGL and DX in windows guests case..)
-
- Volunteer
- Posts: 3342
- Joined: 10. May 2007, 16:59
- Location: Israel
While reading on the mailing list, I found a mail a message by Juan Luis Baptiste on the 3D acceleration questions list, that stated the following:
this was written on september 2007, but for the sake of clearing some things, I want to post this here...
first off, transgaming has not contributed a single line of code to Wine's 3D support. Cedega's contribution to the whole Wine project can actually be counted with one hand and range from trivial to useless.
nothing is backported from cedega to wine
I'm not aware of how Cedega's DirectX implementation works, but I doubt it's too different from Wine's... if I recall correctly, they also rely on OpenGL translations, but I'd have to investigate a little.
Cedega is not more complete than wine... in fact, Transgaming is changing Cedega's code to synchronize it once again with Wine and be able to take stuff they haven't done but that Wine has. (for more information, search Cedega's entry on wikipedia, which I happen to have written to a couple of times)
what cedega has that wine doesn't?... some types of copy protection... and that's about it
cedega WAS a long time ago more complete in it's 3D, but as time has passed, not only has Wine done almost the same things, but have done it even better (more 3D games work on wine than on cedega).. but that was because, since the fork they only concentrated on 3D while wine concentrated on general apps support.... now that wine has gotten so far, cedega is not better than wine
and I also wanted to point out that it's generally better to try software first hand and then make your opinions than trusting the maker's statements blindly ...
I would like to hear VBox developer's opinions about this option of using wine to get DirectX acceleration, but I guess that it will only come as either paying consumers or Sun say they want it.... anyways, I think that the (as of this very moment) 33333 Views of this thread works as some indication of what common, non-paying users want
when the discussion pointed towards suggesting the use of Cedega instead of Wine to make 3D possible a la Parallels...And the difference between cedega and wine is that cedega implements a full Direct3D and DirectSound 9 API, wine doesn't. As far as I kniow, most of the 3D support wine has is because of contributions of Transgaming, stuff that is already in cedega and then backported to wine, which makes cedega always more complete than wine, in 3D stuff that is. Also, Somewhere I read sometime ago that Transgaming claims that cedega has the same performance than in windows, but I havent used it to confirm that.
this was written on september 2007, but for the sake of clearing some things, I want to post this here...
first off, transgaming has not contributed a single line of code to Wine's 3D support. Cedega's contribution to the whole Wine project can actually be counted with one hand and range from trivial to useless.
nothing is backported from cedega to wine
I'm not aware of how Cedega's DirectX implementation works, but I doubt it's too different from Wine's... if I recall correctly, they also rely on OpenGL translations, but I'd have to investigate a little.
Cedega is not more complete than wine... in fact, Transgaming is changing Cedega's code to synchronize it once again with Wine and be able to take stuff they haven't done but that Wine has. (for more information, search Cedega's entry on wikipedia, which I happen to have written to a couple of times)
what cedega has that wine doesn't?... some types of copy protection... and that's about it
cedega WAS a long time ago more complete in it's 3D, but as time has passed, not only has Wine done almost the same things, but have done it even better (more 3D games work on wine than on cedega).. but that was because, since the fork they only concentrated on 3D while wine concentrated on general apps support.... now that wine has gotten so far, cedega is not better than wine
and I also wanted to point out that it's generally better to try software first hand and then make your opinions than trusting the maker's statements blindly ...
I would like to hear VBox developer's opinions about this option of using wine to get DirectX acceleration, but I guess that it will only come as either paying consumers or Sun say they want it.... anyways, I think that the (as of this very moment) 33333 Views of this thread works as some indication of what common, non-paying users want
... I think you should try to put that on Wine's forum!... anyways, with 3D acceleration in VirtualBox, you will eventually have everything solved hehesteve723 wrote:I keep checking as as of my last check wine still could not run The Sims 2. That's the last reason why I can't kick Winblows off my hard drive.
The Wine approach to translate Direct3D to OpenGl is the most logical approach to solve the problem. It's on our todo list, but I can't give you an ETA.
good to know!.. I didn't expect an ETA, but it's good to know what and/or how you will progress with VBox.. keep up the good work
-
- Posts: 1
- Joined: 9. Mar 2008, 16:40