11–20 of 23 posts
Cool project. Small rant; can we please stop titling our libraries with the language extension as a portion?
I like it (for otherwise generic names); it quickly shows which language the library is for, reduces name collisions, and makes Googling easier.
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?
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:
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?
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 t…
Earlier quoted context omitted.
I like it (for otherwise generic names); it quickly shows which language the library is for, reduces name collisions, and makes Googling easier.
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.
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'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?
Earlier quoted context omitted.
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 t…
Disclaimer: I know nothing about the issues, but would using C with inline assembly gain anything?
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.
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.
Pragmatism and nice code are not at odds with each other. Quite the opposite, they are often in agreement with each other.
Cool project. Small rant; can we please stop titling our libraries with the language extension as a portion?
That's like me saying "can we stop choosing HN usernames that contain programming references?"