I worked on the Linux graphics system some years ago, in a previous job.

I can point you to a comment I posted about a similar question in another thread. Quoting myself :

acl wrote on 2023-05-05, 17:18:

I don't know how it works on Windows. But i worked on the Linux graphic stack in a previous job. I can risk a guess, but not 100 […]
Show full quote

Ozzuneoj wrote on 2023-05-05, 02:50:

I remember doing this for both audio and video acceleration, and in many cases it worked... though there were usually some compromises.

Does anyone here actually know what these sliders do?

I don't know how it works on Windows. But i worked on the Linux graphic stack in a previous job.
I can risk a guess, but not 100% sure.

On Unix/Linux, X.Org is a display server. Simplified, it has access to physical devices (screens/keyboard/mouse).
The display server listen for incoming connections (tcp or local socket).
The applications that must draw stuff connects to the display server. In standard desktop usage, the application connects to the display server running on the same machine.
The application send draw orders through this connection, using a protocol called X11. Orders like "create a window, draw a line or an image inside". But also more complex orders, like "blend this font with the background using alpha compositing".

When the server displays this on the screen, it must talk to the physical device : graphics card.

In the context of 2D graphics :
Roughly, in the un-accelerated mode, the CPU draws pixels one by on in the framebuffer.
In accelerated mode, the operations are drawn by the card itself. And the card often have magic tricks to accelerate things like drawing rectangles, filling a zone with a defined pattern. Line from point x0-y0 to x1-y1.
For example, a common optimization is copy the framebuffer content from here to here, when a window is moved on screen. (instead of clearing and re-drawing).

Moving the "Acceleration" slider down on Windows probably reduce the number of magic tricks used to draw stuff.
Less things handled by the card, more by the CPU. Less dependant on the card and its drivers, more dependant on the CPU.

See here for code example (for mach64 solid rectangle fill): https://gitlab.freedesktop.org/xorg/driver/xf … h64accel.c#L565
The driver talks to the card and asks it to draw a rectangle. The CPU could have done it by itself by accessing the framebuffer pixel by pixel. But this would have been much slower.

This comment answer was more about windows acceleration, but some features could probably be used in another context .
My starting point would be to read the code of Linux accelerated drivers to know how to use these proprietary commands.

This YT-channel might interest you: Bits inside by René Rebe. He has several videos about coding directly for specific VGA cards. Like e.g. Bare metal hardware 3d texturing in 23kb of code w/ S3/Virge!

From what I've seen in his videos I think it's not worth the hassle and it's better doing everything on the CPU. At least when it's about 3D graphics (before the Voodoo)

It's worth looking at the VESA VBE/AF standard, later renamed FreeBE/AF; it was really the only standard API for accelerated access to GPU hardware on DOS, but it was right at the end of the Dos era so didn't really take off.

SaxxonPike wrote on 2023-08-10, 17:15:

manufacturers of VGA cards had drivers specifically written for them that maybe took advantage of features specific to a model or line of products (cards from Trident

deff no

>S3

garbage, but if you really want to there is low level documentation. This and related videos in this channel might be interesting
Acceleration code working on real S3 Virge/DX! already suspected a silicon bug!! 😒 https://www.youtube.com/watch?v=Hsg1N4IqXac
How 3D acceleration started 20 years ago: S3/Virge register level programming! https://www.youtube.com/watch?v=fXJ11_wG_0U
edit: just noticed HanSolo linked same thing 😀

SaxxonPike wrote on 2023-08-10, 17:15:

How much of a hassle do I avoid by making BIOS calls instead?

zero, because bios interface doesnt support any of advanced 2d/3d functions

SaxxonPike wrote on 2023-08-10, 17:15:

I am interested in SDKs for all this regardless.

back in the day you would use middleware, for example sound was usually handled with Miles Sound System https://en.wikipedia.org/wiki/Miles_Sound_System or https://doomwiki.org/wiki/DMX

megatron-uk wrote on 2023-08-10, 21:03:

It's worth looking at the VESA VBE/AF standard, later renamed FreeBE/AF; it was really the only standard API for accelerated access to GPU hardware on DOS, but it was right at the end of the Dos era so didn't really take off.

yeah, nothing used it, afaik not a single game