vesa. vga, graphics in general

[albeva]

I am doing research on how to enable gfx in my OS.

What I keep finding is that VESA support is not reliable. Non-complete/broken implementations, support for only old versions ...(1, 1.2, 2) , or lacking alltogether.

Nice idea of VBE/AF (accelerated blitting, ...) was only ever implemented by handful of cards so the very thing is utterly pointless.

The way I see it the only way to go is either vga or try to figure out proprietary interfaces?

Where could I find more information about this? And what gfx standard could be useful?

[Brynet-Inc]

Not all graphics cards are mysterious black boxes, recent ATI/AMD cards are documented.. including the 3D acceleration.

Intel and Via also have documentation, or at least open source reference drivers....

The only manufacture holding out these days is NVidia.

http://developer.amd.com/documentation/ ... x#open_gpu
http://www.x.org/docs/AMD/ (Mirror of above..)
http://www.intellinuxgraphics.org/documentation.html
http://www.x.org/docs/intel/ (Ditto....)
http://linux.via.com.tw/ (It's slow, under the "Document" column you'll eventually find a PDF document for various chipsets..).
http://www.viaarena.com/default.aspx?Pa ... CatID=2580

So, that's what I've found for documentation... another resource is the existing Xorg drivers for modern cards.

This has all be discussed before, search the forum archives..

[Brendan]

Hi,

What I keep finding is that VESA support is not reliable. Non-complete/broken implementations, support for only old versions ...(1, 1.2, 2) , or lacking alltogether.

In my experience, most modern video cards do support VBE 2.0, and you can get by with VBE 1.x if you don't need the protected mode interface (e.g. if you set a default video mode during boot while you're in real mode, and leave the default video mode alone unless the OS has a proper video device driver).

Nice idea of VBE/AF (accelerated blitting, ...) was only ever implemented by handful of cards so the very thing is utterly pointless.

The way I see it the only way to go is either vga or try to figure out proprietary interfaces?

VGA doesn't have accelerated blitting or anything either.

And what gfx standard could be useful?

Honestly, all of the "standards" are temporary solutions - something you put up with because you don't have a decent video driver for the specific video card.

Decent video drivers are the only long term solution, but it's also the most painful/complex solution.

IMHO there is only one easy way to do it - setup a default video mode during boot and design a good video driver interface (and maybe implement things like 3D textured polygons and fog in software, so the video driver interface works and so that there's example code people can use as a reference), then let other people write the video drivers later on...


Cheers,

Brendan

[Jeko]

Nice idea of VBE/AF (accelerated blitting, ...) was only ever implemented by handful of cards so the very thing is utterly pointless.

The way I see it the only way to go is either vga or try to figure out proprietary interfaces?

VGA doesn't have accelerated blitting or anything either.

There is the standard VBE/AF. This standard allows the use of graphic cards' accelerated functions using graphic interrupt (0x13) or VBE Protected Mode Interface.

[Brendan]

Hi,

Nice idea of VBE/AF (accelerated blitting, ...) was only ever implemented by handful of cards so the very thing is utterly pointless.

There is the standard VBE/AF. This standard allows the use of graphic cards' accelerated functions using graphic interrupt (0x13) or VBE Protected Mode Interface.

I think you'll find Albeva's original comments are mostly correct - there's very little reason to bother with a standard that most cards never supported.

Maybe it might be worth worrying about if you can actually find some video cards that do support it; but IMHO even if all video cards supported VBE/AF it'd still be a short term solution (something to use when you don't have a decent video driver for the specific video card) because the list of features supported by VBE/AF looks more like a list of "lowest common dominator" features from a decade ago and doesn't represent the current state of the art (and more importantly, won't represent the future state of the art that OS developers should be considering).

To be more specific, here's a quote from the newest version of the VBE/AF specification I have (which was written 12 years ago):

Why have you implemented only a small set of functions?

The VBE/AF functions have been boiled down into the smallest possible set of accelerator functions that can be implemented as efficiently as possible and are the most commonly needed by application software. When an application calls the VBE/AF device driver routines, it will already have performed any kind of application specific special casing necessary.

What they really mean here is that there's no fog, no volumetric smoke, no lighting, no shader, no alpha blending, no anti-aliasing, no support for 3D displays (shutter glasses, layered LCD, etc), a poor 3D co-ordinate system (imprecise 32-bit co-ordinates that'd cause errors and glitches after transformations are done due to rounding, overflow, etc), no Z-buffer access (no way to implement something like fog in software), crappy hardware cursor image format (fixed "32 * 32 pixels" size that's guaranteed to look too small in high-resolution video modes and too large in low-resolution video modes, that uses AND and XOR masks - no alpha blending or anti-aliasing again), no way to find out which texture the mouse "hot spot" is on top of (insanely painful if you want to find out what the user clicked the mouse on), and most of the primitives that are covered by the specification are *optional* anyway.

Perhaps there's good reasons that none of the video card manufacturers bothered supporting it...


Cheers,

Brendan

[Jeko]

Hi,

I think you'll find Albeva's original comments are mostly correct - there's very little reason to bother with a standard that most cards never supported.

Maybe it might be worth worrying about if you can actually find some video cards that do support it; but IMHO even if all video cards supported VBE/AF it'd still be a short term solution (something to use when you don't have a decent video driver for the specific video card) because the list of features supported by VBE/AF looks more like a list of "lowest common dominator" features from a decade ago and doesn't represent the current state of the art (and more importantly, won't represent the future state of the art that OS developers should be considering).

