OSDev.org

Hi,

Rusky wrote:

Brendan wrote:Basically; for graphics; it should never be a question of "will it work" and should only ever be a question of "how well does it work" (frame rate, graphics quality). That can not happen because the abstraction isn't abstract.

By that logic, programs should never be allowed to rely on CPU-side hardware features either.

This is (part of) what high level programming languages have been trying to do for about 60 years (abstract low level details of the underlying CPU so high level code is portable to different CPUs).

Rusky wrote:But go ahead and try to design a graphics API that accepts the sorts of assets we see in AAA games today and produces something at all useful on a fixed-function pipeline from the 90s- I'll wait.

Why wait? It's trivial to design a graphics API that does this and you could do it yourself.

Regardless of how the graphics API is designed; the hard part is always implementing drivers that support GPUs and/or getting acceptable quality graphics with the "performance challenge" of software rendering.

The fact is you don't even need a new graphics API for this. You could (e.g.) implement DirectX12 in software (including emulating a modern GPU in software) and make the exact same assets we see in existing AAA games work on an ancient CGA card (just with worse quality/resolution/colour depth and far worse frame rate).


Cheers,

Brendan

Brendan wrote:This is (part of) what high level programming languages have been trying to do for about 60 years (abstract low level details of the underlying CPU so high level code is portable to different CPUs).

Yep. Same goes for e.g. Vulkan, which specifically abstracts the differences between desktop and mobile GPUs so we no longer need separate OpenGL and OpenGL ES APIs.

Brendan wrote:

Rusky wrote:But go ahead and try to design a graphics API that accepts the sorts of assets we see in AAA games today and produces something at all useful on a fixed-function pipeline from the 90s- I'll wait.

The fact is you don't even need a new graphics API for this. You could (e.g.) implement DirectX12 in software (including emulating a modern GPU in software) and make the exact same assets we see in existing AAA games work on an ancient CGA card (just with worse quality/resolution/colour depth and far worse frame rate).

You missed the part about being "at all useful."

Hi,

Rusky wrote:

Brendan wrote:This is (part of) what high level programming languages have been trying to do for about 60 years (abstract low level details of the underlying CPU so high level code is portable to different CPUs).

Yep. Same goes for e.g. Vulkan, which specifically abstracts the differences between desktop and mobile GPUs so we no longer need separate OpenGL and OpenGL ES APIs.

Brendan wrote:

Rusky wrote:But go ahead and try to design a graphics API that accepts the sorts of assets we see in AAA games today and produces something at all useful on a fixed-function pipeline from the 90s- I'll wait.

The fact is you don't even need a new graphics API for this. You could (e.g.) implement DirectX12 in software (including emulating a modern GPU in software) and make the exact same assets we see in existing AAA games work on an ancient CGA card (just with worse quality/resolution/colour depth and far worse frame rate).

You missed the part about being "at all useful."

I find the irony here quite humorous.

First you say that (e.g.) Vulkan abstracts the differences between different video cards, then you say that modern AAA games (using APIs like Vulkan and DirectX12) can't work in a useful way for some different video cards (fixed function pipeline).


Cheers,

Brendan

Just like your OS can't work in a useful way for some CPUs (without an MMU).

Trying to support fixed-function pipeline is like trying to support real mode on x86. It had its uses, but it's just not capable of doing the kinds of things we want to use GPUs for today.