feat: apple support

[pollend]

No description provided.

[pollend]

something interesting, I guess apple doesn't report the device/vendor.

    "Apple": {
      "id": "0x106b",

      "_comment": [
        "Apple GPUs do not report a DeviceID via the Metal API, and as such the typical device",
        "pattern matching does not work for them. The recommended approach is to find the highest",
        "supported 'common' family supported and report it as the architecture.",
        "Examples: 'common-1', 'common-3'",
        "https://developer.apple.com/documentation/metal/gpu_devices_and_work_submission/detecting_gpu_features_and_metal_software_versions"
      ]
    },

[vertver]

I don't think it's a problem. Just do what Metal's layer says and just pass the single device.

[pollend]

looks like these are #defined in apple framework.

[dzhdanNV]

I don't mind to add these undefs to the interface.

[pollend]

not sure how this will work in practice.

[pollend]

@dzhdanNV just an observation you nearly have a pure C interface any reason for the C++ code to abstract across that. you can also just union a bunch of stuff together for dx12/dx11/vulkan/metal. You also have all this logic to build tables of functions etc ... avoid having to use a C++ so it should be easier to distribute. I guess you could just access that data based on the api.

struct CmdBuffer {
   union {
      struct {...}dx11;
      struct {...}dx12;
      struct {...}metal;
   };
}

struct NriDevice {
   union {
      struct {...}dx11;
      struct {...}dx12;
      struct {...}metal;
   };
   int (*Method1)(NriDevice*...);
}

[pollend]

looks like there isn't a count buffer implement provided by the encoder. https://developer.apple.com/documentation/metal/mtlrendercommandencoder/render_pass_drawing_commands?language=objc

[vertver]

Ping me when you're done with the base implementation, I'll try to get samples to work.

[vertver]

Also, argument buffers can be used to emulate root constants/push constants. But yes, you can also use it for count buffers

[pollend]

Also, argument buffers can be used to emulate root constants/push constants. But yes, you can also use it for count buffers

feel free to jump in if you know what to do, you can drop me a PR and i can merge it. still looking around at the metal docs and trying to roughly get something together, will take quite a bit there is a lot here to cover.

[pollend]

not sure how these will fit together i only know about encoder once the pipeline is set. the attachment is know only with BeginRendering

https://developer.apple.com/documentation/metal/mtlcommandencoder

[pollend]

I have something rough for this CommandBufferMTL. hopefully I can get something rough.

[pollend]

Also, argument buffers can be used to emulate root constants/push constants. But yes, you can also use it for count buffers

feel free to jump in if you know what to do, you can drop me a PR and i can merge it. still looking around at the metal docs and trying to roughly get something together, will take quite a bit there is a lot here to cover.

[pollend]

been busy with something else, I'll have to catch up to this once i finish up what i want to do with this game project im working on.

[dzhdanNV]

Sure, no prob. And tons of thanks for working on native Apple support!

[dzhdanNV]

Thanks for the progress. Very appreciated.

[pollend]

so i guess you encode the data to an argument buffer. I guess to reproduce descriptor sets the pool would allocate an argument buffer for n number of descriptor sets?

fragmentShader(       RasterizerData            in                 [[ stage_in ]],
               device FragmentShaderArguments & fragmentShaderArgs [[ buffer(AAPLFragmentBufferIndexArguments) ]])

[dzhdanNV]

To be honest I don't follow. Please, explain the problem and a solution. Is the question about indirect drawing or something else?

[vertver]

I guess to reproduce descriptor sets the pool would allocate an argument buffer for n number of descriptor sets?

Correct. Metal requires to fill argument buffers even for non-indirect draw calls, so you need to store descriptors in it.

[pollend]

any clue how these properties line up with DescriptorRangeDesc?
https://developer.apple.com/documentation/metal/mtlargumentdescriptor?language=objc

