A terminal or shell application that is centered around Vulkan

[skilz80]

Since the goal of Vulkan is to be closer to the metal compared to other graphics and compute APIs along with its proposed and upcoming features such as Machine Learning, A.I., Exposing Matrix Multiplication, Ray Tracing, etc., and due to how powerful and versatile it is utilizing multi-core processors and modern GPUs; I was thinking instead of having Vulkan just as an API for some choice named progamming language such as C/C++, C#, Java, Python, etc. that one would write their Vulkan application in; would it be feasible to create a Shell, Console, or Terminal type of application designed at the Kernel level that has its own built in real time Compiler, Linker, and Debugger where Vulkan is at the core of its programming language?

For example if you want to create a VK_KHR_Surface all they would have to do within the shell is type something like: Surface mySurface; and they would have an instance of a VkSurface object, then they can access all of its fields via mySurface.someField = someValue, someFlag or somePointer to some other data structure.

What I’m trying to get at here is that every structure, function call, enumeration and constant within the Vulkan API would be built into the shell’s core language and would be readily available for the user. It would also be considered an intuitive and interactive shell so that when one declares a Vulkan Info or Create type structure they would have a declared and ready variable of that Vulkan type.

Then once they access one of its members such as *.sType and after they enter an = sign after that type’s member the shell would be smart enough to fill in the appropriate enumerated typed for them! As for other fields that have to be populated with values, flags, data structures, etc., such as setting flags, it would give you a scrolled list of the most commonly used flags that are acceptable for that member type.

I believe this would decrease and improve on development time. I’m not suggesting to revert back to OpenGL’s style of hand holding with all the driver signing and checking; I’m only suggesting that the capabilities of the shell would be smart enough to recognize which enumerations belong to said structures and or their members.

The shell would be a customize-able dual window while having the capabilities of having multiple tabs. The idea of of this would be to provide say on the left hand side, your command prompt - text editor while on the right hand side, having on the fly compiler-debugging errors and warnings with suggestions to proper fixes.

The shell could also have interactive controls for independent compiling, linking and debug where one could almost literally modify their code as it is running within its context window. Another possible feature would be to have a built in Rendering Canvas that is separate from the programming interface. This would also render complete objects on the fly once one has the proper amount of code base to draw something tangible.

One should easily be able to write any arbitrary text file for shaders, csv, json, etc. to easily be able to create scripts, batch files and piped type sub programs while having the ability to load them in to their Vulkan program similar to that of Bash, Python, Windows Power Shell, etc.

Another useful built in feature for the shell or terminal would be to compile any acceptable shader language and convert it directly to Spir V either in the shell directly or within the source code. They could for example have something like: use glslangValidator convert shader.vert to shader.spv and it will convert and validate that shader either from the shell directly or within the compiled code. Then they could load that Spir V file on their next available line of code.

Another feature that would be interesting to see is something similar to that of Visual Studio’s Solution Explorer in that it would contain a tree hierarchy of every available Vulkan API call from all of its Structures, Enumerated Types, Constants and Function Calls. It would also populate all possible extensions; however because this shell is intuitive it would grey out extensions that are not supported by the currently installed hardware. What I mean by this is when a user has this shell installed along with the most recent updated version of Vulkan, it will automatically query for the supported physical devices and extensions for that platform and architecture! The shell acquires this information when it is executed or invoked to run on that system. This is a built in feature so that one doesn’t have to worry about creating a Physical device, the shell itself has a privately hidden global physical device that is publicly accessible within the shell-compiler. All of the other extensions would still be in the list and available to use in order to write ported code for other machines but they would not be able to be executed on the current machine unless if some kind of integrated virtual environment is available to enabled one to do so. The tree hierarchy would also give you a brief description of the Vulkan object along with its common uses and a directly hyper link to the specifications and documents page!

If something like this is achievable then one who becomes extremely familiar with Vulkan wouldn’t have to program it in some other language to make an application, they can make a Pure Vulkan Application from a Vulkan Terminal or Shell where Vulkan itself is at the core of the shell’s language. Of course there would still be a general need for basic programming idioms and abstractions such as structs, classes, pointers, arithmetic and logical operations, function calling, namespaces, macros, and possibly even a template system with lambdas and other core concepts that are vital to languages such as C++ including strongly typed data types and to have the ability to have built in threads. I also think it would be beneficial to also fully support the STL, and GLM and to easily import GLFW, SDL and other APIs without having to link them in manually. I think this would be an interesting thing to see.

Some other things that would be beneficial would consist of having the Vulkan Terminal to easily import or integrate different higher level languages’ compilers, so that one could quickly write C++ blocks, C blocks, Python blocks, C# blocks, and even ASM blocks directly into the shell or in their code. Here the Vulkan Terminal would just end up passing your specified language block to the native compiler or interpreter that is installed on your system and it would invoke them to do their job, then after they are done with their tasks, the Vulkan Shell would then be able to take that binary code and either convert it into equivalent Vulkan code or use the binaries directly depending on the user’s and code’s intended use.

Instead of just having Vulkan as programming library or API, how about turning it into its own close to the metal programming language! A language that would have the raw power of ASM, the capabilities and flexibility of C/C++ with the ease of Python while having the ability to integrate any other programming language by invoking their compiler’s or interpreters as long as they are installed on that system.

I believe that this would be a very powerful and versatile programming environment centered completely around Vulkan. Who knows; if something like this came about, then some could take advantage of this and even have the ability to nearly design an Operating System centered around and based directly on Vulkan and its capabilities.

Turning concepts like these into something tangible is how we progress into the future!