To be more specific, here's a quote from the newest version of the VBE/AF specification I have (which was written 12 years ago):

Why have you implemented only a small set of functions?

The VBE/AF functions have been boiled down into the smallest possible set of accelerator functions that can be implemented as efficiently as possible and are the most commonly needed by application software. When an application calls the VBE/AF device driver routines, it will already have performed any kind of application specific special casing necessary.

What they really mean here is that there's no fog, no volumetric smoke, no lighting, no shader, no alpha blending, no anti-aliasing, no support for 3D displays (shutter glasses, layered LCD, etc), a poor 3D co-ordinate system (imprecise 32-bit co-ordinates that'd cause errors and glitches after transformations are done due to rounding, overflow, etc), no Z-buffer access (no way to implement something like fog in software), crappy hardware cursor image format (fixed "32 * 32 pixels" size that's guaranteed to look too small in high-resolution video modes and too large in low-resolution video modes, that uses AND and XOR masks - no alpha blending or anti-aliasing again), no way to find out which texture the mouse "hot spot" is on top of (insanely painful if you want to find out what the user clicked the mouse on), and most of the primitives that are covered by the specification are *optional* anyway.

Perhaps there's good reasons that none of the video card manufacturers bothered supporting it...

Yes, you are right. I was only saying that the standard exists, it isn't really usable, but it exists.

[Brynet-Inc]

Yes, you are right. I was only saying that the standard exists, it isn't really usable, but it exists.

The OP already mentioned it exists.... everyone acknowledges at least that, but no graphics cards support it.

So, what was the point of your post?

[Dex]

I agree fully with Brendan, the only way to do it, is to use vesa 2 LFB and write you own "3D textured polygons and fog in software", also make sure you have a good driver interface, so when the times right people can code drivers.
Theres alot you can do to speed up using vesa eg: setting MTRR to write combine will give you something like a 40% increase in FPS in my tests.

Much better is to all on this forum get togeather and have a small compo, to see who could get the most FPS from a pease of code that just dump a buffer to screen (in a loop) in a set vesa mode.
Just for starters.
If anyones interested, i will post the code.

[kmtdk]

Well dex,
i havn't programmed in vesa, but i would like to.
for 2 reasons:
optimising execises ( i love to optimise pre written code)
for knowledge.

KMT dk

[albeva]

Maybe it would be interesting to set up a project dedicated to develope free to use gfx device interface and say vesa/vbe and vga driver implementations.

I understand some of it would be complicated due to fact that everyone's kernel is different and people have different ways of accomplishing things. However there is this http://www.jamesmolloy.co.uk/edi/ taht could be perhaps used and extended accordingly.

It could potentionally benefit many people here.

EDIT: and this could mean that with time people could start contributing "real" drivers for different cards and eveyone using the interface could benefit

[Dex]

OK, give me a day or two and i will post the test code, so we can see who can get the best vesa FPS.

[Brendan]

Hi,

Much better is to all on this forum get togeather and have a small compo, to see who could get the most FPS from a pease of code that just dump a buffer to screen (in a loop) in a set vesa mode.

That'd be a good way to test the bus bandwidth of various computers/video cards, but otherwise it won't tell you much. IMHO getting data from RAM into video display memory is the least interesting part of it - you can only really tweak AGP and MTRR settings (or the Address Region Registers on a Cyrix, or the Memory Configuration Registers on an IDT/Winchip) and make sure you transfer the data efficiently - REP MOVSD/MOVSQ, or maybe using SSE (see note).

Note: For SSE the general method involves PREFETCH, load, non-temporal store and CLFLUSH. The CLFUSH is to avoid polluting the cache and won't make any difference in a "dump data to display memory as fast as you can" benchmark. The non-temporal store isn't worth bothering with if the destination address is setup for write-combining (or "write gathering" on Cyrix, or "store combining" on IDT/Winchip) anyway, or if the destination address is "uncacheable". The prefetch is to avoid delays getting the data into the CPU, but that won't help much here because getting the data out of the CPU will be the bottleneck (and the CPU's hardware prefetcher will start after the the first few sequential cache line reads).

Much more interesting to me would be code to generate the graphics data (including all the tricky 3D stuff) that keeps track of dirty rectangles or something so that you only need to copy data that changed to video display memory (instead of blindly copying all data including unchanged data to display memory); that also keeps track of when the video was updated and skips some frames completely (e.g. if there's several frames to be done, only display the most recent frame and don't do any processing, etc for the previous/obsolete frames).


Cheers,

Brendan

[Jeko]

everyone acknowledges at least that, but no graphics cards support it.

My graphic card support VBE/AF

That'd be a good way to test the bus bandwidth of various computers/video cards, but otherwise it won't tell you much. IMHO getting data from RAM into video display memory is the least interesting part of it - you can only really tweak AGP and MTRR settings (or the Address Region Registers on a Cyrix, or the Memory Configuration Registers on an IDT/Winchip) and make sure you transfer the data efficiently - REP MOVSD/MOVSQ, or maybe using SSE.

I wrote code to handle vesa drawing (line drawing, blitting, etc., but no 3D code) and with SSE or MMX the blitting was really really faster... There was a really big difference. I think at least 10 times faster!

[jal]

My graphic card support VBE/AF

And now it would be interesting to know what video card you have.


JAL

[Jeko]

My graphic card support VBE/AF

And now it would be interesting to know what video card you have.


JAL

NVIDIA GeForce 6600