for(size_t r = 0; r < descriptorSetDesc.rangeNum; r++) {
            MTLArgumentDescriptor* argDescriptor = [MTLArgumentDescriptor argumentDescriptor];
            const DescriptorRangeDesc* range = &descriptorSetDesc.ranges[r];
            argDescriptor.arrayLength = range->descriptorNum;
            argDescriptor.access = MTLBindingAccessReadWrite;
            argDescriptor.index = range->baseRegisterIndex;
            switch(range->descriptorType) {
                case DescriptorType::TEXTURE:
                    argDescriptor.dataType = MTLDataTypeTexture;
                    argDescriptor.textureType = MTLTextureType2D; // descriptor type does not have this
                    break;
                case DescriptorType::SAMPLER:
                    argDescriptor.dataType = MTLDataTypeSampler;
                    break;
                case DescriptorType::CONSTANT_BUFFER:
                case DescriptorType::STORAGE_TEXTURE:
                case DescriptorType::BUFFER:
                case DescriptorType::STORAGE_BUFFER:
                case DescriptorType::STRUCTURED_BUFFER:
                case DescriptorType::STORAGE_STRUCTURED_BUFFER:
                    argDescriptor.dataType = MTLDataTypeStruct;
                    break;
                case DescriptorType::ACCELERATION_STRUCTURE:
                    argDescriptor.dataType = MTLDataTypePrimitiveAccelerationStructure;
                    break;
            }
        }

[dzhdanNV]

An obvious suggestion: you can look at MoltenVK sources and work this way:

NRI => open NRI/VK => open corresponding place in MoltenVK => analyze, rearrange, copy & paste to MTL implementation

(looking at MTL docs...)

[pollend]

An obvious suggestion: you can look at MoltenVK sources and work this way:

NRI => open NRI/VK => open corresponding place in MoltenVK => analyze, rearrange, copy & paste to MTL implementation

(looking at MTL docs...)

I've been looking at the MoltenVK source, thanks for the suggestion. umm, ill have to do a bit of research i don't want to have to extend DescriptorType. maybe there is a more ideal solution?

[dzhdanNV]

Why do you need to potentially extend DescriptorType? Because of this:

                case DescriptorType::TEXTURE:
                    argDescriptor.dataType = MTLDataTypeTexture;
                    argDescriptor.textureType = MTLTextureType2D; // descriptor type does not have this
                    break;

?

[pollend]

Why do you need to potentially extend DescriptorType? Because of this:

                case DescriptorType::TEXTURE:
                    argDescriptor.dataType = MTLDataTypeTexture;
                    argDescriptor.textureType = MTLTextureType2D; // descriptor type does not have this
                    break;

?

https://developer.apple.com/documentation/metal/mtltexturetype

defines 1D/1DArray/2D/2dArray/Cube/CubeArray etc ... ill have to see NRISamples when I get there. just something to note later on. Ummm, I still need to finish metal cmd buffers.

[vertver]

You can do the same trick as here -

NRI/Source/D3D11/DescriptorD3D11.hpp

Line 55 in 205cf05

switch (textureViewDesc.viewType) {

Just identify your texture type by texture parameters, that's all you need.

[pollend]

You can do the same trick as here -

NRI/Source/D3D11/DescriptorD3D11.hpp

Line 55 in 205cf05

switch (textureViewDesc.viewType) {

Just identify your texture type by texture parameters, that's all you need.

in what way?

[vertver]

AFAIK, MTLTextureDescriptor is a direct analogue of NriDescriptor, so it shouldn't be hard to identify the texture type when creating the descriptor. If I'm right, you can use TextureViewType to identify the MTLTextureType.

[dzhdanNV]

The problem is that there are no descriptors in DescriptorRangeDesc. In other places - yes. In this and hopefully the only one place - no.

[vertver]

https://github.com/KhronosGroup/MoltenVK/blob/1d2ec638532268d076a550262df2e5e5e4fd2c9e/MoltenVK/MoltenVK/GPUObjects/MVKDescriptorSet.mm#L1146C43-L1146C67
This type doesn't seem to be very important, as it's only used for size calculations.

Same here - https://github.com/KhronosGroup/MoltenVK/blob/1d2ec638532268d076a550262df2e5e5e4fd2c9e/MoltenVK/MoltenVK/GPUObjects/MVKDescriptor.mm#L486

[pollend]

there isn't a similar implementation in metal for this. umm I guess it would have to cache out a pipeline and render rectangles to the various layers then restore some of the command buffer state?