-
-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for VirGL for qemu? #13
Comments
VirGL in QEMU only support 32-bit framebuffer formats for both 3D and 2D making it useless for vast majority of early D3D games; there's not much point supporting it unless support for 16-bit framebuffer formats is added to it. |
Oh, in that case, i'd like to ask: are any of the other graphics cards in qemu hardware accelerated as well? (vmware-svga, bochs, etc..) |
No. |
Hello, VirGL now in TODO list. Limit to 32 bpp framebuffer is same for SVGA3D (vmware) and modern 3D hardware. But if is supported 16 bpp unaccelerated framebuffer it can be solved by using internal 32 bpp rendering and finally software blit to 16 bpp - I'm using this in VBox/VMware and it’s less memory effective (you need one extra back buffer) and slower (software blit) but 16 bpp games works (for example all Glide) . |
@Cacodemon345 Cut out that RETARDED mindset typical of "Trash"Box or "JUNK_PC"em. VirGL in QEMU is phenomenal if anyone wished to plunge enough devotion and realize it for Windows guests, even if it only provides host OpenGL acceleration without DirectX support similar to Linux guests. For what matters to Game Preservation in VM, the rest can then be taken care of by WineD3D emulating ddraw1~7 to d3d11 on OpenGL backend similar to the other *EVIL* project. 16-bit framebuffer format has never been an issue at all. Wine manages DDRAW surfaces in textures. Linux X.Org/Wayland only support 32-bit pixel formats and early D3D games are just fine with Wine. Don't just take my words, download WineD3D and read the source codes. The other *EVIL* project does the same and always negotiates for 32-bit pixel format for OpenGL context. sarah-walker-pcem/pcem#205 (comment) |
As the maintainer and main developer of 86Box, I can't help but wonder where did you hear that we wouldn't accept a Virtual Direct3D adapter? Are you just assuming that because we forked PCem, we have the exact same restrictions? We have the "Virtual PC" machine which literally uses the Virtual PC BIOS, and we have PCem's Voodoo emulation which basically mostly runs in the acceleration thread, so it basically runs as fast as the host can do it (certainly faster than the real Voodoo), so a Virtual Direct3D adapter wouldn't be that much of an outlier. And ultimately, if using the host CPU to accelerate the emulated CPU (which the dynamic recompiler does) is acceptable, then I don't quite see why using the host GPU to accelerate the emulated GPU wouldn't be - you're basically dynamically recompiling guest 3D (and 2D?) operations to the host GPU. That said, we currently still have so much work to do that, even if we do decide to do that, it's going to be a long way before we have the time to do it. However, if you, or anyone else for that matter, were to PR such an adapter, then we would gladly review it and accept it if it's good enough. |
If you missed the chance to read the link to PCem "canonical" Github above, then too bad, the FUN & informative TRUTH were deleted. The "Veil of Deceit" ~~ "Incoming was Direct3D5 (and already works)" ~~ however remains. 🤣🤣 I had merely suggested the ideas of a rebirth in "PCvm" as well as the concept of "Virtual Direct3D adapter". If you liked them, feel free to take them. The good thing is coming. VirtIO GPU 3D acceleration for Windows guest, a true implementation that leverages MESA Gallium3D for GL and d3d10umd. If anyone ever need a reference to break the promise of NO GPU acceleration 🤣🤣, that's it. There is nothing wrong in how anyone want to shape their projects & set priorities, so long as they are presented with honesty & integrity. Not in the *BS* such as "Incoming was Direct3D5 (and already works)" or "Max Payne works on PCem". Oh, I was wrong again 🤣🤣, they "work" just don't "play" them.
It is indeed delightful to hear that. Why just stop at real Voodoos, NVIDIA RIVA TNT or ATI Rage 128 Pro? A 20% utilization of any modern GPUs from the last 5 years, including iGPUs/APUs in laptops, easily outclass any of them. It is annoying when someone kept spewing the Accuracy *BS* as the BEST for Windows 98 games, including the almost *USELESS* Voodoo 3/Banshee emulation for playing games from that era in the low-res, low-quality compromise for 20+-year old games. |
As I said, you're right and if someoen were to implement your idea for 86Box and PR it, I would gladly accept that. The idea was also floated around on my Discord server a few times, but, as I said, we currently have a lot of work to do. Though, let me correct you about Windows 98 games - you are assuming they are all 3D - they are not. I remember playing Krush, Kill & Destroy, Oddworld: Abe's Oddysee, and ToonStuck, just to name a few, just fine on my real Pentium 100 with a Cirrus Logic CL-5446 with no 3D acceleration. As a matter of fact, the era you are talking about, namely, Max Payne, etc., is basically out of the scope for 86Box - the first Max Payne, for instance, is from 2001, the era of Pentium III, Athlon, and the beginnings of the ATi/Nvidia duopoly - definitely not the era we think 86Box is currently remotely capable of emulating, or will feasibly be for the foreseeable future. Yes, there's a fork attempting to emulate the Pentium III and even Athlon and Pentium 4, but it's by stubborn former developer of ours who refuses to accept that no PC currently in existence can adequately emulate those machines. So in fact, I would say that games from that era are indeed best served by solutions such as yours. |
I don't disagree with you for non-3D Windows 9x games. I played StarCraft 1, Diablo 1 and countless of DirectDraw 2D-only RPG/RTS on QEMU without the needs of virtualization accelerators (WHPX/KVM) on the emulated Bochs VBE/DISPI or CL-5446, too, way before the *EVIL* even existed.
https://www.vogons.org/viewtopic.php?p=915671#p915671 The *RETARDED* "long live PCem" fanboy was definitely in disagreement with you, along with the show-off of MDK2 1920x1440 HD *without the guts* 🤣🤣to include on-screen FPS that the demo supported. The Unprofessional Moderator @vogonsorg would rather purge the *EVIL* TRUTH while tolerate such *BS* to remain. And when such "Veil of Deceit" was teared off, it was deemed "disparaging remarks" for the super sensitive's own dishonesty and lack of integrity. In fact, I wouldn't mind for exaggerating the Voodoos emulation potentials, but it would only be fair & honor when it also stood up against criticisms. I am sorry for making use of strong words. Sometimes, the messages ought to be delivered with an impact, if anyone reading VOGONS truly believed those games "work" on PCem v17. Road Rash (1994) was definitely fine, but Mechwarrior 3 without CD-Music, well, what a comedy!🤣 I don't have any comments on one's pursue of Pentium III/Athlon/Pentium4 emulation. Who knows one day, such obsession may lead to the wonderful world of "Virtualization".
http://pcem-emulator.co.uk/phpBB3/viewtopic.php?p=15196#p15196 There were valid reasons why the forums were nuked. Many *BS* remain nonetheless. I wonder if someone will pull the trigger again.... 🤣 |
Having that TODO list in the README would be exiting, maybe add after Bugs Future work
|
I'd like to ask if it's possible to target virgl for people using qemu? I think it can be beneficial for windows emulation because till now, no windows drivers for virgl exist.
The text was updated successfully, but these errors were encountered: