On 3/10/23 4:10 PM, ryuukk_ wrote:
> On Friday, 10 March 2023 at 20:53:23 UTC, Hipreme wrote:
>> Hello guys. I have been working for some time into binding Metal to D.
>> This has been quite an interesting journey and today I've reached a point where it is usable.
>> It is far from complete, but I included a lot of comments from Apple's documentation, and also have tested and got an entire Metal hello world working in D.
>>
>> The API I worked on is really nice, I manually put the opIndex, opIndexAssign, wrapped Objective C Runtime Arrays to a strongly typed array in D. The main point into this binding is getting Metal to run on Hipreme Engine, so, I don't plan into supporting what I don't use. That said, I still welcome any contribution to make this a standard way to program using Apple's Metal.
>>
>> I'll put an example folder the moment I get a dub fix for macOS.
>>
>> ![Metal MacOS D Hello World](https://user-images.githubusercontent.com/10136262/224425800-e417414e-b6be-4e92-93b4-9087b1b281a2.png)
>>
>> https://code.dlang.org/packages/d-metal-binding
> 
> Congrats!
> 
> But metal obj-c? do you mean DMD support only? so no Apple Silicon (intel only)?
> 
> I don't think Intel stuff on mac ecosystem will be a thing for too long, PPC era already vanished from history
> 
> There is the official C++ headers that you can use to make things easier
> 
> https://developer.apple.com/metal/cpp/

From that page:

     No measurable overhead compared to calling Metal Objective-C headers, due to inlining of C++ function calls.

D will not inline C++ function calls. So there will be overhead.

Objective-C support is better. Getting Obj-C support into LDC is the right path. And I'm with you too -- we need ARM support for Metal. Looking forward to it!

-Steve

On Saturday, 11 March 2023 at 13:08:49 UTC, Steven Schveighoffer wrote:
> On 3/10/23 4:10 PM, ryuukk_ wrote:
>> On Friday, 10 March 2023 at 20:53:23 UTC, Hipreme wrote:
>>> Hello guys. I have been working for some time into binding Metal to D.
>>> This has been quite an interesting journey and today I've reached a point where it is usable.
>>> It is far from complete, but I included a lot of comments from Apple's documentation, and also have tested and got an entire Metal hello world working in D.
>>>
>>> The API I worked on is really nice, I manually put the opIndex, opIndexAssign, wrapped Objective C Runtime Arrays to a strongly typed array in D. The main point into this binding is getting Metal to run on Hipreme Engine, so, I don't plan into supporting what I don't use. That said, I still welcome any contribution to make this a standard way to program using Apple's Metal.
>>>
>>> I'll put an example folder the moment I get a dub fix for macOS.
>>>
>>> ![Metal MacOS D Hello World](https://user-images.githubusercontent.com/10136262/224425800-e417414e-b6be-4e92-93b4-9087b1b281a2.png)
>>>
>>> https://code.dlang.org/packages/d-metal-binding
>> 
>> Congrats!
>> 
>> But metal obj-c? do you mean DMD support only? so no Apple Silicon (intel only)?
>> 
>> I don't think Intel stuff on mac ecosystem will be a thing for too long, PPC era already vanished from history
>> 
>> There is the official C++ headers that you can use to make things easier
>> 
>> https://developer.apple.com/metal/cpp/
>
> From that page:
>
>      No measurable overhead compared to calling Metal Objective-C headers, due to inlining of C++ function calls.
>
> D will not inline C++ function calls. So there will be overhead.

If you are able to use LTO then they'll be inlined. This may be slightly easier said that done for some build targets because apple's "clang" is actually a closed source fork so it's not impossible that there is LLVM incompatibility in there somewhere.

In the absence of evidence suggesting otherwise, the overhead of an additional function call is probably quite small relative to the metal part of the function call (especially if that Metal call ends up waiting on the GPU for something).

I'm now curious if there are I$ optimizations specifically for chasing function calls like this.