Rpcs3: Vulkan limit maxPerStageDescriptorSamplers is not respected

[kvark]

Running on a particular Vulkan implementation and RPCS3 requiring 32 samplers for one of the shader stages. This is more than the driver reported in the physical device limits: maxPerStageDescriptorSamplers == 16.

[kd-11]

Hi @kvark
I suppose maxPerStageDescriptorSampledImages != maxPerStageDescriptorSamplers on this vulkan implementation as well? Both are consumed by COMBINED_IMAGE_SAMPLER so they should be equal.

Impl: https://github.com/RPCS3/rpcs3/blob/master/rpcs3/Emu/RSX/VK/VKHelpers.cpp#L236

Spec quotes:

maxPerStageDescriptorSampledImages is the maximum number of sampled images that can be accessible to a single shader stage in a pipeline layout. Descriptors with a type of VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER, VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE, or VK_DESCRIPTOR_TYPE_UNIFORM_TEXEL_BUFFER count against this limit. Only descriptors in descriptor set layouts created without the VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT bit set count against this limit

maxPerStageDescriptorSamplers is the maximum number of samplers that can be accessible to a single shader stage in a pipeline layout. Descriptors with a type of VK_DESCRIPTOR_TYPE_SAMPLER or VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER count against this limit. Only descriptors in descriptor set layouts created without the VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT bit set count against this limit.

The implication here is that for the same type, e.g COMBINED_IMAGE_SAMPLER constraint, the two should be equal. While we can just change the check to check sampler limit only to get around it, but combined image sampler is both sampler and image - maybe we can get clarification from khronos?

[kvark]

You are totally right! I'm fixing our driver to return the proper maxPerStageDescriptorSampledImages limit. Thank you!

[kvark]

loosely related, I'm past that error now, and I'm trying to run anything, and I'm hitting "EXC_BAD_ACCESS" on SPU worker 1 for the precise interpretation mode, and this for LLVM:

Thread 'PPU[0x1000000] Thread (main_thread) [0x00510000]' terminated due to fatal error: Null function
(in file /Users/dmalyshau/Code/rpcs3/Utilities/JIT.cpp:570)

Tried on Scogger HD as well as Bomberman. Is this known, or am I doing something strange?
I'm running master branch with latest PS3 firmware to date.

[kd-11]

Unfortunately I have never encountered this problem, it's likely limited to mac OS which no devs have access to. Join our discord server and ask around in #development, maybe someone on mac/BSD has encountered this.

[hcorion]

None of the LLVM recompilers with on MacOS for some reason, but I think using the fast interpreters for PPU and SPU should still work.

[kvark]

Unfortunately, fast interpreters didn't work for me either. Oh well. If I have extra spare mac machines, I know where to send them :)

[MSuih]

As said, we do not have anyone with a mac so nobody tests for regressions. Interpreters did work at one point, and it might not take much fixing to get them to work again. I think you're the only person I've seen on this project who has a mac and knows something about programming.

[kvark]

@MSuih in case I find more time to look into it, where can I get an idea of how to investigate/fix this? If there is anything more concrete than a general RTFM, I'd appreciate some pointers. Saying that, my lack of Discord participation may become a blocker at some point if I go for it.

[Nekotekina]

SPU Interpreter (fast) is LLVM-based, try ASMJIT just in case.