5 ms·

Correct me if I'm wrong: 1) this is an effort to provide an abstract graphics API for any OS/CPU instruction set 2) it is rust and therefore usable from rust an

Correct me if I'm wrong: 1) this is an effort to provide an abstract graphics API for any OS/CPU instruction set 2) it is rust and therefore usable from rust and C(++). If so, great news! Maybe we'll one day be free from tyranny of Windows when it comes to gaming. In my ideal world, operating systems should be interchangeable like web browsers and competing to provide the best implementation of an open standard rather than trying to trap developers and users by providing the most enticing proprietary API. Have there been any previous attempts to do this? Any success?

megaman22 8y ago
> Have there been any previous attempts to do this? Any success? Many over the years, and largely not. Unreal and Unity are probably the closest to successful to date, but they are full-blown game engines, at a higher level of abstraction, rather than just graphics APIs. OpenGl mostly failed as a multi-platform solution, because vendors provide varying levels of compatibility in their drivers, not to mention unholy extension soup, and you still have to deal with all the platform nastiness of everything else besides sending triangles to the GPU.
- pjmlp 8y ago
  Vulkan is not any better on this regard. Get ready to play extension and version golf. http://www.vulkan.gpuinfo.org/listextensions.php http://www.vulkan.gpuinfo.org/listextensions.php http://www.vulkan.gpuinfo.org/vulkansupport.php http://www.vulkan.gpuinfo.org/vulkansupport.php
  - oliwarner 8y ago
    The extensions are just that. They are essentially proposals or hardware specific items not meant for broad adoption. Those that are get drafted into the proper specs. And variable driver support is common across all big graphics APIs. If anything, the feature per driver coverage here is better than DX12.
    - snaky 8y ago
      And hardware vendors are and will be very eager to add hardware specific quirks, tons of it. So there is no point to "abstract graphics API for any OS/CPU instruction set" then, when most of the work - and we are talking about graphics acceleration, where performance is everything - is and increasingly will be handling all of that quirks.
      - pcwalton 8y ago
        That's not how it works. Most games and apps are just fine with leaving some amount of graphics performance on the table. That's why engines like Unity are so popular: sure, you could always go a bit faster writing your own engine, but in most cases it isn't worth the trouble. Likewise, with graphics APIs, you have to weigh the significant benefits of greater compatibility against the benefits of using vendor-specific extensions. For most apps, the benefits of going wild with extensions are marginal, while the obvious drawbacks are significant. I think a lot of people have mistaken ideas about how performance sensitive games are. They care about performance, but not so much that it trumps all other considerations. Games really aren't that different from other apps.
        microcolonel 8y ago
        > I think a lot of people have mistaken ideas about how performance sensitive games are. They care about performance, but not so much that it trumps all other considerations. Games really aren't that different from other apps. Beyond that, even where performance is the priority, a generic performance win is usually more interesting unless the IHV is buying the developer time.
        pjmlp 8y ago
        It is not going wild with extensions, rather having to deal with extensions for feature X, because everyone does it differently, and when X becomes part of the core, it is just another additional path, as naturally not all GPU drivers do update to the version that has X in the core. And even then, there are the workarounds to deal with hardware or driver specific bugs.
shmerl 8y ago
> it is rust and therefore usable from rust and C(++). They want to provide C bindings (vulkan.h). > Have there been any previous attempts to do this? Any success? MoltenVK translates Vulkan into Metal. Looks like gfx-rs has a potential to break these lock-ins one step further with translating Vulkan into DirectX 12. They should also consider making GNM backend for completeness.
- zanny 8y ago
  Is there any hardware that supports only DX12 and not Vulkan? My understanding is the only extant device is the Xbox One, which doesn't support Vulkan not because the hardware lacks the ability or drivers (since its an AMD SoC shared with the PS4 and using GCN 3 tech) but because of politics trying to lock developers into their API over the industry standard. Trying to fight politics with software rarely ends well, especially with hobbyist software. Microsoft has complete control over their console and are probably willing to take moves to prevent the use of transpilers on their platform in the same vein Apple has.
  - shmerl 8y ago
    Both recent Xbox and PlayStation hardware should support Vulkan just fine, so it is dirty political and anti-competitive tactic not to support it there. But if MS will try banning things like translation layers, they already can get some anti-trust pushback. Apple while being complete lock-in jerks, so far didn't prevent usage of MoltenVK on their systems. Recent incident with using private APIs was resolved, and Apple allowed applications that use MoltenVK back on iOS.
  - muizelaar 8y ago
    5th generation Intel chips support Direct3D12 and not Vulkan. https://www.intel.com/content/www/us/en/support/articles/000005524/graphics-drivers.html https://www.intel.com/content/www/us/en/support/articles/000...
    - microcolonel 8y ago
      If I'm not mistaken, Mesa/ANV supports Vulkan back to Haswell (with some limitations until Broadwell).

