17 Apr 2021 |
mindtree | I guess there's only so much that can be done here, as falling back implies that we have a list of features that can be used to check compatibility at the time of adpater selection, which I'm aware is still a work in progress for webgpu | 15:36:04 |
kvark | mindtree: we can't have panics, it's a bug | 15:36:09 |
kvark | What was it, exactly? | 15:36:26 |
mindtree | Hmm let me see if I can find it | 15:36:36 |
mindtree | I think it might have been an error returned by swapchain creation, but let me double check | 15:37:08 |
kvark | In reply to @mindtree:matrix.org I guess there's only so much that can be done here, as falling back implies that we have a list of features that can be used to check compatibility at the time of adpater selection, which I'm aware is still a work in progress for webgpu Adapters do have a set of features exposed | 15:37:17 |
kvark | In reply to @mindtree:matrix.org I think it might have been an error returned by swapchain creation, but let me double check What panicked, exactly? Did you provide the surface to adapter selection? | 15:38:11 |
mindtree | Ah no, it was an unreachable in gfx_backend_vulkan by the looks of it https://github.com/nannou-org/nannou/issues/724 | 15:39:01 |
mindtree | I asked them to test my wgpu 0.7 PR and they mentioned they're still getting the same bug, but I'll ask for the new stack trace to confirm it's still the same thing | 15:39:33 |
kvark | We can't fix bugs that aren't reported. This one will be trivial. | 15:40:53 |
mindtree | ah my bad, they already did provide the stacktrace https://github.com/nannou-org/nannou/pull/726#issuecomment-820813233 | 15:41:15 |
mindtree | Of course, I think we did recommend doing so in matrix but it was hard enough to get a stack trace first - that issue started as "Literally all examples panic" with no content :) | 15:42:02 |
mindtree | * Of course, I think we did recommend doing so in matrix but it was hard enough to get a stack trace first - that issue started as "Literally all examples panic" with no content :) | 15:42:44 |
kvark | Please file it on gfx if that's what panics | 15:51:23 |
kvark | It might have already been fixed in master | 15:52:28 |
mindtree | Yep am doing so now 👍️ | 15:55:46 |
mindtree | * Yep am doing so now 👍️ | 15:55:56 |
scoopr | Resizing windows. Who woulda thunk it'd be so hard :) | 16:07:30 |
mindtree | Seriously, over the last few yrs of using/contributing to winit and various graphics backends, resizing windows has been a great source of mind benders | 16:12:08 |
mindtree | kvark: I noticed that while PowerPreference 's Default variant was changed to LowPower , the Default trait implementation still remains. Is this left over by mistake? Or perhaps to avoid breakage? Or because it really is the recommended default? | 16:13:49 |
scoopr | you can check my notes on my resize-fueled-adventure https://github.com/gfx-rs/gfx/pull/3627 | 16:15:42 |
kvark | mindtree: it's good to have defaults | 16:15:56 |
scoopr | checking all kinds of combinations of winit code, gfx code, and my app code to behave nicely in synchrony is a bit of a pain :) | 16:16:54 |
mindtree | In reply to @kvark:matrix.org mindtree: it's good to have defaults I agree, I'm just wondering if I'm shooting myself in the foot by making HighPerformance the default for nannou whose applications tend to revolve around graphics intensive sketches etc. In other words, is it the default because more devices "just work" with LowPower or is it the ddefault just because there might as well be a default? | 16:17:33 |
mindtree | In reply to @scoopr:matrix.org checking all kinds of combinations of winit code, gfx code, and my app code to behave nicely in synchrony is a bit of a pain :) I bet... I commend your efforts for diving in and working it out though :) I think the most disbelief I had while learning about the resizing on different OSes was learning about how macOS does a full context switch when a resize begins... I think this has resulted in multiple rewrites of the winit macos backend over time haha | 16:20:26 |
scoopr | IIRC, MTLCreateSystemDefaultDevice actually returns lowpower when on battery and highpower when not on battery, though I can't find a reference for that anywhere .. | 16:20:47 |
scoopr | I think win32 also goes to a inner runloop when resizing | 16:21:42 |
kvark | In reply to @mindtree:matrix.org I agree, I'm just wondering if I'm shooting myself in the foot by making HighPerformance the default for nannou whose applications tend to revolve around graphics intensive sketches etc. In other words, is it the default because more devices "just work" with LowPower or is it the ddefault just because there might as well be a default? It shouldn't affect what works and what doesn't, it's just a hint. For nannou, HighPerformance is definitely what you want. | 17:58:54 |
kvark | hugoam: the mapping is fixed in latest nightly | 20:35:33 |
18 Apr 2021 |
| ccwu660601 joined the room. | 04:07:52 |