| 27 Mar 2024 |
 eddyb | there have to be a dozen slightly different takes on that idea by now, but if I had to do an ecosystem survey to figure out exactly what's out there, I would either give up or publish the 13th take anyway :P | 08:42:12 |
| eddyb | also "unique" stuff is usually called "interner" tho I wouldn't be surprised if there's a few more names for that idea | 08:43:27 |
| eddyb | (SPIR-T annoyingly has similar data structures to any of these "entity" map things that are flat arrays, but with an extra hierarchical complication I haven't seen elsewhere, so it's all homebrew for now. it combines globally unique IDs like SPIR-V, with being able to contiguously allocate IDs independently for each function. basically there's a "chunk" size under which a function is on the fast path with only contiguous storage/access and larger functions have to use multiple chinks with an extra level of B-tree map or whatever. still, globally unique IDs + per-function ownership is a nice combo for my needs, and the numbers can be tweaked to benefit the common case) | 08:52:29 |
 wumpf |
I would either give up or publish the 13th take anyway :P
good take actually, heh. that's usually how it goes with these more basic utilitites
| 10:16:05 |
| 28 Mar 2024 |
|  MohitJaix joined the room. | 09:44:54 |
 Daniel McNab | In Vello, we've run into a case of the uniformity analysis being non-spec compliant - this is at vello#535
Is it helpful to track this down, or should we expect this to be fixed by Naga implementing a spec-compliant algorithm? | 16:30:18 |
| 30 Mar 2024 |
 Vladislav Grechannik | Hi guys, I've run into a problem running cargo test --all-features --workspace on the repo. Is it currently broken on the trunk branch, or is it just my machine acting up? | 12:47:24 |
| Vladislav Grechannik | 
Download After fixing unclosed bracket here (the class scope isn't properly closed, so you cant start defining const and function), it gave me this error:
`ext:cts_runner/bootstrap.js not present in the module map` | 12:52:14 |
| Vladislav Grechannik | After fixing unclosed bracket here (the class scope isn't properly closed, so you cant start defining const and function), it gave me this error:
`ext:cts_runner/bootstrap.js not present in the module map | 12:53:03 |
| Vladislav Grechannik | After fixing unclosed bracket here (the class scope isn't properly closed, so you cant start defining const and function), it gave me this error:
ext:cts_runner/bootstrap.js not present in the module map | 12:53:11 |
 ErichDonGubler | We're planning on completely re-implementing the uniformity analysis; the current one simply doesn't do what the spec. asks. Do y'all need the diagnostic opt-out (i.e., diagnostic(off,derivative_uniformity)) for now? I've asked a similar question just now in wgpu#3135.
CC jimb, teoxoy.
| 17:40:25 |
| ErichDonGubler | * We're planning on completely re-implementing the uniformity analysis; the current one simply doesn't do what the spec. asks. Would the standard diagnostic trigger filtering for WGSL do what y'all need (i.e., diagnostic(off,derivative_uniformity))? I've asked a similar question just now in wgpu#3135. We're considering implementing it soon, but we're also considering "just" implementing the correct uniformity analysis soon.
CC jimb, teoxoy.
| 17:42:32 |
| Daniel McNab | The direction of the implementation being wrong was "in our favour", i.e. it accepted something by-spec invalid (which was, incidentally, actually uniform :D)
That is, we're happy to work within the constraints of uniformity analysis, but in this case we had to make changes to work with tint | 17:47:50 |
| Daniel McNab | * The direction of the implementation being wrong was "in our favour", i.e. it accepted something by-spec invalid (which was, incidentally, actually uniform once doing control flow :D)
That is, we're happy to work within the constraints of uniformity analysis, but in this case we had to make changes to work with tint | 17:48:05 |
| Daniel McNab | * The direction of the implementation being wrong was "in our favour", i.e. it accepted something by-spec invalid (which was, incidentally, maintained uniform control flow :D)
That is, we're happy to work within the constraints of uniformity analysis, but in this case we had to make changes to work with tint | 17:48:15 |
| Daniel McNab | * The direction of the implementation being wrong was "in our favour", i.e. it accepted something by-spec invalid (which was, incidentally, maintained uniform control flow :D)
That is, we're happy to work within the constraints of uniformity analysis, but in this case we had to make changes to work with tint (for Chrome compatibility) | 17:48:26 |
| Daniel McNab | If the specific issue we ran into doesn't need tracking down, that's mostly great for us, as it saves the time doing that | 17:49:27 |
| Daniel McNab | For me personally, I'd be happy just sticking with the only definitely valid set, but Raph might be able to answer about scoped disabling of the check | 17:52:45 |
| Daniel McNab | We're not using derivatives (afaik) | 17:53:56 |
| ErichDonGubler | Asked in #wgpu:matrix.org for you: https://matrix.to/#/!FZyQrssSlHEZqrYcOb:matrix.org/$MIEZ-14TnHuQ8F18asRMMmfEdBVwkzyCt9Vu4ACKzPQ?via=matrix.org&via=mozilla.org&via=envs.net | 17:54:18 |
| ErichDonGubler | I think you'll want to chat with @crowlKats there, if this is Deno-related (which IIRC cts_runner is). | 17:54:35 |
|  crowlkats joined the room. | 17:55:41 |
| crowlkats | i really need to update deno in the wgpu repo. will do that in the next few hours | 17:57:14 |
| crowlkats | and that error makes no sense | 17:58:20 |
| crowlkats | ill look into it asap | 17:58:45 |
 jimb | In reply to @lylythechosenone:matrix.org
would anybody be willing to move Arena/UniqueArena outside of naga, so that they can be used in other crates? Another crate in the wgpu namespace? Sure. | 22:08:00 |
| jimb | The thing that worries me is that such a move implicitly suggests that Arena is "general purpose", and we may be pushed to add features that we don't need. | 22:08:43 |
| jimb | A few extra methods here and there are no problem. | 22:08:51 |
| jimb | But, for example, there's one shortcoming that Arena has now, as used in Naga: we have an Arena<Expression> in each Function, and then a global Arena<Expression> in the module, for constant expressions and overrides. If I have a Handle<Expression>, there's no way to distinguish which one it's referring to. | 22:10:11 |
| jimb | In the specific case of Naga, this isn't a big deal, and we just manage. | 22:10:20 |
