gfx: Quad example doesn't work on OS X

Okay, I had a bit of a chance to look at this over the last couple of nights. Here’s where I’m at/what I’m seeing.

Disclaimer: I’m a bit ignorant to pretty much all things graphics…so…I might be getting all this wrong. 😅

So I traced back through a typical failure from the logs. When we submit a queue we don’t return a Result which doesn’t exactly match up to vkQueueSubmit. This is where the error first manifests itself. Might consider changing gfx_hal::queue::CommandQueue’s submit method to return a Result to catch the error sooner?

@buzmeg observed take_drawable failing, but I believe this is operating as designed. If there’s no drawable to take then it should bail out. I think None is always an error because the fence should prevent the race described. I haven’t fully traced that, so take with a grain of salt, but my next observation I think further solidifies this for me.

I opened with the initial error happening during queue submission. During queue submission the trace is:

     at window.rs::gfx_backend_metal::window::SurfaceInner::next_frame::_$u7b$$u7b$closure$u7d$$u7d$::h655ca9c47527b2ae:127
     at autorelease.rs::objc::rc::autorelease::autoreleasepool::hb806d60b31173f4f:29
     at window.rs::gfx_backend_metal::window::SurfaceInner::next_frame::hb99c61ac413b95af:90
  *  at window.rs::gfx_backend_metal::window::SwapchainImage::wait_until_ready::h384367e4c220bed9:275
     at command.rs::gfx_backend_metal::command::CommandQueue::wait::h4ead9b298d75fb5f:1894
     at command.rs::_$LT$gfx_backend_metal..command..CommandQueue$u20$as$u20$gfx_hal..queue..RawCommandQueue$LT$gfx_backend_metal..Backend$GT$$GT$::submit::h4f406aebd81e160d:1923
     at mod.rs::gfx_hal::queue::CommandQueue$LT$B$C$C$GT$::submit::h6590d0441c153524:138
     at main.rs::quad::main::hf1c854eb28eb897a:799
     at rt.rs::std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::hf4d59476fdad3709:64
     at rt.rs::do_call<closure,i32> [inlined] {{closure}}:49
     at panicking.rs::do_call<closure,i32>:293
     at lib.rs::__rust_maybe_catch_panic:87
     at panicking.rs::lang_start_internal [inlined] try<i32,closure>:272
     at panic.rs::lang_start_internal [inlined] catch_unwind<closure,i32>:388
     at rt.rs::lang_start_internal:48
     at rt.rs::std::rt::lang_start::hdac7e6390caeec42:64

During next_frame we’re iterating over the fames in the swapchain looking for a texture received from the call to Metal’s texture based off the drawable we get on the line above. If we break there we can inspect the swapchain’s frames and the texture we received from the texture call to the drawable.

(&[gfx_backend_metal::window::Frame]) frames = &[
Frame {
  texture: Texture(&0x10280da00)
},
Frame {
  texture: Texture(&0x10303c400)
},
Frame {
  texture: Texture(&0x102816a00)
},
Frame {
  texture: Texture(&0x102815800)
}]
(metal::drawable::DrawableRef *) drawable = &0x101d5b980

Note: I’ve removed everything from the frame except the frame’s texture to make it easier to parse.

As you can tell the texture isn’t anywhere in the swapchain’s frames, and since they don’t match we (silently) fail and move on to presentation. Since we never had a chance to set the drawable of the frame take_drawable is going to fail which results in swapchain recreation and the missed render.

Interestingly when I inspect this with Xcode’s profiler (just found this, and wowah it’s pretty cool) I see this strange empty call to Metal just before every swapchain recreation.

So the question I’m asking myself now is, “Why are these textures different?” So I’ll continue from there unless someone has any insights on if I’m mistaken or know the issue given my observations.

@kvark Yeah, I can check – My renderer is a side project for me so I won’t be able to dedicate a normal amount of time to it. I will look into the root cause and see if I can drum something up when I’m working on this. (Mostly nights/weekends)

Re: wgpu-rs examples – they appear to be working as expected. Frame-rate of shadow does not look like it’s recreating the swapchain every 3rd frames, and I don’t see any output. Haven’t examined the code, but I’ll look at that tonight.

For signposts, the easiest way to proceed would be covering all of them in a new feature (#[cfg(feature = "signpost")] that is not default but enabled on CI.

Mstange has 10.12

On Thu, Mar 21, 2019, 10:46 PM Dzmitry Malyshau notifications@github.com wrote:

@buzmeg https://github.com/buzmeg sorry about not addressing this. Rolling back an OS version on Mac is rather trouble-some. I hope to get my hands on a device with 10.12 installed to investigate. If anyone has that and can look into it, that would be great!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gfx-rs/gfx/issues/2563#issuecomment-475475137, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUTbQWmHRCUnhRx1bO56zzljs8eaZ2Fks5vZEQIgaJpZM4Z5Fi- .