| 18 May 2022 |
 jimb | ooooohhhhh | 04:08:09 |
| jimb | they do not agree on Label, shoulda checked one step deeper | 04:08:24 |
| jimb | okay, I see now that playing with label types is a thing. I guess the simplification I was hoping I could score is not going to happen. | 04:12:59 |
| jimb | * okay, I see now that playing with label types is a thing throughout the code base (calls to map_label everywhere). I guess the simplification I was hoping I could score is not going to happen. | 04:15:00 |
|  @judithbnks:matrix.org left the room. | 10:39:40 |
|  @californiatokens:matrix.org left the room. | 11:01:43 |
 ellipsoid | In reply to @kvark:matrix.org
Next season? They’ve been pretty bare lately. Nothing beats the original. I preferred the original as well. Although, in part 2 additional factors must contribute: (1) I knew less at the time; (2) society was far less developed, as was AI and talk of cyborgs. Some of my first impressions upon watching the original GiTS series were: (1) This is so well drawn! (2) I love the complexity of these matters. (3) Finally, someone is talking about stuff that matters (e.g., what it means to be human, the coming of AI, etc.). These concepts are more commonplace now. I don't think the new series on Netflix hits the same heights, but as mentioned, society has changed too. I initially quite disliked the new format (the CGI versus drawn), and would still prefer a return to the 'older' format. But, I did enjoy the series. After waiting so long for anything new in that direction, it was great to finally receive something. They did have nice touches. I enjoyed watching Batou help out the elderly folk at the bank, and the dilemma they were facing at 'having no purpose in life'. But nothing really 'hit as hard', as say, that episode where the child with the terminal illness placed his mind into a tank to go see his parents. In any case, I look forward to the next installation of the series via Netflix in less than a week now. | 11:08:55 |
| ellipsoid | I've a basic question here: I see a lot of WGSL with this double bracket syntax, as in: [[stage(vertex)]], and then I also see syntax such as @vertex. Scanning the latest documentation, the @ token represents an attr and I can read its purpose there. I take it these 2 representational forms are bijective -- and I do think the @ token is a significant simplification. However, my code fails to run when I swap the [[...]] for @. I'm using wgpu .12. | 11:11:05 |
| ellipsoid | I am currently comparing various tutorial files, paring them down to bare minima, to attempt to determine the root cause. If I missed something obvious in the documentation, please feel free to point it out. Thank you. | 11:17:39 |
 teoxoy | ellipsoid there is currently no release that has the `@` attribute syntax (it's a relatively new change) | 11:22:09 |
| ellipsoid | Ah. Thanks teoxoy. I was reviewing the official examples from Github. I had not realized that code was not yet released in a crate or otherwise. | 11:25:46 |
| ellipsoid | Do you know the standard way to look at changelogs, or to keep up to date on any changes? I don't see anything obvious on the w3c site. | 11:30:31 |
| ellipsoid | I'd like to start breathing WebGPU syntax in the weeks to come. | 11:30:50 |
 Kangz | The [[attr]] syntax has been replaced in the spec with @attr, it's just that Naga hasn't implemented it yet. | 11:30:56 |
| ellipsoid | Thanks Kangz . | 11:31:19 |
| Kangz | There is no changelog because there isn't a v1 yet. The best thing is https://github.com/gpuweb/gpuweb/commits/main :/ | 11:31:25 |
| Kangz | https://dawn.googlesource.com/dawn/+/refs/heads/main/docs/tint/origin-trial-changes.md could help too | 11:32:00 |
| ellipsoid | Great. Good to know, instead of hunting for it. I'll keep tabs on the public commit log then. | 11:32:01 |
| Kangz | Tint is closer to the upstream spec so you can see the major changes in that changelog | 11:32:13 |
| ellipsoid | Thanks! | 11:32:47 |
 hugoam | Hello there, I'm back working on WebGPU topics after a good while. I'm working on a project that has been looking at Naga for shader compiling in the context of a C++ project (I guess the benchmarks from february are not entirely unrelated to that interest 😅).
So I'm looking a little bit into the feasibility. Looking quickly at the repo, Naga doesn't currently have C bindings, right ? If someone (say, me) had in mind to develop some interop capability, how complex would that be ? Is Naga architectured in a way that would make that easy or just feasible ? | 12:28:44 |
| hugoam | * Hello there, I'm back working on WebGPU topics after a good while. I'm working on a project that has been looking at Naga for shader compiling in the context of a C++ project (I guess the benchmarks from february are not entirely unrelated to that interest 😅).
So I'm looking a little bit into the feasibility. Looking quickly at the repo, Naga doesn't currently have C bindings, right? If someone (say, me) had in mind to develop some interop capability, how complex would that be ? Is Naga architectured in a way that would make that easy or just feasible? | 12:29:06 |
| hugoam | * Hello there, I'm back working on WebGPU topics after a good while. I'm working on a project that has been looking at Naga for shader compiling in the context of a C++ project (I guess the benchmarks from february are not entirely unrelated to that interest 😅).
So I'm looking a little bit into the feasibility. Looking quickly at the repo, Naga doesn't currently have C bindings, right? If someone (say, me) had in mind to develop some interop capability, how complex would that be? Is Naga architectured in a way that would make that easy or just feasible? | 12:29:14 |
 scoopr | I suppose that depends a little on how detailed integration you are looking at. Parsing -> providing opaque module handle -> codegen to another shader, should be relatively compact surface area for the api, and doesn't sound too bad. If you need deeper access to the module internals, then that might take some more design work | 12:34:17 |
|  @billykin:matrix.org joined the room. | 12:34:54 |
| hugoam | Well for a start we should be good with a very narrow surface area yes, we probably can be fine with what the CLI can do but as a library with C bindings, not as command line | 12:55:07 |
| hugoam | * Well the needs might evolve but for a start we should be good with a very narrow surface area yes, we probably can be fine with what the CLI can do but as a library with C bindings, not as command line | 12:55:17 |
 kvark | In reply to @kangz:matrix.org
The [[attr]] syntax has been replaced in the spec with @attr, it's just that Naga hasn't implemented it yet. Implemented a while ago, just not released on crates yet | 16:33:44 |
| @billykin:matrix.org left the room. | 16:57:07 |
|  @davis_:matrix.org left the room. | 17:36:18 |
