coxmi

> but the bindless approach can give you both ergonomics and performance in some cases (not all). Certainly it can reduce CPU overhead - passing a single pointer to a shader is much faster than heavy bind group updates. The trade off is that you might have more pointer indirection on the GPU, which can introduce stalls.

Yeah I'm totally with you there, it just feels like the interfaces aren't that pleasant at the moment (although I've not tried Metal)

Edit: didn't realise you were the project author, I think it's great by the way!

Sorry, I wasn't clear (and have edited the post), I absolutely do believe that usability is important, and to be honest I feel like it's the main problem with graphics APIs (at least for my skill level).

Where I'm at now is that Vulkan is great because it's removed so many of the hard-coded assumptions that were previously hidden in the driver layer, allowing much greater CPU and GPU utilisation and performance when you need it (if you can get past the ugly APIs).

Where the usability stuff comes in is that it allows for the creation of alternative, higher-level shader-reflection setups that work brilliantly for simple use cases, all in user-space, which can open up shader programming for creative coders and a broader spectrum of developers. The lower-level APIs are then still accessible to those who absolutely need those performance levers.

I wonder what the dev/CI process looks like on this.

Will it ultimately be manually loading a build into specific hardware each time, or is there a level of automation that can be done here?

Thanks for the detailed answer :)

All this does for me is raise the question of why they chose to use the `.` for so many different uses. I'd be fine if it was just to infer the type, but it seems very overloaded.

Yeah, after looking it up, it looks like it is basically only used as either field access or an 'infer operator', is that right?

I thought it was used in four completely separate ways:

· normal struct field access

· anonymous struct definition

· field definition within structs (for reasons to do with the parser)

· an extra 'infer operator' for syntactic sugar

But there's no support for anonymous structs/fields, and all structs and fields require a type somewhere for it to be inferred. Which is why this is invalid zig:

  const test = .{ .x = 0, .y = 1 };

(It would need the type to be specified in the called function definition, or inline when assigning)

Correct me if I'm wrong here! (And thank you)

The dot syntax used everywhere really confuses me. I get its use in struct fields, or for defining anonymous structs, but what is this one for? (Some kind of module-level enum space, where .sampler and .unknown are defined previously?)

  const Sampler = @SpirvType(.sampler);
                             ^

  const Image = @SpirvType(.{ .image = .{
    .usage = .{ .sampled = u32 },
    .format = .unknown,
              ^
  } });

Everything else about zig is quite readable, but this gets me every time. Maybe I'm being dumb though.

Great stuff!

I can imagine the financial modelling side is a particularly difficult balance, yeah. Mod support sounds amazing though, I'll keep a look out. :)

This looks great. I've had a quick look through the docs and can't see anything about bikes under transport, or, under housing, anything relating to modes of tenure that aren't private rentals (e.g. Vienna-style social housing, housing co-operatives, or private ownership). Would be lovely to play around with those variables.

Also, for finance, is there a particular reason why the finance sector calculations look quite simple (on the face of it, at least)? They seem only to be a percentage lift based on aura, rather than anything resembling any number of complex sectoral dynamics, from full rentier-financial domination to prudent support of industry/services.

Thank you!

The point of civilisation, however loose that idea may be, if it’s anything at all, is determined by people.

Technology exists today in a way that feels like it could be defining its own path in a sense, but much like oral tradition, neither are large enough concepts to describe civilisation.

This is an insane claim:

> The entire point of civilization and society is that we are all "addicted" to technology and progress.

Technology is like much of material reality, in that we can think whatever the hell we like about its various forms, especially so if we’re surrounded by it.

Is there a general preference for serifs, or a local style in Finland for this reason?

German certainly has typographic preferences that err toward taller x-heights and narrower forms due to heavy use of portmanteaus. It’d be interesting to know of other language-specific typographic styles too.

This sounds really interesting, do you have any more info or a repo to follow?