| 27 Feb 2020 |
| 20:57:06 |  m4b | If your file above is compiled with x86-apple-ios then I’m not sure what your issue is |
| 20:57:28 | m4b | You are on Catalina yes ? |
| 20:57:55 |  waha.06x36 | Yes. |
| 20:58:02 | waha.06x36 | I can simulate Metal just fine,. |
| 20:58:28 | waha.06x36 | And it's built with whatever cargo-lipo uses, which I think is x86_64-apple-ios? |
| 20:58:36 | m4b | Hmmm ... well you may be the first person ever running wgpu/rust code in simulator on Catalina :) |
| 20:59:01 | m4b | I don’t use cargo lipo either, it has a lot of bugs. I just have makefile that calls lipo manually |
| 20:59:32 | waha.06x36 | Yeah, that's what I planned to do but I have a patched version and it seemed to the right thing. |
| 20:59:45 | m4b | Let me dink around try to get a wgpu example running in simulator |
| 21:05:16 | waha.06x36 | kvark: I tried using the memory graph tool, and I found a leak but it's on the CPU... sigh. |
| 21:52:52 | waha.06x36 | Hmm, this time I ran out of memory before even filling up my 100MB buffer and even starting to try to free things. Surely there can't be that little memory available? |
| 21:53:52 | waha.06x36 | I found the CaptureMTLBuffer objects that seem to correspond to buffers, and there aren't many more of them than I expect. |
| 21:53:57 |  kvark | strange! |
| 21:55:18 | waha.06x36 | Very. Getting thread '<unnamed>' panicked at 'calledResult::unwrap()on anErrvalue: AllocationError(OutOfMemory(Device))', src/libcore/result.rs:1051:5 |
| 21:56:02 | waha.06x36 | Some day I'll work on a project and only have regular, everyday problems instead of mystery ones. |
| 22:10:53 | waha.06x36 | Hmm... I use wgpu_device_create_buffer_mapped and unmap immediately, but, could I be somehow running out of virtual address space? But no, iOS is all 64 bits these days isn't it... |
| 22:12:16 | kvark | I use tons of these in vange-rs, and it's fine for that case. Although, they are relatively small there. |
| 22:13:19 | waha.06x36 | Mine are all a few tens of ks, and I have 2-3 thousand alive at any moment. |
| 22:14:28 | m4b | Ya I can repro your issue waha.06x36. It’s crashing in enumerate_adapters in gfx metal backend. In particular internal.rs:496 |
| 22:15:05 | kvark | wait, what does this have to do with enumerate_adapters? thought you are talking about OOM? |
| 22:15:22 | waha.06x36 | kvark: This was the earlier issue about not working on simulator. |
| 22:16:10 | m4b | Ya, about simulator. Sorry should have clarified was following up on my last comment |
| 22:29:42 | m4b | So I think you now need the x86_64-apple-ios-macabi target on catalina. But rust up currently does not ship the std for that target, so I think you’re out of luck for now (if I’m right about the new target being required) |
| 23:07:13 | waha.06x36 | m4b: Do you have a way to test it? |
| 23:08:57 | m4b | I’d have to build stdlib with the target and then rustup link it and I’m too lazy/busy. It’s a lot of tediousness. Why do you want to run in simulator ? It’s just going to use host gpu anyway. So you aren’t testing really how it performs / works on iOS real device. |
| 23:18:19 | m4b | (Other than it being fun/more convenient for testing iOS ui control flow/application start logic) |
| 23:20:13 | waha.06x36 | Basically just convenience yeah. I have a macOS build I can use for most testing. |
| 23:22:40 | m4b | Yea that’s what I do. Every now and then load on iOS device to check everything is ok. Honestly wgpu is so cross platform and “just sort of works” (except for some corner cases in shaders) it’s been refreshing just developing on whatever machine is easiest and then checking in every now and then. It’s pretty bodacious :) |
| 23:26:04 | m4b | I became effectively convinced of this after building on windows amd discrete and it just worked identically. Contrast this with Linux + macOS with Vulkan + moltenvk and it was awful. Every other moltenvk has some regression, or was busted on real iOS, was quite stressful. |
| 23:27:26 | m4b | Not even to mention just getting the tool chain working, libraries building and linking properly for moltenvk was really unpleasant; all gone now.... ❤️ |
