
Why Command and Vector Processors Rock - kayamon
http://www.codersnotes.com/notes/command-and-vector-processors/
======
sitkack
This is one thing that amazed me about early mainframes, the hardware was the
API. It was designed to be used, not abstracted over and cleaned. In the
modern world each abstraction layer fixes problems of the layer below,
exposing its own flaws that are fixed by the layer above. With exokernels,
nanokernels, picokernels and unikernels mabye we can get some of these
qualities back. If an abstraction because pervasive enough, then we can make
hardware that implements the abstract hardware interface.

~~~
digi_owl
Not likely, because the base idea of those "kernels" is for them to drive the
VM performance envelope closer to that of a container.

~~~
e12e
Isn't that a core idea of mainframes too?

~~~
sitkack
Some of this has been achieved via widely used PCIe devices, those control
registers are now a defacto standard for talking to the outside world.

------
slededit
The evolutionary growth of the PC platform provided for some powerful things.
But we've lost a bit of the "engineered system" principle in the process.

Like the Apple II I suspect such an integrated system was a pain to expand.
There were later Amiga OSs so perhaps this was possible, but I don't know how
well they maintained compatibility with original programs.

~~~
Annatar
As long as one programmed through the OS API, things were guaranteed to work.
Even the AGA CustomChips were backwards compatible with ECS, just as ECS was
backwards compatible with OCS: the addresses were the same, and so were the
control / function bits in them. Newer ChipSets simply added additional
CustomChip registers. The biggest source of incompatibility on the Amiga were
the processors, as newer ones introduced instruction and data caches: software
which used self-modifying code, a concept taken over from the C=64 would crash
instantly due to cache being out of sync with memory.

Hardware expansion was and remains a breeze with the AutoConfig protocol and
the Zorro-II and Zorro-III expansion buses. Many people run their Amigas with
additional sound and graphics cards. There are even PCI bridge expansion
cards.

~~~
slededit
My main concern is that if you have a publicly documented chip that explicitly
concerns itself with timing it makes it very hard to shave off cycles in the
future.

The Apple IIhad similar problems. Woz moved a lot of stuff to software to save
chips but it causes compatibility issues in the future.

------
digi_owl
I can't help wonder if this is the root of the schim forming around Linux.

Where more developers, and more and more "admins" are less than interested in
the underlying hardware, because all they see during the day is piles upon
piles of VMs and containers that abstract away the actual hardware being used.

And then there is a dwindling group of people with at least a token interest
in the hardware, but they are either being ignored or ostracized by the
abstract software people.

~~~
pjmlp
That is a side effect of the UNIX culture, because the hardware doesn't matter
as long as you have C and POSIX.

Even OpenGL and audio APIs made it so that most of the time the cards you have
plugged are irrelevant.

Being a old timer, which also has spent quite a few time with Amiga users/devs
back in its golden age, it took me a few years to realise, that in what
concerns desktop graphics programming, macOS and Windows communities are much
more welcoming than UNIX focused ones.

You see this quite clearly on macOS, those that came from Mac OS days (pre OS
X) focus on UI/UX and the whole experience as a dev taking advantage of an
unified software/hardware stack.

Those that came from BSD/Linux just use CLI tools as if they were in any other
UNIX.

Which is one reason why the demosscene never thrived on GNU/Linux.

~~~
digi_owl
I think it has less to do with C and POSIX, and more that Unix from day one
was multi-user, you can't have someone "bitbang" hardware when there are
multiple users accessing.

Also, i think perhaps you conflating issues here.

While sure they may be more interested in the GUI (though you will find plenty
of TUI programs in the Unix world, and even some in Windows that has been
inherited from DOS) the newer generation is less likely to be interested in
the actual hardware beyond that it works to run their precious "apps".

And IMO the demo scene were largely "dead" by the time Linux come on stage
anyways.

This because the fixed hardware models of the C64 and like were being
supplanted by the mix and match PC, where the only commonality is the BIOS and
the CPU ISA.

~~~
pjmlp
The demoscene is pretty much alive, here are some 2017 events.

[http://www.assembly.org/summer17](http://www.assembly.org/summer17)

[https://2017.revision-party.net/](https://2017.revision-party.net/)

[https://www.evoke.eu/2017/](https://www.evoke.eu/2017/)

[https://nordlicht.demoparty.info/](https://nordlicht.demoparty.info/)

[http://outlinedemoparty.nl/](http://outlinedemoparty.nl/)

And some info about upcoming parties,

[https://www.demoparty.net/](https://www.demoparty.net/)

[https://demozoo.org/](https://demozoo.org/)

------
rwallace
OP says you can't access the command processor on a modern GPU, but I thought
that changed recently, now you can program the GPU hardware?

[http://gpuopen.com/amd-vega-instruction-set-architecture-
doc...](http://gpuopen.com/amd-vega-instruction-set-architecture-
documentation/)

Am I missing something, or is OP just a little out of date?

~~~
kayamon
Shader ISA != command processor

~~~
rwallace
So you're saying the open ISA still doesn't allow access to the command
processor? What sort of things does that preclude? Suppose you decided to
write a game directly to the hardware instead of via DirectX or OpenGL, or a
molecular dynamics simulation directly to the hardware instead of via CUDA,
what would happen?

~~~
kayamon
If you tried to do it directly, you'd a) find it very hard as it's largely
undocumented, and b) it'd probably break when the vendors decide to change it
without warning on their new GPUs.

As for applications, well I dunno. One particular example would be Render To
Vertex Buffer, something that ATI cards used to expose an extension for but
NVidia cards didn't. Even though basically _any_ GPU could do it if the driver
decided to.

A better use would be to allow the GPU to read the game's scene structure
directly without even needing an API in-between.

------
monocasa
To be fair, Vulkan/Mantle/DX12 and pretty much every console's API is a _very_
thin wrapper around the command buffer.

Like on Nintendo consoles the graphics commands tend to just be a macro to
write an opcode and bump a pointer.

Xbox canonicalized this kind of management in their API as "push buffers".

Vulkan /Mantle/DX12 all have 'queues' which are just a memory centric view of
the command processor.

~~~
kayamon
I wasn't suggesting a way to write your own command buffers, but instead a way
to write your own code that _reads_ those command buffers on the GPU side.
(running on the GPUs command processor)

