vkGetPhysicalDeviceSurfaceCapabilitiesKHR reports incorrect surface extent on iOS

[jswillard]

I found that checking the extent of the surface does not match the actual width and height of the underlying CAMetalLayer. I am testing on 12.9inch iPad Pro which has a 2732x2048 resolution display. The CAMetalLayer will report the drawableSize as 2732x2048 but I get a surface extent from Vulkan of 2731x2048.

I believe the culprit is this function in CAMetalLayer+MoltenVK.m

-(CGSize) naturalDrawableSizeMVK {
    CGSize drawSize = self.bounds.size;
    CGFloat scaleFactor = self.contentsScale;
    drawSize.width = trunc(drawSize.width * scaleFactor);
    drawSize.height = trunc(drawSize.height * scaleFactor);
    return drawSize;
}

The bounds of the layer are 1590x1192 with a contentsScale of 1.7181208053691275.

I tried replacing trunc() with round() which worked great on my 12.9inch iPad but broke the 11inch iPad version.

I can't think of a great way to solve this as per Apple's docs bounds * contentsScale is the expected way to get the extent of the surface. If you set drawableSize = bounds * contentsScale then Apple will do some rounding behind the scenes to the correct value, it's not clear what rounding they are doing except that drawableSize will be the correct value (2732x2048).

By default, a layer creates textures sized to match its content—that is, this property’s value is the layer’s bounds size multiplied by its contentsScale factor.

For now, I am just creating swapchains of 2731x2048 so that the image extent and the surface extent match and then letting the system scale appropriately. It would be great to have a proper solution for this, thanks!

[billhollings]

Could be adjusted along with fixes for #1753 (comment).

[billhollings]

PR #1835 should fix this issue. Please retest and close this issue if the problem you encountered has been resolved.

[jswillard]

The PR fixes the case when the bounds of the layer are 1590x1192 and contentsScale are 1.7181208053691275. But the scaling on the 12.9inch iPad can be set to "More Space" (1.71812...), "Default" (2.0), and "Larger Text" (2.66665). When set to "Larger Text" the bounds are 1024x768 and at this setting MoltenVK will report the surface extent as 2730x2048, which is still incorrect.

Also, another issue I noticed with the changes to naturalDrawableSizeMVK is vkAcquireNextImageKHR will return VK_SUBOPTIMAL_KHR even when the surface extent and image are both 2732x2048. I'm guessing due to this addition in MVKSwapchain.h:

bool hasOptimalSurface() {
	if (_isDeliberatelyScaled) { return true; }

	auto drawSize = _mtlLayer.drawableSize;
	return (CGSizeEqualToSize(drawSize, _mtlLayerDrawableSize) &&
			CGSizeEqualToSize(drawSize, _mtlLayer.naturalDrawableSizeMVK));
}

as drawSize will be a whole number (2732x2048) and _mtlLayer.naturalDrawableSizeMVK will be some fractional value (2731.81x2048 with scaling set to "More Space").

[billhollings]

Also, another issue I noticed...as drawSize will be a whole number (2732x2048) and _mtlLayer.naturalDrawableSizeMVK will be some fractional value (2731.81x2048 with scaling set to "More Space").

Latest MoltenVK update should fix this. It now applies the rounding before comparing. Please retest and respond.

When set to "Larger Text" the bounds are 1024x768 and at this setting MoltenVK will report the surface extent as 2730x2048, which is still incorrect.

Unfortunately, I wasn't able to reproduce this, as my iPad Pro 10.9" doesn't have the "Larger Text" toggle. It does have a font scaling slider, but changing that did not change the2.0 contentsScale value. My MacBook Air does have the "Larger Text" toggle on its Retina display, but selecting it did not change the 2.0 contentsScale value.

Effectively, I only ever see a contentsScale value of 2.0 or 1.0, depending on whether Retina is in play or not.

Notwithstanding my inability to replicate, your results for "Larger Text" on your 12.9" iPad seem to be a result of Metal having only one value for contentsScale, instead of separate scales for width and height. Basically, 2048/768 and 2732/1024 do not result in the same scaling value, and with a single contentsScale reported as 2.66665, the pixel width calculates as 2730.65, which will round to 2731 (I'm not sure why you might be seeing 2730, please retest with latest MoltenVK).

I'm not sure if there is anything we can do about this here. Given the single contentsScale value provided by Metal, we will end up with that scale resulting in one of the screen dimensions occasionally being slightly smaller or larger than it should be, in your case resulting in the pixel width being 2731.

And even checking the screen size itself provides the values in points and not pixels, so we don't seem to even have a way of retrieving the actual pixel size of the screen in order to detect a contentsScale mismatch. For instance, here's the available info queried on my iPad Pro 10.9":

[mvk-info] CAMetalLayer 
	bounds size (1024.000, 768.000) 
	contentsScale 2.000 
	contentsRect size (1.000, 1.000) 
	natural drawable size (2048.000, 1536.000) 
	drawableSize (0.000, 0.000) 
	screen size  (1024.000, 768.000) 
	screen Scale 2.000.

If needed, you can use the new functionality available in the VK_EXT_swapchain_maintenance1 extension to set the scaling and gravity to either slightly stretch one dimension (the default behavior), or set the scaling the same in both dimensions, and align the image on the screen, leaving one unpainted row of pixels on one or the other side of the rendered image.