megaman22 8y ago

> Have there been any previous attempts to do this? Any success? Many over the years, and largely not. Unreal and Unity are probably the closest to successful to date, but they are full-blown game engines, at a higher level of abstraction, rather than just graphics APIs. OpenGl mostly failed as a multi-platform solution, because vendors provide varying levels of compatibility in their drivers, not to mention unholy extension soup, and you still have to deal with all the platform nastiness of everything else besides sending triangles to the GPU.

pjmlp 8y ago
Vulkan is not any better on this regard. Get ready to play extension and version golf. http://www.vulkan.gpuinfo.org/listextensions.php http://www.vulkan.gpuinfo.org/listextensions.php http://www.vulkan.gpuinfo.org/vulkansupport.php http://www.vulkan.gpuinfo.org/vulkansupport.php
- oliwarner 8y ago
  The extensions are just that. They are essentially proposals or hardware specific items not meant for broad adoption. Those that are get drafted into the proper specs. And variable driver support is common across all big graphics APIs. If anything, the feature per driver coverage here is better than DX12.
  - snaky 8y ago
    And hardware vendors are and will be very eager to add hardware specific quirks, tons of it. So there is no point to "abstract graphics API for any OS/CPU instruction set" then, when most of the work - and we are talking about graphics acceleration, where performance is everything - is and increasingly will be handling all of that quirks.
    - pcwalton 8y ago
      That's not how it works. Most games and apps are just fine with leaving some amount of graphics performance on the table. That's why engines like Unity are so popular: sure, you could always go a bit faster writing your own engine, but in most cases it isn't worth the trouble. Likewise, with graphics APIs, you have to weigh the significant benefits of greater compatibility against the benefits of using vendor-specific extensions. For most apps, the benefits of going wild with extensions are marginal, while the obvious drawbacks are significant. I think a lot of people have mistaken ideas about how performance sensitive games are. They care about performance, but not so much that it trumps all other considerations. Games really aren't that different from other apps.
      - microcolonel 8y ago
        > I think a lot of people have mistaken ideas about how performance sensitive games are. They care about performance, but not so much that it trumps all other considerations. Games really aren't that different from other apps. Beyond that, even where performance is the priority, a generic performance win is usually more interesting unless the IHV is buying the developer time.
      - pjmlp 8y ago
        It is not going wild with extensions, rather having to deal with extensions for feature X, because everyone does it differently, and when X becomes part of the core, it is just another additional path, as naturally not all GPU drivers do update to the version that has X in the core. And even then, there are the workarounds to deal with hardware or driver specific bugs.

shmerl 8y ago

> it is rust and therefore usable from rust and C(++). They want to provide C bindings (vulkan.h). > Have there been any previous attempts to do this? Any success? MoltenVK translates Vulkan into Metal. Looks like gfx-rs has a potential to break these lock-ins one step further with translating Vulkan into DirectX 12. They should also consider making GNM backend for completeness.

zanny 8y ago
Is there any hardware that supports only DX12 and not Vulkan? My understanding is the only extant device is the Xbox One, which doesn't support Vulkan not because the hardware lacks the ability or drivers (since its an AMD SoC shared with the PS4 and using GCN 3 tech) but because of politics trying to lock developers into their API over the industry standard. Trying to fight politics with software rarely ends well, especially with hobbyist software. Microsoft has complete control over their console and are probably willing to take moves to prevent the use of transpilers on their platform in the same vein Apple has.
- shmerl 8y ago
  Both recent Xbox and PlayStation hardware should support Vulkan just fine, so it is dirty political and anti-competitive tactic not to support it there. But if MS will try banning things like translation layers, they already can get some anti-trust pushback. Apple while being complete lock-in jerks, so far didn't prevent usage of MoltenVK on their systems. Recent incident with using private APIs was resolved, and Apple allowed applications that use MoltenVK back on iOS.
- muizelaar 8y ago
  5th generation Intel chips support Direct3D12 and not Vulkan. https://www.intel.com/content/www/us/en/support/articles/000005524/graphics-drivers.html https://www.intel.com/content/www/us/en/support/articles/000...
  - microcolonel 8y ago
    If I'm not mistaken, Mesa/ANV supports Vulkan back to Haswell (with some limitations until Broadwell).