Py-Videocore: Python Library for GPGPU on Raspberry Pi | Hacker News Reader

Py-Videocore: Python Library for GPGPU on Raspberry Pi

github.com

105 pointsmatsuu22 comments

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?

The same could be said for Python/Ruby programmers.

Pragmatism and nice code are not at odds with each other. Quite the opposite, they are often in agreement with each other.

Although VC4 is capable enough to run simple GLSL shaders, it is not possible to compile a generic C (or OpenCL) code efficiently.

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.

More info on the QPU here:

https://github.com/hermanhermitage/videocoreiv-qpu

Disclaimer: I know nothing about the issues, but would using C with inline assembly gain anything?

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.

In the requirements it says Python 2.7, does it mean 2.7.x (hence no python 3 support) or "2.7 or newer" (hence with python 3 support)?

python3 is supported:

https://github.com/nineties/py-videocore/commit/7b192779e844...

Oh that's very cool, thanks for the clarification!

Cool project. Small rant; can we please stop titling our libraries with the language extension as a portion?

Who's "we"?

The Hacker News Community?

I tend to see it a lot in python, go and rust as of late.

It is largely because the package namespace is polluted, so the name you want is never available.

How come?

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.

Package repositories are useful to download the libraries; not so much if you're looking for discussions regarding them.

This is part of Python culture.

That's like me saying "can we stop choosing HN usernames that contain programming references?"

I can hande the "py" prefix or suffix (hopefully lower-cased though), but the dash is too much!

Reply on news.ycombinator.com