I still wait for the answer to the question: what feature are you missing from C++ that would improve code quality? C already can do classes and dynamic typing and lamdas. An enum is just the same as some constants. And templates are compiler time constructs. If you really need templates then you can just pre-compile them and pass them as values to the GPU.
What I miss are Java style generics. But this is just syntax sugar for additional type safety.
I just ported myself a C++ library to OpenCL and it doesnāt miss anything. The OpenCL port have also classes just like the C++ library had.
The main real-world problems in shader management today are combinatorial explosion, compile times, and run-time patching (recompiling) - what would this actually do to solve any of these?
If i understand you correctly you do not see any value in programming in C++ instead of C. I do not want to explain all advantages that C++ has over C, which to a large part comes from being able to program object oriented instead of function oriented, since very likely i would not be able to convince someone who thinks C has everything a programmer needs.
However, with C++ nobody enforces you to program in C++, you can still program in C if you want, so i am not proposing to take something away from the way you want to program.
The Circle C++ compiler demonstrates that it is indeed possible to program shaders in C++ right now. And i slowly understand why such a big step forward had to come from an individual person that was working on a C++ frontend compiler and was not coming from an industry where many people are happy as can be to write their code in GLSL.
You are the one saying that a bunch of work ought to be done. If you arenāt willing to get into the details of why that work ought to be done, it shouldnāt be surprising that your argument is not found too convincing.
What do you mean when you say āobject orientedā? Do you just mean having functions directly connected to data? Or do you refer to runtime polymorphism (which is what this term often refers to)?
Either way, OOP isnāt all that great from a performance perspective these days. When it comes to runtime performance, especially for things like shaders, we tend to want to structure our data to most efficiently use caches. The direct association between data and the code that manipulates it isnāt that important next to arranging data so as to be efficiently manipulated.
On the CPU end, its often more efficient for a conceptual āentityā object to not store its model data. Instead, itās more efficient to have an array of models, or even arrays of model components, and process those models through that array, rather than going through the entity object.
The overall point being that āC++ can do OOPā is not as good of a selling point as you think it is.
You pitch this as āCircle C++ (or whatever) vs. GLSLā, but thatās just not reality. Lots of people use Vulkan with shader languages that are not GLSL. Being able to do this is the whole point of SPIR-V.
Many game engines, for example, donāt even have a āshading languageā exposed to the user. They instead build shaders visually with a āshader graphā tool, which itself manufactures shaders. Some people use HLSL instead of GLSL. Others have home-grown languages tailored to their needs.
Saying āthis would be better than GLSLā is not a strong selling point when GLSL is not the main shading language being used.
It does not make any sense in my opinion to go into a discussion of type: What advantages does a language like C++ have compared to C, that would lead nowhere. There is ton of literature that can be found that goes into the details, not to mention that there are already very successful GPU frameworks that demonstrate this as CUDA and SYCL shows.
In my opinion things are very simple: You can program GPUs without performance penalty in C++ if you want, just ask the SYCL or CUDA people. And as the circle compiler shows you can do this now also for Vulkan in C++ and generate SPIR-V code.
My whole point was that I really found it very strange that this topic is not reflected in having on official shading language based on C++ that is supported by Vulkan and Khronos didnāt do more to support the topic āwriting your shader in C++ā.
I was not precise here, i meant GLSL/HLSL. These are the only two shading languages where i know that people write their shaders in for Vulkan.
When doing a quick google search about shading languages and Vulkan, GLSL and HLSL are also the only two shading languages i could find (for Linux/Windows).
What is the name of a shading language that i missed?
They do not support C++. They support a small, limited subset of C++. Thereās a reason for that.
C++ as implemented intuitively (and naively, as new grads do) yields very inefficient, hard to parallelize code on a CPU ā and even thatās on a CPU where significant circuitry has been devoted to try and compensate for this inefficiency, and where there are very few possible concurrent threads. On a GPU, thereās no space to waste on such silliness. It is expected that you will learn to write efficient, trivially parallelizable code for the GPU, or you will get no help from the architecture (nor should you). Itās about maximum performance, with more threads than the CPU can even begin to support, not compensating for a lack of development skill.
If I were working for a GPU vendor, I would not want to give you full support on the GPU for the full C++ cesspool. Can you imagine the support nightmare when folks start whining about how their inefficiently-written, general C++ programās performance is absolutely abysmal on one of their GPUs? Yeah, not good publicity. Thereās definitely some benefit in having to āre-gearā your thinking for a different mode of programming.
So (as has been suggested before in this thread ā multiple times!), letās move this discussion beyond:
āyou should program GPUs without performance penalty using C++ā,
which is extremely naive, to something like:
āI think GPU shading languages [or IRs] should support feature <X>ā.
Then describe how this featureā¦:
would save you time/money/etc. and
would be supportable at large scale with tens or hundreds of thousands of concurrent threads without tanking efficiency.
No. Most certainly this was not my point. The main advantages of C++ as I see it are in the std library. Being able to use std::string, vector, etc. and not using raw pointers is a huge help. But those are not language features, and I canāt see the std or boost library being available for GPU hardware. Iām sure there are also C libraries that make life easier by providing a string library.
Iām familiar with C++ and clearly it has advantages over C. Having classes and operator overloading could be helpful. But this can be all done also in C. Object oriented programming can be done in C just as well.
where many people are happy as can be to write their code in GLSL.
Iām not happy writing code in C or GLSL. I gladly would love a higher level programming language, but it should be higher level than C++.
Of course you have to live with some restrictions of C++ on the GPU. CUDA and SYCL all have those restrictions. I never would propose anything different, i have written lots of CUDA C++ code myself. Typically you will not use features as virtual functions, RTTI, heap memory allocations within a GPU thread, exceptions any various other things that do not map well on the GPU.
But C++ with CUDA and SYCL have successfully demonstrated that you can write very efficient GPU code with C++ when using this restricted C++ (AMD has coined this subset of C++ āstatic C++ā if i remember correctly).
C++ on GPUs is already heavily in use - with CUDA and SYCL for compute shaders - and very successfully. Of course they are so successful because they do not use C++ in the naive form that you described. You make the impression that lots of research might be necessary to extract features of C++ into shaders. In my opinion this is not necessary at all. SYCL already has done this extensively for compute shaders. Hopefully keryell1 has success in bringen SYCL and Vulkan tightly together, would be highly welcome from my side.
But the reason i started this thread was that i found this circle C++ compiler and tested it with really complex C++ kernels and it was nearly always able to digest those (one exception was that my beloved atomic_ref currently was not supported ). And the circle compiler can not only be used for compute but also for graphics shader types.
This demonstrated to me that C++ (again, i am talking about āstatic C++ā) already right now can be used as shading language for Vulkan, but i could not find any discussion of this fact from Khronos so far. This silence is what i found very disturbing.
Many people still have the opinion - yes you can write C++ with SYCL and CUDA - but this is very different from Vulkan. But this compiler proved to me that with latest Vulkan 1.2 this is no longer true. You now only require C++ frontend support - SPIR-V seems to have the features required for this right now already. With clspv and Sylkan you could get this conjecture already, but these tools converted from other frameworks to SPIR-V.
But the circle compiler uses its own language extensions to bring GLSL support into C++. It would be great if this extension would be standardized in some way.
). And the circle compiler can not only be used for compute but also for graphics shader types.