All the GPGPU projects on the Pi seem to be centered around low level assembly language for the Videocore. Are there any technical reasons why there are no higher level C/C++ abstractions?
I think C/C++ programmers are more pragmatic than the typical Python/Ruby programmer in that their highest priority is the program works (typically performance is important). If the code is nice that's just a bonus.
I probably shouldn't bother replying to this. But I am curious about what leads a person to paint with such broad strokes.
I've intentionally chosen a job that is mostly Python. Because while I am aware that it has some flaws or trade offs or whatever you want to call them, it's a language that -- first and foremost -- allows me to write programs that work.
The fact that I find the language aesthetically pleasing is a bonus. When I run into situations where Python isn't good enough, then I drop down into C and do things there.
I'm new enough at being a developer that I'm willing to understand that there are things I may be missing out on coming from a self-taught background that started with SQL and then moved to C# and eventually Python, and then sometimes C when needed.
I'm also open to the idea that a person's language of choice indicates something about their personality characteristics in the same way that you can guess a little about a person based on which instrument they play in an orchestra or a band.
But is there really anything you can say about what I'm reading in your comment as 'rigor' based on that?
Shader units --- e.g. the VideoCore's QPUs, which this project is targeting --- are very very weird. Compiling C into them basically isn't possible. They don't really do memory accesses, for example.
The VideoCore's own processor, commonly referred to as the VPU or just the VC4, is a perfectly normal architecture with its own vector unit and DSP addons. C can compile into that perfectly easily, and the real-time OS that runs on it alongside Linux is written in it, but there aren't any adequate open source C compilers yet.
No. Inline assembly is a static construct targeting the same compute unit as the C code during compile-time.
What is needed is "runtime inline assembly" which assembles inline assembly for a different target architecture at runtime.
This is essentially what shader programs are and you don't need special syntax to support it. Just store your shader program in a char* and bundle an assembler/compiler with your host program.
That's fair, but I feel like most languages have searchable package repositories, and I'd be searching in one of those, eliminating the need for such naming.
22 comments
[ 3.6 ms ] story [ 57.1 ms ] threadI've intentionally chosen a job that is mostly Python. Because while I am aware that it has some flaws or trade offs or whatever you want to call them, it's a language that -- first and foremost -- allows me to write programs that work.
The fact that I find the language aesthetically pleasing is a bonus. When I run into situations where Python isn't good enough, then I drop down into C and do things there.
I'm new enough at being a developer that I'm willing to understand that there are things I may be missing out on coming from a self-taught background that started with SQL and then moved to C# and eventually Python, and then sometimes C when needed.
I'm also open to the idea that a person's language of choice indicates something about their personality characteristics in the same way that you can guess a little about a person based on which instrument they play in an orchestra or a band.
But is there really anything you can say about what I'm reading in your comment as 'rigor' based on that?
Pragmatism and nice code are not at odds with each other. Quite the opposite, they are often in agreement with each other.
The VideoCore's own processor, commonly referred to as the VPU or just the VC4, is a perfectly normal architecture with its own vector unit and DSP addons. C can compile into that perfectly easily, and the real-time OS that runs on it alongside Linux is written in it, but there aren't any adequate open source C compilers yet.
More info on the QPU here:
https://github.com/hermanhermitage/videocoreiv-qpu
What is needed is "runtime inline assembly" which assembles inline assembly for a different target architecture at runtime.
This is essentially what shader programs are and you don't need special syntax to support it. Just store your shader program in a char* and bundle an assembler/compiler with your host program.
That's like me saying "can we stop choosing HN usernames that contain programming references?"
https://github.com/nineties/py-videocore/commit/7b192779e844...