Portability benchmark of Dota2 on MacOS | Hacker News Reader

Portability benchmark of Dota2 on MacOS

gfx-rs.github.io

187 pointskvark27 comments

This is exciting because gfx-rs has implementations of Vulkan on top of Metal, D3D12, D3D11, OpenGL, and Vulkan

It brings back the option of writing one graphics backend, having it work everywhere, and as a bonus not having to deal with terrible API that is OpenGL.

terrible API that is OpenGL.

Eh, Direct3D9 was awful and not at all rooted in mathematical convention. I think (0,0) was the upper left of a texture instead of the center of the upper-left texel, too.

Granted, it's been awhile. Maybe the situation has improved.

OpenGL is pretty bad, but it's not clear to me that Vulkan is really any better. Importantly, though, it gives more control and so makes it possible to build a good API on top.

More importantly, being lower-level reduces opportunities for driver bugs and inconsistencies — aren't they the main reason GL(&ES) and D3D(<12) are bad?

Note that while in principle a compiler for the lower-level APIs/languages should be simpler, these are still pretty complex compilers (and given the underlying architecture changes quite often they don't necessarily end up eventually stable, given the architecture-specific code frequently becomes unmaintained).

The lower level = bad drivers argument doesn't really apply to D3D. Microsoft is in control of the high level pieces of that, and the ISVs target a low level API underneath all of that. It's been that way for decades at this point.

Vulkan is way better. It's not lower level per se, just a way better abstraction for how modern GPU hardware works as opposed to the mid/late 90s hardware that OpenGL still targets at it's core.

The biggest win is how explicit it is so you won't stutter for things like shader recompiles like you do in OpenGL (I'll give you a hint, most of the time the shader isn't fully compiled by the time glLink returns). Also, Vulkan's emphasis on immutable objects really tickles my fancy in terms of programming hygiene.

While Vulkan is a better abstraction for modern GPU hardware, I’ve always thought OpenGL better mapped to how humans think of 3D scenes, and imposes relatively little* tedious boilerplate on the developer. If I wanted to get a quick experiment up and running that just shows a model and maybe using a few shaders, I know which API I’d rather use. If I wanted to make a simple, non-AAA budget game without using Unity or Unreal, I know which API I’d rather use.

Vulkan, to me, is the assembly language of graphics APIs. Few should need to drop down that far, but those who do really need to.

*The exception being platform-specific window management which has always been terrible, but mostly solved by compatibility libraries.

Honestly, OpenGL isn't that great for how people think. IMO a scene graph API is much better in that situation.

The boilerplate in Vulkan is a lot of work to get to a triangle on the screen, but once you're there it really isn't much more work to do whatever. The boilerplate isn't linear with lines of code, and honestly anything nontrivial with modern OpenGL is probably going to have more boilerplate.

It's sort of an unfortunate consequence of how code architecturally should change with log10(cloc). Examples in Vulkan look verbose, but as soon as you get out of examples, it's a lot nicer. So, with a simple game, I'd probably end up using something like Vulkan too.

The world of 3D APIs would have been much different if OpenInventor was released on the same terms as OpenGL, but it wasn't.

OpenGL is so raw than everyone ends up creating their own scene graph API from scratch.

It seems like a cleaner design to me—emphasis on a well-defined pipeline and immutable objects.

Does it? It seems very experimental now. They even had to do work _just_ to get DOTA2 running

> The initial results were… slightly discouraging. For a while we weren’t able to get the game to start, due to our Metal backend was missing some required features, like compressed texture support

Right, at the moment there is still missing functionality on each of the backends, but Dota2 was a great test application for the gfx-rs team to prioritize implementing some of that missing functionality.

As mentioned in the blog post, the team is also actively working on improving Vulkan conformance test suite coverage, so the goal is to continue maturing these backends relatively quickly.

Maybe it's me not knowing any better, but for visualization stuff I've never had much problems at all with modern OpenGL.

I think the issues start when you try and build high performance abstractions over opengl.

Does this abstraction target WebGL as well? I could imagine it being a nice portability layer for web-aware apps since rust can easily target wasm with a few compiler flags.

They currently have support through the emscripten target, and (as far as I know) are working on support for the unknown target.

Ideally this should be straightforward by adapting the OpenGL ES backend to perform the equivalent WebGL calls. There have been some initial investigations into this already, and the Emscripten target worked well with an earlier version of gfx.

In the future there could be a backend to target WebGPU (https://www.w3.org/community/gpu/) as well.

Great work on the gfx portability layer! I hope to be able to use it in the future, but for the time being I've abandoned gfx in favor of raw OpenGL calls in order to avoid the type complexity in gfx (I spent multiple hours trying to cram all of the gfx state into a struct, but could not figure out what to put as some of the type signatures... even with the compiler trying to help me). Hopefully the the low-level API, once stable, will give me the type simplicity I prefer.

You can also try one of the Vulkan Rust libraries (ash, Vulkano). Later you'd have easier time migrating to gfx-hal, or alternatively can just run over gfx-portability.

I'm currently using my MacBook pro for development, so vulkan isn't an option right now. I'll definitely keep that in mind, though.

Sure it is, use MoltenVK or `portability` from this article :)

I've been doing my Vulkano learning on a mac about half of the time. MoltenVK makes it good enough to get things going.

Well, at least now your know that there is an alternative. For a Rust ecosystem project, really, there shouldn't be a need to use MoltenVK.

The thing that drives me insane in Dota2 on MacOS is that Quickcast doesn't seem to work with the built-in keyboard on my mid 2015 Macbook Pro 15" :(

I spent about a week trying to play Dota2 on my macbook pro a couple years ago (I've played on Windows desktop for years), and I was very put-off by the mouse acceleration profile with my Magic Mouse. I tried tweaking it, but couldn't get it to feel like it did with my Logitech mouse on Windows.

It wasn't about dpi or speed. I would constantly find myself trying to rapidly aim-click on something and have my cursor stop just short of the target. The cursor felt _heavy_ and stuck like it didn't move as easily.

MacOS mouse acceleration takes some getting used to, and there was OS-level mouse input latency (since fixed) to contend with for a while also.

The SmoothMouse utility fixed the latency issues and made the mouse cursor move like it did on Windows. I was very disappointed when Apple deprecated the APIs that made it work.

Reply on news.ycombinator.com