Gfx: metal: Can't generate mipmaps for cubemaps using vkCmdBlitImage because it's not implemented

[zeux]

We use vkCmdBlitImage to do progressive blitting from mip 0 to mip 1 to mip 2 etc., including cubemaps. Getting this panic:

thread '<unnamed>' panicked at 'not yet implemented', /Users/travis/.cargo/git/checkouts/gfx-e86e7f3ebdbc4218/4a1b551/src/backend/metal/src/internal.rs:382:30
stack backtrace:
  0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
  1: std::sys_common::backtrace::print
  2: std::panicking::default_hook::{{closure}}
  3: std::panicking::default_hook
  4: std::panicking::rust_panic_with_hook
  5: std::panicking::begin_panic
  6: gfx_backend_metal::internal::ImageBlitPipes::create
  7: gfx_backend_metal::internal::ImageBlitPipes::get::{{closure}}
  8: <storage_map::StorageMap<L, std::collections::hash::map::HashMap<K, V, S>>>::get_or_create_with
  9: gfx_backend_metal::internal::ImageBlitPipes::get
 10: <gfx_backend_metal::command::CommandBuffer as gfx_hal::command::raw::RawCommandBuffer<gfx_backend_metal::Backend>>::blit_image
 11: portability_gfx::impls::gfxCmdBlitImage
 12: _ZN3RBX8Graphics19DeviceContextVulkan15generateMipmapsEPNS0_7TextureE
 13: _ZN3RBX8Graphics6EnvMap10fullUpdateEPNS0_13DeviceContextE
 14: _ZN3RBX8Graphics12SceneManager11renderBeginEPNS0_13DeviceContextEjjRKNS0_12RenderCameraE
 15: _ZN3RBX8Graphics12SceneManager11renderSceneEPNS0_13DeviceContextEPNS0_11FramebufferERKNS0_12RenderCameraE
 16: _ZN3RBX8Graphics10RenderView17renderPerformImplEdPNS0_11FramebufferENS_10RenderTypeE
 17: _ZN15RenderScheduler18renderIntoViewBaseEv
 18: _ZN11QOgreWidget5eventEP6QEvent
 19: _ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent
 20: _ZN12QApplication6notifyEP7QObjectP6QEvent
 21: _ZN17RobloxApplication6notifyEP7QObjectP6QEvent
 22: _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent
 23: _ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData
 24: _ZN28QCocoaEventDispatcherPrivate19processPostedEventsEv
 25: _ZN28QCocoaEventDispatcherPrivate26postedEventsSourceCallbackEPv
 26: __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
 27: __CFRunLoopDoSource0
 28: __CFRunLoopDoSources0
 29: __CFRunLoopRun
 30: CFRunLoopRunSpecific
 31: RunCurrentEventLoopInMode
 32: ReceiveNextEventCommon
 33: _BlockUntilNextEventMatchingListInModeWithFilter
 34: _DPSNextEvent
 35: -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
 36: -[NSApplication run]
 37: _ZN21QCocoaEventDispatcher13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE
 38: _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE
 39: _ZN16QCoreApplication4execEv
 40: main

Presumably due to this: https://github.com/gfx-rs/gfx/blob/b2b3f8a8d629556504ed3200f7d894a908fc7380/src/backend/metal/src/internal.rs#L381-L382

[kvark]

Thanks for the bug! Yes, this is the cubemap path (left behind), we'll fix it ASAP.

[kvark]

@zeux we've made the gfx-portability 0.2 release containing the cubemap fixes.

[zeux]

@kvark Thanks! This is looking much better. I can now see geometry on screen so our UI & post-fx passes seem to mostly work. There's a couple of issues with texture arrays and instancing, I'll file them shortly.

[zeux]

This almost worked :P We use cubemap blitting to generate mipmaps for cubemaps; with this change there are no validation errors, but the cubemap is mostly black; face 0 in mip level 1 has valid contents, but all other faces are black. Unfortunately the shader doesn't have source so I don't have an easy way to debug this. I'll need to look at the command buffer closer. FWIW we do one blit per face as a workaround for drivers that ignore layerCount during blits. On the bright side, besides this and a potential presentation issue where vkAcquireNextImageKHR returns an error code in some cases I don't see any other issues.

[kvark]

face 0 in mip level 1 has valid contents, but all other faces are black

Uh oh. I locally modified the CTS to test this (there is a pending PR in Khronos gerrit). I guess I screwed that up somehow... going to rewrite that PR regardless so hopefully find the source of the problem.

Unfortunately the shader doesn't have source so I don't have an easy way to debug this.

That's a bug on our side - should include debug info in build.rs under Debug configuration. cc @grovesNL

[zeux]

This is stale and needs revisiting after gfx updates; I will close this and open a new issue with more up to date information if that's still a problem.