SIGMA GL/2 (aka SGL, SIGGL) is a data-oriented C API specification where the common things are (relatively) easy, and the super powerful low-level optimizations are optional.
The idea behind its proposal was the development overhead of Vulkan API being absolutely insane when we tried to move from OpenGL to Vulkan in our recent works. There were several helper functions to produce a minimalist usable library that made Vulkan a lot productive, which became effectily an other middleware. After several deployments in Vulkan, the SIGMA Technology Group, the technology arm of SIGMA Federation, pushed by graphics programming community, started development a new API: the purple side of the force.
This new API was firstly idealized to be easy as OpenGL but still trying to be powerful close to Vulkan, Direct3D e Metal. Another Glide? But don’t think we are just creating a wrapper around them.
Qwadro Video Graphics Infrastructure
Draw I/O System, a modulation of Qwadro Execution Ecosystem, is the first implementation of the SIGMA GL/2 API specification. It is also developed by SIGMA. You can install custom device drivers in Qwadro, like in early days of computer graphics where you could download and install device drivers directly in root directory of your application. These custom device drivers obviously will be wrappers. But you can write your own so no relying on the only driver to X platform or Y API. Could have even drivers using combined physical devices at once.
Why custom device drivers? Well. You see. Vulkan started suffering of same issues than OpenGL suffered in past. Vulkan runs over wrappers in Metal, for example. For presentation, Vulkan relies on Direct3D 12 swapchains on Windows.
Old APIs such as Direct3D 9 and OpenGL also runs over wrappers in some recent versions of some IHV drivers. WebGL (almost unnecessarily) runs over wrappers. WebGPU runs over wrappers. These wrappers seems several bugs and issues due to IHVs being negligent. In the end, almost everything will run in wrappers.
In SIGMA GL/2, devices are virtual. You probably will not seen the name of your GPU there, but a custom name. Wrappers broken the concept of handling a real device, so we adopted it as a fact.
The first (standard) implementation of SIGMA GL/2 is strongely inspired on paradigms of that was supposed to be OpenGL 5. This is an effort by SIGMA to offer a high-performance real-time 3D drawing API. SIGMA chose a different approach with SIGMA GL/2: introducing its own abstractions and not directly mirroring any of today’s native APIs. One reason is because no single API is available on all systems, and also because many concepts (such as extremely low-level memory handling) are not idiomatic to users not accustomed to the heat of metal.
Although certain features inherited from (3dfx Voodoo) Glide API, they have been reworked to look more like Vulkan. And also most of the dialect of SIGMA GL/2 is inherited from the OpenGL/Vulkan side of the force, becoming the purple side (blue + red).
An example of abstraction in SIGMA GL/2 is the lack of an object known as a “framebuffer“. The framebuffer is a problematic name for its concept of operation where there is no actual buffer and it was a name inherited from the hardware. Due to this, in Qwadro, its pseudo-equivalent is a “canvas”, which is an object that handles an arrangement of surfaces, capable of being bound with rasters (de facto, the buffer), where a drawing is made.
As aforementioned, SIGMA GL/2 works on the “bring your own driver” model. Seeing Vulkan, OpenGL’s successor, suffer from the same problems that OpenGL suffered in the past when platform holders did not want to have such an API, SIGMA chose to replicate a model from the ancient times of hardware-accelerated computer graphics, where people looked for better driver implementations, including those based on existing common APIs or APIs specific to the installed VGA; the installable client driver (ICD) or, its more minimalist version, the mini client driver (MCD).
SIGMA GL/2 is distributed with the “e2draw.icd” module, which is a reference model for ICD implemented on OpenGL 4 core and taking advantage of 4.x extensions, developed by SIGMA.
Due to several problems in OpenGL architecture, SIGMA GL/2 on Qwadro works in differently of any other API. For every CPU core available in the host platform, SIGMA GL/2 will run a Drawing Processing Unit (DPU).
DPUs are autonomous services, designed as a system on a threading unit, provided by a drawing device for process the lines of execution in Qwadro Draw I/O System. DPUs calls draw input services to perform transhipment of draw workload, process the drawing queues and flushes draw output services.
In Qwadro, threads are virtualized effectively working as fibers. Real threads in Qwadro are abstracted as “thread execution units”. This allow us to better manage host platform resources and consistence across synchronization primitives avoiding several manual sync/lock operations.
Unlike other low-level APIs, SIGMA G/2 follows a rapid application development (RAD) philosophy, where it delivers several utilities to speed up and automate operations, still allowing the user to do it their own way if they want.
SIGMA GL/2 tried and will keep trying to match the OpenGL conventions or, when not existing, the Vulkan conventions.
The default pixel format will probably be ARGB (as known in LE as, BGRA) why it is faster.
And the image data origin will continue to be left-bottom-near (even it being weird for work in video ops) why it makes sense going up in positive Y and right in positive X and far in positive Z, preserving consistence to the right-handed coordinate system.
Also, in SIGMA GL/2, the triangle front facing is counter-clockwise (CCW).
Why happened to “GL/1”? Flopped. There were several problems inherited from RenderWare way of doing drawing.
SIGMA GL/2 will include a fixed-function video decoder.
To establish the mandatory features in SIGMA GL/2, we grab a ordinary office desktop PC released in 2013, four years before the begining of Qwadro Execution Ecosystem development and we are working with the whole set of features available in OpenGL driver (updated by Intel until 2021) for this machine. By default, this machine garantees full support up to OpenGL 4.0 but it have extensions up to 4.6 (the last one). Things like buffer storage and texture storage are required, for example, when using SIGMA GL/2 over Advanced OpenGL.
Despite driver implementation, Qwadro uses extended OpenGL Shading Language (GLSL) as native shading language.
Special thanks to Markus Tavenrath, Christoph Kubisch, Alfonse Reinheart, Evgeny Makarov and NVIDIA, for contributing their techniques and knowledge in hardware-accelerated 3D design.