VBE and other possible graphics hardware interfaces

[CodeCat]

I get the feeling just about everyone here who's done graphics beyond VGA has done it using VBE. But my main issue is that at least VBE 2 requires dropping into real mode for a VBE call. Personally, I think that's just ugly, and I'd like to avoid real mode if at all possible. VBE 3 supports protected mode calls I believe, but I'm not exactly sure how strong support for VBE 3 is (despite that it's 10 years old). Ideally I'd be able to write 'direct' interfaces to the hardware, like what commercial graphics card drivers do, but that's not possible without specs of course. So I have a few questions...

- Is VBE 3 really the way to go when it comes to graphics programming? What do you use?
- Is it 'safe' to assume support for VBE 3 exists?
- What alternatives and standards are there beside VBE?
- Is there any amount of hardware acceleration that is accessible regardless of manufacturer/card? Or is this still the holy grail it seems to be?

[JohnnyTheDon]

For hardware acceleration that isn't device specific, take a look at VBE/AF. Just google for the specs and you'll find them. It allows for basic 2D acceleration, but I'm willing to bet its even less supported than VBE3,

As for using graphics cards in native mode, I imagine that Intel gives out data sheets for all its onboard graphics. NVIDIA and ATI don't (because they don't want patent holders to know they're being ripped off), but there are closed source linux drivers for each. There are also open source projects attempting to make drivers for the two vendors.

Nouveau ( http://nouveau.freedesktop.org/ ) is a project to make an NVIDIA driver w/ hardware acceleration. They have pretty much succeeded with 2D acceleration. By using their source code, you will be able to switch an NVIDIA card into native mode and change the resolution, among other things.

As for ATI, xorg (who makes X server) has a driver and development. You may want to look that up for ATI card support.

[Love4Boobies]

As for using graphics cards in native mode, I imagine that Intel gives out data sheets for all its onboard graphics. NVIDIA and ATI don't (because they don't want patent holders to know they're being ripped off),

AFAIK, ATI started releasing data sheets for their cards.

[JohnnyTheDon]

You're right: http://www.theregister.co.uk/2008/12/31 ... e_3d_code/

Its very recent. You picked a good time to ask this question.

[quok]

For hardware acceleration that isn't device specific, take a look at VBE/AF. Just google for the specs and you'll find them. It allows for basic 2D acceleration, but I'm willing to bet its even less supported than VBE3,

I'll second that about VBE/AF, but consider it circumstantial. I remember reading somewhere that VBE/AF wasn't very well supported at all, but I don't recall where. It was probably a post by Brendan, Candy, or Combuster somewhere on here.

About VBE3, though... I recall also reading somewhere (again, most likely a post on here somewhere) that all modern ATi and Nvidia cards (maybe even Intel cards) support VBE3 fairly (if not very) well.

As for using graphics cards in native mode, I imagine that Intel gives out data sheets for all its onboard graphics. NVIDIA and ATI don't (because they don't want patent holders to know they're being ripped off), but there are closed source linux drivers for each.

Intel does in fact give out datasheets for their graphics cards, and they've even got some rather good information in them as far as working with the 3D chip in the cards. As previously pointed out, ATi also releases datasheets now. You should be able to find them on AMD's website somewhere, but they're also available somewhere on either x.org or freedesktop.org.

[Love4Boobies]

Unfortunately, not the same can be said about VIA. They just released some register information. No hardware acceleration, no nothing...

[quok]

Unfortunately, not the same can be said about VIA. They just released some register information. No hardware acceleration, no nothing...

Well, not every company can be as great as Intel and AMD.

[Brendan]

Hi,

AFAIK both AMD and VIA released (not necessarily well documented) register information and an open source driver for Linux. Intel did the same, but Intel's register information includes lots of documentation. There's also some information for a few older cards around (Cirrus Logic, S3, 3dfx/voodoo).

Unfortunately, even with the best possible documentation modern video cards are extremely complex; and it'd take an extremely long time to write a "full featured" device driver just for one video card. Basically, IMHO writing a full featured video driver isn't practical unless you've got lots of video driver experience beforehand.

The real mode interface for VBE (all versions) work fine (but not in protected mode), and it's relatively easy to write code that uses any information it can get (e.g. supports all versions of VBE at the same time). The protected mode interfaces for VBE often aren't supported.

VBE/AF wasn't great when it was released, and VESA tried charging a huge amount of $$$ for a copy of it, so nobody ever implemented anything for it (no support in almost all video cards; and almost no software that would've used VBE/AF if video card manufacturers bothered).

The last option is to program the card as if it's a "standard VGA". This works on lots of cards, but all the video modes have low resolution and/or poor colour depth, and there's no hardware acceleration.

My advice (in order of implementation):

• Setup a video mode using VBE during boot (while you're still in real mode) and try to get DDC/EDID information during boot too. Then implement a simple framebuffer device driver (where everything is done in software, and you need to reboot to change video modes). Note: Some people spend time implementing virtual8086 mode support (and/or 8086 emulators, e.g. for long mode) so that they can change video modes with VBE without rebooting. To be perfectly honest (for my purposes at least) I think this is a waste of time - the goal should be to have a device driver that supports all features of the video card, and the simple framebuffer driver should be considered a temporary thing that's only used when there's nothing better. Basically, in the long run, your time as an OS developer could be better spent elsewhere.
• After that, write a "standard VGA" driver. Let the user install this driver instead of the framebuffer driver if they want, and keep track of which video cards it works on (and which video cards it doesn't). This still means everything is done in software (no hardware acceleration).
• After that, attempt to write a basic video driver for Intel's video controllers. What you learned from writing a standard VGA driver will help, and it'd be best to start with the controller with the most complete documentation. This still means everything is done in software (no hardware acceleration).
• Then, either write basic drivers for other video controllers, or turn the existing basic video drivers into full featured video drivers (starting with Intel's due to better documentation). Note: Once you've got a basic video driver or a full featured video driver for one video card, it should be relatively easy to modify that video driver to support similar video cards (e.g. video cards from the same manufacturer, where "version X" is only slightly different from "version X+1").

The most important thing is the software interface between the video driver/s and other software (e.g. the GUI). This needs to be designed well, with all sorts of things in mind (e.g. hardware acceleration, hardware cursors, device independent shader language and tools/compiler, stereoscopic 3D glasses, 3D layered LCD screens, multiple monitors, multiple video cards, etc). The last thing you want to do is spend years implement device drivers, GUIs, etc; and then realize that the video driver interface you're using isn't adequate and that you need to go back and redesign everything.

Also, sooner or later you'll need to start maintaining a hardware compatibility database. This could be as simple as a text file that says if each piece of hardware works or not, and what level of support there is (e.g. if the driver supports everything, or only some things); but it could be a more complex thing, like a web site with a MySQL back-end with the ability to find contributing factors (e.g. "video card X works unless it's used with chipset Y") and (optional) automated feedback sent from the OS.


Cheers,

Brendan

[Dex]

The PMode interface using vesa3, is a 16bit pmode interface, which rather makes it no better than realmode as far as the programmer is concerned.

[CodeCat]

It does a bit, because it doesn't put your system in anarchy-mode. 16-bit PM is still PM, so you can still use segments to limit what the code can access.