search

mn416 / QPULib

Language and compiler for the Raspberry Pi GPU
Other
430 stars 63 forks source link

Added scripts for detection of Pi-platform #38

Closed wimrijnders closed 6 years ago

wimrijnders commented 6 years ago

Fix for #32 and #18 .

This adds a C++ program and a shell script for detecting the platform being run on (Pi or non-Pi).

The shell script is used within the Makefile to block QPU-mode compilation for non-Pi platforms.

The C++ is more a proof of concept. After creating it, I wondered if it had any critical use case - the answer is globally 'no'[1]. Still it might be worthwhile to add it to the library. Awaiting your thoughts on this.

[1] Only thing I can think of: taking the binary and running it on a non-Pi ARM system.

wimrijnders commented 6 years ago

Actually, it might be good idea to make a command line tool to check the availability of the platform along with some basic info.

Something like this tool but much, much simpler. What I'm thinking of:

That's all I find useful for now. More can be added in due time.

mn416 commented 6 years ago

I don't think detectPlatform.cpp should be stored in the Examples dir. Either we can remove it until it's needed, or find a better place for it. Other than that, looks good.

wimrijnders commented 6 years ago

Agree, it's not really an example, more of a tool. A directory Tools? Perhaps under Lib?

wimrijnders commented 6 years ago

I noticed that get_version() was not filled in, in MailBox.cpp, so I added it. This returns the hardware revision code using a Mailbox call. The code is now displayed in detectPlatform.cpp.

I see a potential problem with the mailbox calls; will add an issue to explain it.

EDIT: I checked the mailbox calls, they're fine.

The issue is that you need to reserve space for input values as well as return values. The mailbox call in get_version() is different from the others, in that there's no input value but one return value; hence, you need to reserve a spot for the return value. The other calls are all good in this respect.

I have to say it's a bit bothersome that there is no official documentation for the QPU-specific mailbox calls. I can't find any online. Do you know where to look?

mn416 commented 6 years ago

Let's go for a Tools directory at the root of the repo. I don't mind code going into Lib, as long it is part of the library that can be called from applications. Programs with a main() function are better in Tools I think.

wimrijnders commented 6 years ago

OK, coming up.

wimrijnders commented 6 years ago

@mn416 I'm looking into how to read the VideCore registers, notably by examining the qpuinfo project.

It's one heck of a lot more work than I expected. The question is: do you think it's worthwhile to add the possibility of reading the registers? (don't know about write). Perhaps you have it already?

I do think it's worthwhile, it's just so much work to obtain information from the hardware we already know, namely the numbers of slices and the number of QPU's per slice.

Would like to hear from you if you think this functionality would be useful.

EDIT: Never mind, I figured it out. It's not as bad as it looks.

EDIT2: :smile: got it working. I'll clean up the code and make a PR out of it.

wimrijnders commented 6 years ago

@mn416 OK moved it. The register map PR builds on top of this one. I'll submit that when this one is merged.

wimrijnders commented 6 years ago

@mn416 Ping. Any chance you can process some of my issues and PR's? Especially this one, #38. If this one merges I have more.

mn416 commented 6 years ago

Hi @wimrijnders,

Can we move detectPlatform.sh into Tools too?

wimrijnders commented 6 years ago

Sure. That's a good place to put it.