[Alfonse_Reinheart]

This suggestion betrays a misunderstanding of where “API” ends and “programming language” begins. For example, let’s take your very first statement:

Surface mySurface;

OK: what does that mean? What is a variable? How much space does it take up? Where does that space come from? Why does it come from there? What can you do with it? And when does it go away?

Vulkan answers none of these questions.

The concept of a “variable” is entirely foreign to Vulkan. Vulkan is an application programing interface, a protocol by which two pieces of code can communicate. It is not a programming language.

As such, the Vulkan specification has no concept of variables, functions (besides the ones it defines), anything you might call a statement (if, for, goto, etc), operators (=, +, etc) strings, number literals, etc. All of those ideas are provided by the language being used to interface with the API.

An API is not something that just becomes a programming language.

Statements like the following also seem to misunderstand APIs:

I also think it would be beneficial to also fully support the STL and glm and to easily import glfw , stl or other APIs without having to link them in manually.

Those are APIs that exist for specific programming languages. For example, “STL” presumably refers to a part of the C++ standard library. Which is part of the programming language called C++. It’s not something that exists outside of C++. It’s designed for C++, using C++ tools and language features, to the benefit of C++ programmers.

Some APIs are not so heavily bound to a particular language. APIs that speak C (like Vulkan or GLFW) can be used by distinctly non-C languages so long as you can get them to speak C.

The project you’re describing will spend 99% of its time on “design a new programming language”; its relationship to Vulkan will be a footnote relative to the amount of work that phrase entails.

At the end of the day, I don’t see how this helps Vulkan’s primary purpose: to create high-performance applications. A new programming language is going to be highly inefficient next to decades-tested, mature compilers for existing languages.

@skilz80

I believe this would decrease and improve on development time. I’m not suggesting to revert back to OpenGL’s style of hand holding with all the driver signing and checking; I’m only suggesting that the capabilities of the shell would be smart enough to recognize which enumerations belong to said structures and or their members.

Vulkan developers do not spend any real length of time dealing with “which enumerations belong to said structures and or their members”. Those are pretty trivial things next to the real issues of developing rendering techniques, optimizing the structure of one’s engine, etc.

[skilz80]

VK_KHR _Surface is a structure with member fields. It doesn’t have to have a necessary size when creating an instance of it. Behind the scenes within the shell’s or console’s programming the concept here is that if you were to declare a Surface object which is a structure with members; the underlying mechanics of the shell would in truth be a pointer to that Vulkan API structure. The memory it requires shouldn’t matter at first as it would be the native size of the pointer on that machine and it would dynamically grow as you populate it with data. Once you populate it with its needed data, flags, structure and function pointers, it would do the same exact thing as it would if you were using Vulkan in an actual programming language; it would still be an instance of a VK_KHR_Surface object. As for handling the memory when ever the object goes out of scope and there are finally no more reference counts to it, that memory will be cleaned up. You wouldn’t need a garbage collector like Java or C# for the pointers behind the scenes would be similar to Python being smart pointers. I’m not referring to dynamic memory on the heap directly as by default it would be considered a stack variable to utilize registers while being cache friendly while still having the ability to put things out on the heap or into main memory as this would also be an option. The objects themselves would clean up their own memory footprint once their lifetime has expired and nothing is referencing it. You wouldn’t have to call new and delete on it unless if you want Dynamic Heap memory. The object itself along with the record keeping of the console would handle that for you. This doesn’t mean that you could not terminate it directly as that would also be a valid thing to do. One could just create the objects and allow the console to manage it itself, or you could write the code with your own managing system. That would be up to the user to decide. The console would be fairly efficient but if one knows how to manage the API calls in a strategic manner, they can do better than the console.

I was also referring to the fact that the shell itself would have its own interactive run time programming language and all of the vulkan interfaces and protocols would be built in to the core of the consoles built in language. The console, shell or terminal itself provides the language. The language itself is built around, centered on and tailored to utilize Vulkan at its core.

It would also provide a versatile integrative back end that would allow you to import any installed compilers for any well known and already established languages on your system. One could still write a Vulkan app using C, C++, Java, Python etc. but they could also write a Vulkan app absent of those languages through the console directly. The console would know how to use the API calls and would know how to use shaders. Another words it would be creating an executable binary on the fly.

The wording of the title is a bit misleading as that isn’t what the overall design I had in mind. I was leaning more towards an IDE specific to Vulkan and the language of the IDE would be wrapper around the API. You wouldn’t have to write a compiler to handle other languages as the shell would target and invoke the native compiler(s) on that system. If you already have a C/C++ compiler or a Python Interpreter installed, during the installation process of the shell or terminal it would find and target them as part of the integration process. Including libraries such as GLM, STL, GLFW etc. would be just as simple as long as you have a supportive language to write them in. So if you are writing in Python you could import someLibrary or if you are writing a C/C++ block you could #include someLibrary and the console would know how to use them as it would just invoke the Python's interpreter or the C++ compiler-linker to do so.

As an analogy I’m running a Windows system and the Dos syntax is native to the command prompt, however I have Cygwin installed and within Cygwin when I start it up and run it; I can use Bash commands within Cygwin. This is kind of what I was trying to get. The shell application would have it’s own built in language, it would also integrate other compilers and interpreters, and allow you to import other libraries into it where the Vulkan API is built into it and ready to use, no need to link against it or to include it as the console knows what Vulkan Code is and knows what to do with it! I hope this helps to clarify things a little better. Yes the title was misleading and I updated it to make it more clear as to what I was suggesting.