lucasm
December 21, 2021, 12:54am
1
Toying around in the newest experimental, and noticed that I do not get any warning on GLSL tops that samplers beyond #32 will be ignored… Does this mean what I think it means??
lucasm
December 21, 2021, 1:00am
2
Holy crap I think I just answered my own question. Below input 256 is orange, and I can sample from it
Are there any limitations to this? Drawbacks? Performance considerations?
2 Likes
malcolm
December 21, 2021, 9:22pm
3
It’s GPU dependent, on macOS its still limited to 16/32. Most Windows GPUs have a high limit though.
You can see how many GPUs support each different amount, and click on the numbers to see the GPU list.
lucasm
December 21, 2021, 9:25pm
4
Oh super neat, will there be a way in TD to query this value? Would be very useful for dynamically tuning systems that leverage many samplers. Check at startup, and limit number of shader inputs, etc.
lucasm
December 21, 2021, 9:28pm
5
Amazing how vast the differences are between hardware… Any insights you could provide as to why macOS is limited to such a low number relative to some of these others for windows/nvidia?
For example, apparently a gtx 1070 on windows 10 can ingest a max of 1,048,576 samplers, obv way more than anyone would/could use but what’s so different from that to the osx side?
lucasm
December 21, 2021, 9:30pm
6
I guess intel HD graphics 520 and 540 are amongst the 16 sampler limited ones too, so that’s interesting as well.
malcolm
December 21, 2021, 9:33pm
7
I’m not sure offhand, it’s possibly just a API limitation of Metal so far.
easisi
December 3, 2022, 6:10am
8
hey people,
/**
* Controls whether MoltenVK should use Metal argument buffers for resources defined in
* descriptor sets, if Metal argument buffers are supported on the platform. Using Metal
* argument buffers dramatically increases the number of buffers, textures and samplers
* that can be bound to a pipeline shader, and in most cases improves performance. If this
* setting is enabled, MoltenVK will use Metal argument buffers to bind resources to the
* shaders. If this setting is disabled, MoltenVK will bind resources to shaders discretely.
*
* NOTE: Currently, Metal argument buffer support is in beta stage, and is only supported
* on macOS 11.0 (Big Sur) or later, or on older versions of macOS using an Intel GPU.
* Metal argument buffers support is not available on iOS. Development to support iOS
* and a wider combination of GPU's on older macOS versions is under way.
*
* The value of this parameter must be changed before creating a VkInstance,
* for the change to take effect.
*
* The initial value or this parameter is set by the
* MVK_CONFIG_USE_METAL_ARGUMENT_BUFFERS
* runtime environment variable or MoltenVK compile-time build setting.
* If neither is set, this setting is enabled by default, and MoltenVK will not
show original
also discussed here:
opened 08:06PM - 06 Jun 22 UTC
closed 02:31PM - 08 Jun 22 UTC
Most of the platforms that have this low of a constraint are mobile platforms:
… https://vulkan.gpuinfo.org/listreports.php?limit=maxPerStageDescriptorSamplers&value=16&platform=all
(also 16 for related properties)
It seems surprising that the modern laptop GPU's on Mac hardware couldn't support more..
This puts strong constraints on code that is designed to run cross-platform without modification, in terms of the critical resource of number of textures in a descriptor set.
and here:
opened 10:01PM - 26 Dec 20 UTC
Enhancement
Question
Fixed
Answered
Information
I've created a new [`argument-buffers`](https://github.com/KhronosGroup/MoltenVK… /tree/argument-buffers) branch to support Metal argument buffers for use in descriptor sets, and have pushed the initial release of this implementation to that branch. Some notes on current status:
1. The use of Metal argument buffers dramatically increases the available quantities of shader resources in most modern (Tier 2) GPU's, properly supporting the goals of the `VK_EXT_descriptor_indexing` extension.
2. The `MVK_CONFIG_USE_METAL_ARGUMENT_BUFFERS` environment variable can be used to enable or disable the use of Metal argument buffers. It is enabled by default in this branch.
3. The Metal argument buffer implementation passes the same 20K+ CTS _descriptor set_ tests that MoltenVK passes when not using Metal argument buffers.
4. However, the current implementation does cause issues and crashes with some applications, and that is being tested and addressed. Please add comments to this issue to identify any problems encountered while testing.
5. In order to streamline descriptor set allocations, this implementation allocates a single large `MTLBuffer` to use for all descriptors managed by a descriptor pool (as opposed to a `MTLBuffer` per descriptor set stage). However, because Metal doesn't seem to allow arbitrary indexed access into Metal argument buffers, each descriptor layout **_stage_** requires a separate argument encoder. The result is that, in theory, each pipeline stage could use all descriptors, meaning that at pool allocation time, the size of the single large `MTLBuffer` is grossly over-allocated. For example, a graphics pipeline of 4 stages will have 4 separate argument encoders, and 4 sets of resources in the argument buffer. An alternative for this could include allocating a separate `MTLBuffer` per descriptor set when the descriptor set is allocated, but in CTS testing, this causes significant performance degradation _(50x)_ during descriptor set allocation and freeing, relative to **_not_** using Metal argument buffers, because `MTLBuffers` are performance-expensive to create and destroy. Another alternative might be to manage a pool of smaller `MTLBuffers`.
6. I will continue to do further improvements, optimizations, and testing on the `argument-buffers` branch before rolling it into `master`.
@cdavis5e I wouldn't mind getting your thoughts on item 5 above.
could this be of help for us TD mac users ?
