VBE/AF support (2D hardware acceleration) #27
Comments
Thank you! I really didn't expect it to take off like this, especially given how unfinished it is! 😅
I thought about it, but once I realized the spec was behind a paywall and so unsupported I didn't really think much more…
Yeah, I don't think I have any hardware that supports it, so that's another reason I didn't think much about it…
But now that you've told me about FreeBE/AF, I must have another look! Somehow I'd got it in my head that the spec was behind a paywall and NDA, but it sounds like that's not the case, and that I could learn it from studying that project. Food for thought! Taking a quick look, it seems like this would supersede a lot of the CPU-based GDI-facing functions that I wrote / tweaked, so maybe it would be a separate driver altogether… 🤔
Definitely! 😉
Thank you for suggesting this! |
|
Well, at least about the "paywall" part, I have some good news: VESA makes a distinction between newer standards for which they still require contribution (modern things like DisplayPort and such) on the one hand, and free standards (older and ubiquitous stuff) on the other. VBE fits into the latter category. Those specs don't require payment to download, but they are a bit hidden behind kind of a "registration wall". You need to submit a form to gain access to the download page for those:
The reason why I know this is because I also needed to submit that form to get to the download page of another old VBE extension, VBE/AI. That was intended to be an open audio API standard for DOS, but unfortunately arrived on the market too late, and thus suffered a similar fate as VBE/AF. But I still think that these standards could be resurrected or at least repurposed by the retro-computing community. As you can see in the LICENSE file of the VBE/AI SDK repo, I got an email reply from someone at VESA who considered VBE/AI to be in the public domain now, and had no problem with me sharing the specification on GitHub. It's highly likely that the same is true for VBE/AF. We could send him another email about that. Anyway, the VBE specs on the download site consist of a number of documents, documenting the core specs and/or the various extensions. I think the ones potentially relevant to the Combined with the source code of the aforementioned FreeBE/AF project, this should provide you (and hopefully also other contributors) with enough information to try implementing this in a driver, right? I hope this is useful. 🙂 |
|
Oh, this is interesting: VESA used to host The Internet Archive has preserved it: https://web.archive.org/web/20050305105407/http://www.vesa.org/public/VBE/VBE-AF07.pdf So there you go. 🙂 |
|
The checksum of the |
|
You technically don't need VBE/AF. You could in theory talk to any interfaces offered by virtual machine software, e.g. opengl passthrough. That'd quickly grow out of scope for a VBE driver though. Though maybe there are other widespread means to accelerate common operations like blits. To take this to a hypothetical extreme: With modifications of doxbox, a doxbox aware driver could pass GDI operations to the host gdi32.dll and have Windows 11 do all the work. |
The problem is that there are multiple paravirtualized video adapter standards, i.e. VMWare SVGA II, VBoxSVGA, VirGL, etc. The hypervisors that support them already have VBE BIOSes that allow those virtual video cards to be use with applications and OSes that use VBE. But to access any 2D acceleration features (in so far these virtual graphics adapters support those), individual drivers would have to be written for them. And then there are the various modern GPUs, all of which have VBE (without the AF extensions) as the lowest common denominator. I was hoping by having more (legacy) software (such as Windows 3.x, but perhaps also 9x and maybe even some DOS games) dust off and embrace VBE/AF, it would encourage developers to extend the existing VBE support in all these graphics cards (both real and virtual) to add support for VBE/AF. It seems like it would make more sense than having to write separate device-specific Windows 3.x drivers for each individual one of them, which could then perhaps tap into any acceleration features. Ditto with for instance Windows 9x and other legacy OSes and software to which one would like to add support for newer graphics cards. Targeting a unified cross-platform standard driver model from both sides (both the device-side and the OS- and application side) makes more sense from a maintainability perspective, I think. The idea being that instead of VBE without acceleration being the "lowest common denominator" here, eventually it would be VBE/AF.
Cool idea. I guess the same could be done with Wine running on a Linux host, since Wine has a GDI implementation too, right? Couldn't a modified Linux-native DOSBox be linked with Winelib and then pass GDI operations through to that? (Just going along with the fun speculation at this point. This seems like madness. 😜) |
|
But to be completely clear: if there's not going to be any serious interest and effort to add VBE/AF support to more graphics cards and hypervisors, there would indeed be no point adding support for this to a Windows driver either. I'm just hoping the one will spark interest in the other. It's kind of a chicken-and-egg problem. |
Exactly what I was thinking! Madness it may be, but the idea's in my head now… Which means that if I live long enough, I may just make it happen… 😅 Anyway, I'm certainly open to adding VBE/AF support to this driver in the nearer term, but there are lots of other bugs / unimplemented functions that need to be sorted out ahead of that. Whether or not it helps push forward a wider revival of the standard is another question – I'd be honoured to be part of such a thing, but I don't really know how realistic it is! Do modern cards have any hardware that would help with VBE/AF? Or has all the hardware capability been moved over to the 3D side? |
Well winelib isn't as simple as linking to -lgdi32 and calling it a day. You still need the entire Wine infrastructure to run it. E.g. gdi32 links to winspool and advapi32 to enumerate printers and most of the actual gdi32 drawing is moved to win32u/win32k nowadays. The purpose of Winelib was originally to build Wine's own programs (like notepad.exe, regedit.exe, ...) without needing a windows cross compiler and to allow building a Windows application for other architectures like PowerPC, MIPS, etc. You still need all the rest of the Wine infrastructure to actually run those binaries. Fwiw I said "hypothetical extreme" because I don't think a gdi passthrough out of dosbox / dosemu would be useful. I meant to make the point that you don't need VBE/AF if it doesn't give you any advantages. E.g. if no VBIOS or virtual machine implement it, it would be more work than talking to whatever else exists, like 3D passthrough. It's your project of course, so work on whatever is fun :-) . My 2c is that there are still performance improvements you can do purely in your driver without relying on anything beyond plain VBE. E.g. compare https://archive.org/details/win3_winben31 to the old svga vbe hacked driver.
Pure 2D circuitry is pretty dead since 20 or so years, but GPUs still have blitters for data transfers. See e.g. IDirectDrawSurface7::Blt, IDirect3DDevice9::StretchRect and ID3D11DeviceContext::CopySubresourceRegion methods for the evolution since the DOS days. You can also do a lot of 2D operation by drawing textured quads + fragment shaders. On the GL side you have glBlitFramebuffer and glCopyImageSubData. That said, GDI and other old 2D APIs have features that don't really exist in modern 3D. Bitwise operations like XOR when copying images for example. Bezier curves can nowadays be done with tessellation shaders, but for a long time this was something always done in the CPU. Text rendering is tricky too. A "simple" way was to generate a texture atlas on the CPU and then just blit characers, although I think some UI frameworks can nowadays use the GPU to render TrueType fonts. It is a can of worms though, even in Windows 3 - if you want to have fun, install the Hebrew or Arabic version of Windows 3.11. A problem with trying to do 2D on the GPU is also that data transfers between the CPU and GPU are slow, in particular GPU->CPU. If you have software fallbacks that force you to read back GPU memory you are likely to lose any GPU rendering advantage. Applications also like to muck with direct framebuffer access, something modern 3D APIs really don't like. |
|
Oh I wasn't thinking winelib, just using the Windows version of Dosbox under Wine! Yeah, I figured modern cards would still have usable blitters, but of course that makes sense that they only do transfers, not ROPs! Indeed, the GPU-CPU transfer speeds are unacceptable, which is why I waited to get CPU double buffering working properly before I published the driver! 🙂 |
Hi!
This is a really incredible project you're working on, and it has caused quite some enthusiasm in the retro computing community.
Have you also considered adding (optional) support for the VBE/AF extensions for 2D hardware acceleration?
Admittedly, this extension didn't gain a lot of adoption due to it being introduced so late to the market, and very few (if any?) video cards and GPUs have built-in support for it in their BIOSes.
But both Scitech Display Doctor and the open source FreeBE/AF project have implemented support for this extension for a number of graphics cards. Although none of them are recent GPUs, adding support to the vbesvga driver might also encourage people to add VBE/AF support for newer GPUs to FreeBE/AF, as well as the paravirtualized client drivers of some popular hypervisors.
It might also be fun to add this from a "completion" perspective.
Thanks for considering, and thanks for developing and sharing this driver in the first place! 😃
The text was updated successfully, but these errors were encountered: