Not quite correct to lump M1 in with A14. It has BC support not reflected in that table. Now I wish the iPhone/iPad did too.

USDZ is a dcc format that's not optimized for GPU use. It's a dcc transfer format that Pixar designed for maintaining high-quality assets for their films. Unlike GLTF, the data is completely stored as uncompressed floats. You can use ModelIO to compress all the vertices. Then write that out as a GLTF or usable asset format of your own design. Then the image data is jpg/png. Jpg should never be used with 3d models, unless you like normals to ring. And png can't represent the 7 image types that most gpus need. So then you need to turn those png textures into ktx or ktx2 files, and then BC compress for desktop or ASTC/ETC compress them for mobile.

This seemed to work. I still don't see why the storyboard settings don't apply to control this. - (void)awakeFromNib {   [super awakeFromNib];   // vertical offset of table down so hud can display info   NSScrollView* scrollView = [_tableView enclosingScrollView];   CGRect rect = scrollView.frame;   rect.origin.y += 50;   scrollView.frame = rect; }

Where is an Apple code example that sets all this up? Having a single post about this on the forums is not enough. The link above is not informative. We don't want multiple windows, we just want a single resizable window of an iOS title. Other posts state that you must be iPad Multitasking aware, and that requires several settings.

I had a second NSTableView in the storyboard that I needed to remove. The fix above is still needed to have the tableView hide itself.

Actually, that's not a complete fix. The area the table occupies invisibly for the scrollView is still consuming pan events. There's just no visual of the slider moving, but that whole area is a panning dead zone now.

This is the workaround is to set the containing scrollView hidden instead of the tableView itself. // doesn't work, scrollbar responds to pan gestures and displays empty scroll region // _tableView.hidden = YES; // fix broken NSTableView, keeps showing scroll and responding to pan   // so set scroll to hidden instead of tables   NSScrollView* scrollView = [_tableView enclosingScrollView];   scrollView.hidden = YES;

It's exactly what I mentioned. Smaller images may have some page sub-allocation strategy. Small buffers in Metal are sub-allocated from a larger 128K buffer, but that's harder with texture data. Not that on macOS Intel, the page size is higher so the need to atlas is even more true there. 256x256, mips 8, Astc: 21872, Metal: 32768 <- mips add up to 16K x 4/3 approx = 21845, but due to align and 16K page size, padded out to 32K 256x256, mips 1, Astc: 16384, Metal: 16384 <- this is the exact fit 32x32x16B = 16K

Try using -MO instead of -frecord-sources. That's the only way things worked on Mac, even though this flag is deprecated.

It's not really padding, it's page alignment. On console, you could sometimes pack buffer data into the unused bytes. Android has similar hardware and alignment requirements. Sometimes mips have to be aligned to the page size, but maybe Metal team can relay more here. It's gpu specific, so I doubt they'll want to commit to details. Also hardware often has a packed mip tail in order to cut page use for smaller mip sizes. Is your output showing the buffers that you generated to upload to Vulkan textures. These are linear block order texture data, and not the tiled order blocks used by the hw that may be aligned to texture pages. Some systems also have to pad mips out to a power-of-two size. On desktop the tile size is 64KB. On iOS the tile size is 16KB. Here are tileSizes. Format Desktop(64K) Mobile (16K) ASTC/BC7 256x256 128x128 BC1/ETCr11 512x256 256x128

Seems like this is a client-side type error. Clearing all cookies on the browser was recommended online, and seems to have corrected the issue for now.

This problem has been happening for years now. It happens on Intel and M1, so it's not tied to hardware. There's something wrong with the forum software that generates the http response. Seems like this is a client-side type error. Clearing all cookies on the browser was recommended online, and seems to have corrected the issue for now.

That sounds even more of a stall if one is trying to use double-buffering. All Apple examples always fallback to triple-buffer to buy more time, and so I'd encourage fixing this api. Vulkan doesn't stall in vkImageAquire for long at all, less that 3ms. Metal can take 30-40ms when the gpu is saturated. In Vulkan, that allows a single command buffer to hold the backbuffer aquire and present to the backbuffer.

This is also why you need to atlas, use array textures, etc. Then each of those can fill up multiple texture pages. Megatexture is just an extreme case of atlasing, where the uv and pages are dynamically adjusted to parts of a single texture.

There's a minimum page size (typically 32k to 64K) to all GPUs. So you can't really defeat that. That affects partially-resident textures, where you load chunks of mips. Also I wouldn't use anything above ASTC6x6 personally. Fitting 64 or 144 samples to two colors and some gradients is a way to turn textures to garbage.