Usin Apple_M GPUs

[Bernd Machenschalk]

Hi!

I am trying to make use of the Apple M GPUs for Einstein@Home. We
already have an application that runs on Intel Macs with any GPU using
OpenCL, and it also runs standalone on an M1 using the GPU. We also
extended our server code to deliver Apps with plan class
"Apple_M=opencl" to Macs with an Apple-M GPU (as a generic OpenCL
coprocessor).

The only thing that doesn't work yet is passing the OpenCL device
information about the device to use from the client to the app. The app
calls the usual boinc_get_opencl_ids((cl_device_id* device,
cl_platform_id* platform), but doesn't get anything back (zeros); the
API reports "GPU type not found in init_data.xml" Are there some special
hoops to jump through to tell the client that is should pass that info
to the app? What's the "type" for a generic OpenCL coprocessor necessary
for the extended version of boinc_get_opencl_ids()? I could find
anything about it e.g. in
https://boinc.berkeley.edu/trac/wiki/OpenclApps

Bernd

[Bernd Machenschalk]

Update:

I found what's actually missing is to let the client know that the app
requires that type of coprocessor. When I do this via a local
app_info.xml, the application gets the proper device information from
the client.

What I had to add in app_info.xml was

    <coproc>
        <type>Apple M1</type>
        <count>1</count>
    </coproc>

Two questions:

1. How / where do I add the <coproc> information on the server side,
such that ultimately the client gets it? In the version.xml of the app
version? That would be the natural place, but it doesn't seem to be
documented anywhere.

2. I seems that as a <type> I have to specify the exact type of the GPU
("Apple M1"). I really don't need to have an app version for every such
GPU version (M1, M2 etc.), or do I?

Bernd

[Bernd Machenschalk]

Ah, got it - needed to extend the server code for this, too. The varying
coproc type is a nuisance, but I found a workaround.

Anyone willing in helping to test could point his Apple Silicon Mac to
EinsteinAtHome. The app is called
Gamma-ray pulsar binary search #1 on GPUs (FGRPB1G)
Beta test work must be enabled. AFAIK this device is not known to BOINC
as a GPU, so the usual GPU settings ("Use GPU"...) will not work here.

Bernd

[David P. Anderson]

Bernd:
Great work! Using Apple GPUs is very important going forward.

It's clear that we need to have the BOINC Mac client use the Metal API
for enumerating GPUs and getting their parameters.
I'll think about the details of this and will create a Github issue
where we can discuss it.

-- David

> --
> You received this message because you are subscribed to the Google Groups "boinc_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to boinc_dev+...@ssl.berkeley.edu.
> To view this discussion on the web visit https://groups.google.com/a/ssl.berkeley.edu/d/msgid/boinc_dev/b0798f18-ee85-2653-c70a-5ef1a87698e5%40aei.mpg.de.

[David P. Anderson]

(my last email refers to a potential Metal app version).

Server: In theory you should be able to give the app version a plan class with
<gpu_type>Apple M2</gpu_type>

API: the code is confusing; in one place "type" is an integer code for
nvidia/amd/intel,
in another place it's a name (like 'Apple M2').
This name comes from the app_info.xml file.

Unfortunately right now I don't have an Apple Silicon Mac to help debug this;
I'll look into getting one.

-- D

On Fri, Aug 18, 2023 at 3:14 PM Bernd Machenschalk
<bernd.mac...@aei.mpg.de> wrote:
>

[Bernd Machenschalk]

David,

thanks. As I wrote, I already got it working, without changing the app
or requiring an app_info.xml. The changes it requires are solely on the
server side.

Bernd

[Bernd Machenschalk]

On 20.08.23 07:45, Bernd Machenschalk wrote:
> thanks. As I wrote, I already got it working, without changing the app
> or requiring an app_info.xml. The changes it requires are solely on
> the server side.

Here's what I did:

The client already has some support for a "generic OpenCL coprocessor",
and it detects the Apple M GPU as such a thing.

Sidenote: the comment in
https://github.com/BOINC/boinc/blob/master/lib/coproc.h#L152
about the COPROC class
"// objects will always be a derived class (COPROC_CUDA, COPROC_ATI)"
seems misleading, as apparently for generic coprocessors this class is
instantiated directly. Would have saved me some time to know that. In my
code I at first derived a CORPROCESSOR_GENERIC class.

Anyway, the tricky thing here is that the client reports the exact type
of the GPU as "Apple M1", "Apple M2" etc. You probably don't want to
write a plan class for each model that exists now or comes out in the
future. OTOH the client needs to be told the exact type as it was
detected to identify the coprocessor to use.

I can see two solutions to this:

1. In parsing the "type", the type might be shortened to a common phrase
(e.g. "Apple M"). Then, however, the full type must be preserved
somewhere else (e.g. in a field "full_type"). This is the solution I
implemented at first. It is similar to commit
https://github.com/BOINC/boinc/commit/26eaa0edb5a7e8cf93cc3f0a85164529bedd3890
The plan class can normally scan for the shortened type, but should then
set custom_coproc_type to that full_type

    COPROC* cpp = (COPROC*)sreq.coprocs.lookup1("Apple M");
...
    strcpy(hu.custom_coproc_type,cp.full_type);

However, there are a few drawbacks to this:
- It seems a bit misplaces to handle a special case of a particular
coproc in the pretty generic coproc class, and odd to mess around with
the reported type in the _parsing_ process at all.
- I learned that the above commit (and also mine) would break existing
modifications other projects made to use Apple M GPUs (PrimeGriD)

2. Add another lookup() function to scan a coproc type only for the
beginning of type string, not for an exact match. This doesn't change -
and thus possibly break - existing behavior or local modifications that
rely on it. it's just an addition that can be used for this case of an
Apple M GPU plan class and similar cases in the future. I'm attaching
this solution only. A plan class for Apple M GPUs would then use that
lookup function, and then set the custom_coproc_type to the actual type:

    COPROC* cpp = (COPROC*)sreq.coprocs.lookup1("Apple M");
...
    strcpy(hu.custom_coproc_type,cp.type);

With that, for the reasons given above, I suggest to revert commit
https://github.com/BOINC/boinc/commit/26eaa0edb5a7e8cf93cc3f0a85164529bedd3890
I think this was meant to help, but to my knowledge it was never
discussed or tested in actual use.

Bernd

[Bernd Machenschalk]

Hi Charlie & David!

On 20.08.23 10:00, Charlie Fenton wrote:
> I believe that the GPU in on the same Apple Silicon chip as the CPU and shares the same memory. So wouldn't knowing the model and other information about the CPU (M1, M2, etc.) automatically tell you about the GPU?

Yes, if you want to limit yourself (and BOINC) to use Metal only for the
on-chip GPU of Apple Silicon. Not sure if we want this. We may at at
least consider using Metal as an additional API for older (Intel) Macs
with other GPUs (AMD, NVidia, Intel), and maybe the possibility of
attaching other GPUs to an Apple Silicon Mac (e.g. via Thunderbolt).
Even for a two M* chip system we need to identify the corresponding
OpenCL device for the Metal device to ensure proper scheduling by the
client.

> If that is not sufficient, then this seems like a good place to start:
> <https://developer.apple.com/documentation/metal/gpu_devices_and_work_submission/detecting_gpu_features_and_metal_software_versions?language=objc>

Thanks, that looks helpful!

>> It's clear that we need to have the BOINC Mac client use the Metal API
>> for enumerating GPUs and getting their parameters.
>> I'll think about the details of this and will create a Github issue
>> where we can discuss it.

Thanks. Two additional bits of information:

- There is the related issue https://github.com/BOINC/boinc/issues/5080
- Oliver is looking into using Metal in general and already has one of
our GPU applications ported to Metal, which can be used for testing.

Bernd

[David P. Anderson]

Also, we don't want to embed knowledge about specific Apple CPUs in the client;
we want to get this info from OpenCL or Metal.

I think we need to handle situations where an Apple CPU is used by
both OpenCL and Metal apps,
which means the client needs to enumerate GPUs with both APIs, and
correlate the results.
I'm working on a github issue for this.

-- D

[Charlie Fenton]

I believe that the GPU in on the same Apple Silicon chip as the CPU and shares the same memory. So wouldn't knowing the model and other information about the CPU (M1, M2, etc.) automatically tell you about the GPU?

If that is not sufficient, then this seems like a good place to start:
<https://developer.apple.com/documentation/metal/gpu_devices_and_work_submission/detecting_gpu_features_and_metal_software_versions?language=objc>

Cheers,
--Charlie

> To view this discussion on the web visit https://groups.google.com/a/ssl.berkeley.edu/d/msgid/boinc_dev/CAFtuuLQpw74tnjC0bFhW%3D39sFJCz1Pewcu42HwHD11R5Gdvfqw%40mail.gmail.com.
>