As the article indicates, they're similar to ioctl, which is a system call that, roughly speaking, allows arbitrary opaque blobs of data to be passed back and forth between a user-mode -process and a kernel-mode driver. This is intended as a generic mechanism allowing drivers to expose arbitrary functionality to user-space. This enables the implementation of functionality that would not otherwise be possible because it was not foreseen and enabled by the design of the operating system.

Bear in mind that the system call ABI changes slowly and with much difficulty: once a version of a kernel is in production, it can stay in use for a long time; it can take a long time for new functionality to be broadly available, and breaking back-compat with applications compiled against older ABIs is Not Done. Dynamically loadable kernel modules and ioctl-like system calls make it much easier to bring new functionality to all the various kernels running around in the real world.

Given the complexity and rate of change in graphics tech, it makes perfect sense for there to be a general-purpose arbitrary functional-call mechanism for interaction between user-mode and kernel-mode graphics driver components. Microsoft (or the linux graphics subsystem maintainers, etc) just doesn't know enough about Nvidia/AMD's current and future requirements to nail down a more rigorously defined API.

Thanks, I know nothing about this level of programming but this gives me a lot of good stuff to google.

It is very similar to an ioctl on Unix (DeviceIoControl on Windows), just specific to the Display/Video driver here. It is a way to send arbitrary data from usermode into kernelmode, for whatever reason.

You can imagine the usermode interface as:

    void escape(int command, void *param);

And then the kernelmode implementation would look something like:

    void escape(int command, void *param)
    {
        switch (command)
        {
            case COMMAND_FOO:
                do_foo((foo_param_t *)param);
                return;
            case COMMAND_BAR:
                do_bar((bar_param_t *)param);
                return;
        }
    }

The driver defines the params and what FOO and BAR are. This can be used to issue special commands that don't have an interface provided by MSFT. It is also used by any drivers that run in usermode (e.g. OpenGL, CUDA, etc) that communicate directly with the kernelmode ones. These interfaces are generally not public. The project zero researcher has disassembled the kernelmode driver and reverse engineered their format.

Does that help?

Definitely, thank you for the psuedocode examples!

It is pretty much just the name for their API.