8 ms·

Mach Engine: The Future of Graphics (With Zig)

138 points by ArtWomb 5y ago

Ono-Sendai 5y ago
The future of graphics, can render 1 red triangle.
- Zecc 5y ago
  Was it supposed to be a black triangle? https://rampantgames.com/blog/?p=7745 https://rampantgames.com/blog/?p=7745
ArtWomb 5y ago
Everyone's building on the "bigg" (bgfx + imgui + glfw + glm) stack ;) https://github.com/yuki-koyama/bigger https://github.com/yuki-koyama/bigger
- slimsag 5y ago
  author here, I do think that's a reasonable choice of tech in general, but I won't be using most of those for Mach for various reasons: * glm -> zig has native vector types with SIMD support and I think in the long-term these could be much nicer. * bgfx is truly awesome, but I'm keen to is WebGPU for the reasons outlined in the post. * imgui - I do think it's the best thing out there currently, but I have something up my sleeve for a much better UI library built around vector graphics and have done a lot of research in this area.
  - vg_head 5y ago
    I am really interested in your research related to vector graphics!
    - slimsag 5y ago
      It'll be a bit before I can publish the paper, libraries, tooling etc. around this - it's been maybe 8 years in the making but slow - the general idea is: 1. GPUs are actually _ridiculously and stupidly_ excellent at natively rendering Bézier curves if you "limit" yourself to quadratic curves. 2. Most of the reasons designers / end users hate working with Bézier curves is because of the absolutely terrible control point manipulation that cubic curves require. 3. GPUs cannot natively render cubic curves (look at any of the papers on this and you'll find they do CPU-side translation of cubic -> quadratic before sending to the GPU in the best case) which harms perf substantially and makes animation of curves expensive. Plus handling the intersection rules is incredibly complex. ...so maybe using the 'mathematically pure' cubic curves is not actually so great after all. :) if only we had tools and formats (not SVG) that worked on isolated quadratic curves (without care for intersection) - then GPU rendering implementations wouldn't need to be absolutely horridly complex (nvidia et. al), or terrible approximations (valve SDF), we could literally send a vector graphic model directly to the GPU and have it render (and animate!) at incredible speeds, with easier to understand tools. At least - that's the idea.
      - Jarred 5y ago
        What do you think of NURBS? eg http://verbnurbs.com/ http://verbnurbs.com/. It’s intended for 3D instead of 2D, but still kind of relevant How do you plan on doing text rendering? I feel like that’s often a challenge with cross-platform UI frameworks. Electron/Chromium does this well. Often QT apps don’t handle pixel ratio correctly, or the text looks non-native.
        pcwalton 5y ago
        NURBS are a generalization of Bézier curves, so everything that applies to Bézier curves here applies to NURBS as well.
        wnkrshm 5y ago
        There are applications in CAD where I imagine working with degree 2 surfaces/curves only is going to be very tricky. What about differentials? How do you get a change of normal, how do you get a curvature tensor? Without a continuous 2nd derivative? Edit: In e.g. product design like e.g. cars, people want curvature continuity, i.e. C2 at minimum for their surfaces, because on machined surfaces, you see any curvature discontinuities as edges in reflected light... that's why degree 3 is kind of an industry standard.
  - AndyKelley 5y ago
    re: zig's SIMD vectors - I would caution you to do some proof-of-concept with some perf testing because as I understand it, these are more well suited for doing bulk operations on a large array of things, rather than for modeling linear algebra. For example, if you had 100 PointA objects and 100 PointB objects and you wanted to compute the midpoint of all of them in an output array, you would use SIMD vectors to represent, e.g. 10 X values at a time, and 10 Y values at a time, and then do the math on that, rather than to represent each Point as a separate vector. But that's just something I heard, of course real world experience would be interesting to hear about.
    - slimsag 5y ago
      Interesting to hear, thanks for the info! I imagine Zig's SIMD is still very immature, I haven't tinkered with it at all yet either - so what I said above is pure speculation about the future.
      - Jasper_ 5y ago
        Yes, you really don't want SIMD types for your vec4, that's a classic mistake, you want to chop vegetables. https://deplinenoise.files.wordpress.com/2015/03/gdc2015_afredriksson_simd.pdf https://deplinenoise.files.wordpress.com/2015/03/gdc2015_afr...
        pcwalton 5y ago
        I generally agree that vertical SIMD is more efficient than horizontal SIMD when both are options, but the dot product is kind of an unfair example: that's literally the worst case for horizontal SIMD. A fairer example would be something like 4x4 matrix times vector transformation, where horizontal SIMD is pretty efficient with AVX2 broadcast instructions.
        dnautics 5y ago
        Does SSE not have a one-cycle dot product between two vector registers? I'd be surprised if it didn't.... Though not sure if zig compiles to that assembly via llvm
- flohofwoe 5y ago
  (disclaimer: shameless plug) Here's another cross-platform alternative, auto-generated Zig bindings to the Sokol headers: https://github.com/floooh/sokol-zig https://github.com/floooh/sokol-zig This is quite a bit slimmer than using one of the WebGPU libraries like wgpu-rs or Dawn, because sokol-gfx doesn't need an integrated shader cross-compiler (instead translation from a common shader source to the backend-specific shader formats happens offline). Eventually I'd also like to support the Android, iOS and WASM backends from Zig (currently this only works from C/C++, for instance here are the samples compiled to WASM: https://floooh.github.io/sokol-html5/ https://floooh.github.io/sokol-html5/) And finally, I'd also like to become completely independent from system SDKs for easier cross-compilation, but with a different approach: by automatically extracting and directly including only the required declarations right into the source files instead of bundling them into separate git repositories (similar to how GL loaders for Windows work).
  - slimsag 5y ago
    very cool work :) If you like, add a screenshot or two and I'll include this in the next zigmonthly.org article you might also be interested to know about stub dynamic libraries, e.g. `.tbd` files on MacOS. That's what is in the Mach SDK repos primarily[0], though I'm sure you could slim them down some more with a concrete list of symbols you depend on. [0] https://github.com/hexops/sdk-macos-11.3/blob/main/root/System/Library/Frameworks/Metal.framework/Metal.tbd https://github.com/hexops/sdk-macos-11.3/blob/main/root/Syst...
  - politician 5y ago
    I love this codebase. I’ve been working with it on the side for a few weeks: it’s extremely well documented, supports Metal, has reasonable abstractions that don’t try to be the One True Way, and the Zig port looks really clean.
