| 27 Jul 2021 |
 doycie | IT IS WORKING!
I found a couple of examples using: features = ["webgl"] which is why I copied it aswell. I hope people realise they are not actually running webgpu in that case.
thank you a lot mr groves! | 22:25:32 |
 groves | In reply to @cwfitzgerald:matrix.org
Couldn't we implement it as always returning the one webgpu device? IIRC it’s problematic because we’d need to request an adapter internally or similar (i.e. using some default adapter options), so we should probably just encourage using that API instead | 22:25:57 |
| doycie | Seeing it working on an old android phone is actually beautiful 🤯, I hope you people understand how amazing you are. | 22:42:55 |
 kvark | Nothing motivates more than kind words:) | 23:06:53 |
| 28 Jul 2021 |
 m4b | noticing this (new) validation error after updating vulkan intel, on wgpu 0.9:
VALIDATION [UNASSIGNED-CoreValidation-Shader-InconsistentSpirv (0x6bbb14)] : Validation Error: [ UNASSIGNED-CoreValidation-Shader-InconsistentSpirv ] Object 0: handle = 0x55fdf3e0b130, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x6bbb14 | SPIR-V module not valid: Expected input to have different bit width from Result Type: FConvert
%56 = OpFConvert %v2float %55
object info: (type: DEVICE, hndl: 0x55fdf3e0b130)
| 02:23:50 |
| kvark | that sounds familiar | 03:58:51 |
| kvark | m4b: would you mind filing it on Naga? | 03:59:31 |
| kvark | I think the solution is simply avoid OpFConvert generation in SPV-out | 03:59:41 |
| kvark | if the bit width doesn't change | 03:59:47 |
| kvark | PSA: texture usage renames are coming in https://github.com/gfx-rs/wgpu/pull/1738 | 04:12:50 |
| kvark | sorry about all the broken code! we are just matching upstream | 04:13:03 |
 cwfitzgerald (wgpu, rend3) | nice | 04:13:21 |
| cwfitzgerald (wgpu, rend3) | I think that's a bit more reasonable | 04:13:41 |
| kvark | another PSA: WGSL syntax for storage buffers/textures is now updated in Naga - https://github.com/gfx-rs/naga/pull/1142 | 05:48:04 |
| kvark | that's going to break some code (sorry! just catching up to the spec) | 05:48:18 |
| cwfitzgerald (wgpu, rend3) | Is there a tldr of the new syntax? (maybe there should be in the changelog of wgpu) | 05:51:43 |
| cwfitzgerald (wgpu, rend3) | * Is there a tldr of the new syntax? (maybe there should be in the changelog of wgpu) | 05:51:57 |
| kvark | https://github.com/gpuweb/gpuweb/issues/1604 has some info | 05:53:15 |
| kvark | basically, storage access is a part of the type for textures, and a part of the var<...> parameters for buffers now | 05:53:39 |
| kvark | I agree wgpu changelog would need to mention this explicitly | 05:53:53 |
|  maroider changed their profile picture. | 06:33:11 |
| m4b | No one likes breaking syntax changes but thank you kvark and all the other webgpu members who have what appears to be infinite energy to continue improving and discussing and stewarding webgpu into its (hopefully soon!) future | 14:25:57 |
 imbris | cwfitzgerald (wgpu, rend3): is there are way to force the dx12 debug layers on in visual studio? (e.g. for debugging a release build). I don't have access to a Windows machine atm so I can't explore the options... but I want to try to help a user collect more information about a device lost error (if they are willing to install visual studio). | 18:00:23 |
| kvark | Yes, via dxcpl - the control panel | 19:39:37 |
| cwfitzgerald (wgpu, rend3) | and make sure to search for dxcpl not dx control panel, they're different applications for some reasons | 19:57:57 |
| cwfitzgerald (wgpu, rend3) | * and make sure to search for dxcpl not dx control panel, they're different applications for some reasons | 19:57:58 |
| kvark | Are they? | 20:37:32 |
| cwfitzgerald (wgpu, rend3) | yeah, one will allow you to do more than the other | 20:46:55 |
| cwfitzgerald (wgpu, rend3) | dxcpl ships with the DX tooling and the control panel ships with windows | 20:50:53 |
| cwfitzgerald (wgpu, rend3) | Or something like that | 20:50:56 |
