| 6 Oct 2022 |
 i509vcb | I assume anything you reference within a recorded render bundle must live as long as you continue to replay the bundle? | 18:43:46 |
 cwfitzgerald | It will live that long, but you don't need to keep it alive, the render bundle owns it | 18:44:44 |
| i509vcb | Okay so under the hood the render bundle will keep anything it needs alive | 18:45:14 |
| cwfitzgerald | Yes, once you call finish | 18:45:41 |
| i509vcb | I assume the underlying vertex/instance buffers can't be mutated then or else a draw command could have not enough data | 18:46:53 |
| i509vcb | Sounds really like something you would use for something very static | 18:47:12 |
| cwfitzgerald | You can mutate them fine | 18:47:12 |
| i509vcb | Well the draw count couldn't be changed though? | 18:47:27 |
| cwfitzgerald | Correct | 18:47:37 |
| cwfitzgerald | (unless it was an indirect call) | 18:47:45 |
 Gents | Mmm I'm using indirect 😅 so render bundles will not actually make it anything better right? Or implementing secondary command buffers for them would make them more interesting? | 18:50:13 |
| i509vcb | I am not working on replaying commands yet, but it could be useful in the case that I could be a rendering a surface into 3 dmabuf all of different formats | 18:52:26 |
| i509vcb | (display 1, display 2, screen capture for example) | 18:53:01 |
| cwfitzgerald | In reply to @i509vcb:matrix.org
I am not working on replaying commands yet, but it could be useful in the case that I could be a rendering a surface into 3 dmabuf all of different formats Pipelines have the format baked in though | 19:29:35 |
| i509vcb | Yeah I know of the pipelines as well | 19:29:57 |
 crowlkats | cwfitzgerald so investigated the trouble of running newer commits of cts: basically cts used to have an out/ directory which the deno script would use as it contained the transpiled typescript that is being used for the node runner, however at some point that out dir was taken out of git and is just gitignored now, and building it will need to have node installed in CI to generate it, though even then, i tried and no clue how to generate it... ideally cts would commit that folder in again, but unsure who to talk to about that. | 20:12:53 |
| cwfitzgerald | installing node in CI is also an option if that would be easier | 20:14:41 |
| cwfitzgerald | #WebGPU:matrix.org would be where to talk about it (besides CTS github issues) | 20:14:57 |
| crowlkats | In reply to @cwfitzgerald:matrix.org
#WebGPU:matrix.org would be where to talk about it (besides CTS github issues) aight, will ask there | 20:16:38 |
| cwfitzgerald | thanks for looking into this! | 20:16:54 |
| crowlkats | In reply to @cwfitzgerald:matrix.org
thanks for looking into this! alright, cts is now working. some failing tests and no idea what the cause is for those; doubt i will be able to help too much with that though | 22:00:14 |
| cwfitzgerald | cool I can take it from here | 22:00:52 |
| crowlkats | also, i have no clue about this test.lst file, or how to properly have it update | 22:01:07 |
| cwfitzgerald | it's an intentional allow list so we only run stuff we can pass | 22:01:29 |
| cwfitzgerald | I think what we should be doing probably is running the whole CTS and then diffing the results | 22:02:08 |
| crowlkats | ah ok | 22:02:36 |
| cwfitzgerald | crowlkats: what exactly does the cts_runner component do? | 22:10:15 |
| crowlkats | basically just create a very slim deno binary with just webgpu & read and write file functionality | 22:12:00 |
| crowlkats | * basically just create a very slim deno binary with just deno_webgpu & read and write file functionality | 22:12:31 |
|  @unrelentingtech:mozilla.org left the room. | 22:15:29 |