Lerc 5y ago
There's a lot of talk on what platforms it supports (or plans to) and how it intends to achieve that. That's nice but what will it actually provide? Does it implement an interface like Raylib? Is it a scene graph? How about an entity component system? Will game logic and graphical representation be tightly bound or kept separate? None of these things are necessarily good, bad, required or forbidden, but they're fairly important to know before you dive in.
- slimsag 5y ago
  The project is only 4 months old :) I will get to those bits and explain my vision there once the groundwork is done. In general, I have a preference of providing (1) solid groundwork, (2) libraries, and (3) extensive tooling. We're only at phase 1/3 :) I don't want to _force_ one way of interacting with this, either. You're free to take the work I've done on making GLFW easy to use and build on top of that (several people are), same with the upcoming WebGPU work. But yes, there will eventually be a graphical editor, component system, and "obvious" ways to structure your code if that's not something you want to choose for yourself.
  - yAak 5y ago
    As a mobile dev, any effort to abstract away platform fragmentation craziness is highly commendable in my eyes. Excited to see where this takes you!
jakearmitage 5y ago
This effort seems to be born out of frustration with build systems for cross-platform engines, not really with the engines.
LordRishav 5y ago
Perhaps the name can be a little problem, due to the existence of the Mach kernel (https://en.wikipedia.org/wiki/Mach_(kernel) https://en.wikipedia.org/wiki/Mach_(kernel)). Nevertheless, the toolkit does look great.
baxuz 5y ago
So WASM seems to be in a good place when it comes to code portability and performance, and now WebGPU does as well. It's great to see how the web is giving back to the native platforms.
ksec 5y ago
>DirectX 13 is coming by the end of 2022. Is that confirmed? I cant search anything official and Windows 11 was suppose to be the moment they could do DX13 ( DX12 Ultimate was a naming madness ). But they didn't.

138 points by ArtWomb 5y ago

Ono-Sendai 5y ago

The future of graphics, can render 1 red triangle.

Zecc 5y ago
Was it supposed to be a black triangle? https://rampantgames.com/blog/?p=7745 https://rampantgames.com/blog/?p=7745

ArtWomb 5y ago

Everyone's building on the "bigg" (bgfx + imgui + glfw + glm) stack ;) https://github.com/yuki-koyama/bigger https://github.com/yuki-koyama/bigger

slimsag 5y ago
author here, I do think that's a reasonable choice of tech in general, but I won't be using most of those for Mach for various reasons: * glm -> zig has native vector types with SIMD support and I think in the long-term these could be much nicer. * bgfx is truly awesome, but I'm keen to is WebGPU for the reasons outlined in the post. * imgui - I do think it's the best thing out there currently, but I have something up my sleeve for a much better UI library built around vector graphics and have done a lot of research in this area.
- vg_head 5y ago
  I am really interested in your research related to vector graphics!
  - slimsag 5y ago
    It'll be a bit before I can publish the paper, libraries, tooling etc. around this - it's been maybe 8 years in the making but slow - the general idea is: 1. GPUs are actually _ridiculously and stupidly_ excellent at natively rendering Bézier curves if you "limit" yourself to quadratic curves. 2. Most of the reasons designers / end users hate working with Bézier curves is because of the absolutely terrible control point manipulation that cubic curves require. 3. GPUs cannot natively render cubic curves (look at any of the papers on this and you'll find they do CPU-side translation of cubic -> quadratic before sending to the GPU in the best case) which harms perf substantially and makes animation of curves expensive. Plus handling the intersection rules is incredibly complex. ...so maybe using the 'mathematically pure' cubic curves is not actually so great after all. :) if only we had tools and formats (not SVG) that worked on isolated quadratic curves (without care for intersection) - then GPU rendering implementations wouldn't need to be absolutely horridly complex (nvidia et. al), or terrible approximations (valve SDF), we could literally send a vector graphic model directly to the GPU and have it render (and animate!) at incredible speeds, with easier to understand tools. At least - that's the idea.
    - Jarred 5y ago
      What do you think of NURBS? eg http://verbnurbs.com/ http://verbnurbs.com/. It’s intended for 3D instead of 2D, but still kind of relevant How do you plan on doing text rendering? I feel like that’s often a challenge with cross-platform UI frameworks. Electron/Chromium does this well. Often QT apps don’t handle pixel ratio correctly, or the text looks non-native.
      - pcwalton 5y ago
        NURBS are a generalization of Bézier curves, so everything that applies to Bézier curves here applies to NURBS as well.
        wnkrshm 5y ago
        There are applications in CAD where I imagine working with degree 2 surfaces/curves only is going to be very tricky. What about differentials? How do you get a change of normal, how do you get a curvature tensor? Without a continuous 2nd derivative? Edit: In e.g. product design like e.g. cars, people want curvature continuity, i.e. C2 at minimum for their surfaces, because on machined surfaces, you see any curvature discontinuities as edges in reflected light... that's why degree 3 is kind of an industry standard.
- AndyKelley 5y ago
  re: zig's SIMD vectors - I would caution you to do some proof-of-concept with some perf testing because as I understand it, these are more well suited for doing bulk operations on a large array of things, rather than for modeling linear algebra. For example, if you had 100 PointA objects and 100 PointB objects and you wanted to compute the midpoint of all of them in an output array, you would use SIMD vectors to represent, e.g. 10 X values at a time, and 10 Y values at a time, and then do the math on that, rather than to represent each Point as a separate vector. But that's just something I heard, of course real world experience would be interesting to hear about.
  - slimsag 5y ago
    Interesting to hear, thanks for the info! I imagine Zig's SIMD is still very immature, I haven't tinkered with it at all yet either - so what I said above is pure speculation about the future.
    - Jasper_ 5y ago
      Yes, you really don't want SIMD types for your vec4, that's a classic mistake, you want to chop vegetables. https://deplinenoise.files.wordpress.com/2015/03/gdc2015_afredriksson_simd.pdf https://deplinenoise.files.wordpress.com/2015/03/gdc2015_afr...
      - pcwalton 5y ago
        I generally agree that vertical SIMD is more efficient than horizontal SIMD when both are options, but the dot product is kind of an unfair example: that's literally the worst case for horizontal SIMD. A fairer example would be something like 4x4 matrix times vector transformation, where horizontal SIMD is pretty efficient with AVX2 broadcast instructions.
        dnautics 5y ago
        Does SSE not have a one-cycle dot product between two vector registers? I'd be surprised if it didn't.... Though not sure if zig compiles to that assembly via llvm
flohofwoe 5y ago
(disclaimer: shameless plug) Here's another cross-platform alternative, auto-generated Zig bindings to the Sokol headers: https://github.com/floooh/sokol-zig https://github.com/floooh/sokol-zig This is quite a bit slimmer than using one of the WebGPU libraries like wgpu-rs or Dawn, because sokol-gfx doesn't need an integrated shader cross-compiler (instead translation from a common shader source to the backend-specific shader formats happens offline). Eventually I'd also like to support the Android, iOS and WASM backends from Zig (currently this only works from C/C++, for instance here are the samples compiled to WASM: https://floooh.github.io/sokol-html5/ https://floooh.github.io/sokol-html5/) And finally, I'd also like to become completely independent from system SDKs for easier cross-compilation, but with a different approach: by automatically extracting and directly including only the required declarations right into the source files instead of bundling them into separate git repositories (similar to how GL loaders for Windows work).
- slimsag 5y ago
  very cool work :) If you like, add a screenshot or two and I'll include this in the next zigmonthly.org article you might also be interested to know about stub dynamic libraries, e.g. `.tbd` files on MacOS. That's what is in the Mach SDK repos primarily[0], though I'm sure you could slim them down some more with a concrete list of symbols you depend on. [0] https://github.com/hexops/sdk-macos-11.3/blob/main/root/System/Library/Frameworks/Metal.framework/Metal.tbd https://github.com/hexops/sdk-macos-11.3/blob/main/root/Syst...
- politician 5y ago
  I love this codebase. I’ve been working with it on the side for a few weeks: it’s extremely well documented, supports Metal, has reasonable abstractions that don’t try to be the One True Way, and the Zig port looks really clean.

Lerc 5y ago

There's a lot of talk on what platforms it supports (or plans to) and how it intends to achieve that. That's nice but what will it actually provide? Does it implement an interface like Raylib? Is it a scene graph? How about an entity component system? Will game logic and graphical representation be tightly bound or kept separate? None of these things are necessarily good, bad, required or forbidden, but they're fairly important to know before you dive in.

slimsag 5y ago
The project is only 4 months old :) I will get to those bits and explain my vision there once the groundwork is done. In general, I have a preference of providing (1) solid groundwork, (2) libraries, and (3) extensive tooling. We're only at phase 1/3 :) I don't want to _force_ one way of interacting with this, either. You're free to take the work I've done on making GLFW easy to use and build on top of that (several people are), same with the upcoming WebGPU work. But yes, there will eventually be a graphical editor, component system, and "obvious" ways to structure your code if that's not something you want to choose for yourself.
- yAak 5y ago
  As a mobile dev, any effort to abstract away platform fragmentation craziness is highly commendable in my eyes. Excited to see where this takes you!

jakearmitage 5y ago

This effort seems to be born out of frustration with build systems for cross-platform engines, not really with the engines.

LordRishav 5y ago

Perhaps the name can be a little problem, due to the existence of the Mach kernel (https://en.wikipedia.org/wiki/Mach_(kernel) https://en.wikipedia.org/wiki/Mach_(kernel)). Nevertheless, the toolkit does look great.

baxuz 5y ago

So WASM seems to be in a good place when it comes to code portability and performance, and now WebGPU does as well. It's great to see how the web is giving back to the native platforms.

ksec 5y ago

>DirectX 13 is coming by the end of 2022. Is that confirmed? I cant search anything official and Windows 11 was suppose to be the moment they could do DX13 ( DX12 Ultimate was a naming madness ). But they didn't.