Quoting: ShabbyXI wonder why they wouldn't make it the default on windows either. That will make not only their vulkan renderer more stable (more people get to test it), but also damage directx considerably, which is nice.

There are 3 reasons I can think of why developers will continue with D3D in the short term.

1. Vulkan ( and D3D12 actually ) are properly supported only on Windows 10, but not other Windows versions. Eventually Vulkan will have broad WIndows support, so it will be interesting to see if D3D12 then gets a magic backport to older Windows versions.

2. To support Microsoft consoles, developers need to use Microsoft technology, so they will need to understand the Microsoft ecosystem. I can see no real likelihood for Microsoft to support Vulkan on the XBox.

3. Vulkan is not as fast as D3D12. This should change as Vulkan drivers mature, and Vulkan/SPIR-V receive a similar degree of optimisation to D3D, but it's not there yet.

Although Vulkan adoption is not as extensive as some would like, I am encouraged by what I hear from game and engine developers. For example, Egosoft have just put a VR version of their most recent Space sandbox game [External Link] into early access on Steam. Although this is only for Windows at present, they stated that the engine is a new build that uses Vulkan, not D3D, and that they intend to use this Vulkan engine for their next game. Egosoft is not a large company, so it suggests that moving to Vulkan as the primary ( or only ) render API is already perfectly practical if the benefits are there.

View this comment - View article - View full comments

Quoting: silmethEDIT: and following a link from the comments of the glslang issue – it seems Microsoft also works on their own open-source HLSL → SPIR-V compiler [External Link]. Interesting times we live in.

As I understand it Microsoft and Google are collaborating using LLVM to get HLSL -> SPIR-V. Microsoft work on the front-end compiler and Google the back-end. There is certainly a lot of maneuvering going on in the graphics world, so I'm sure they each have their own self-interest reasons to collaborate, but I am encouraged that Vulkan does not seem to be receiving outright hostility.

View this comment - View article - View full comments

Quoting: Guest

Quoting: Pecisk

Quoting: GuestHLSL support means less work for porting games from DirectX?
https://youtu.be/bjE-sCkgC7o?t=8m1s [External Link]

They would generate Vulkan shader language using HLSL thus decreasing time required for porting. Or I got it wrong :)

I think it's not quite that easy. There are API differences in using HLSL for DirectX vs Vulkan, but work is ongoing to help with that. So "it depends on the code" is probably the best thing to say, but I think it would at least help. I don't really work with it that much; these are just areas I would expect to need special consideration.

Wouldn't expect to see anything from this being done by porters for at least 6 months, if not longer. Just in case anyone was wondering.

According to a guy from Oxide ( at GDC ) that contrasted D3D12 and Vulkan engines for Ashes of the Singularity, the only significant HLSL source difference to compile to SPIR-V is for binding resources. They just use a preprocessor to insert "register(foo)" for D3D12 or "layout(foo)" for Vulkan.

At the moment though, SPIR-V generated code lacks a lot of the optimisation it should have ( i.e. there is a lot more SPIR-V bytecode than D3D12 bytecode to implement the same feature ). This, along with lack of experience with Vulkan threading, probably contribute to lower than expected performance gains we have seen to date ( 10-15% better than D3D11 seems a common claim ). Elsewhere in the video linked in Liam's post, LunarG mention their work to perform SPIR-V to SPIR-V optimisation, which should benefit all shaders that target SPIR-V.

View this comment - View article - View full comments

Quoting: Shmerl

Quoting: etonbearsGood question! That's why I say it is unclear.

See update above. Looks like X.org foundation is working as a representative for Mesa in Khronos, so that should probably cover it.

OK, yes, assuming X.org sign ( or have already signed ) an adopter agreement, then it looks like they do have the protections of the IP framework.

View this comment - View article - View full comments

Quoting: Shmerl

Quoting: etonbearsNo. Khronos operate an IP framework, the essence of which is that Khronos members agree not to assert any patents they hold against other members implementing a Khronos specification.

So, Mesa project is not protected by that agreement? or X.org/Mesa are now a member?

Good question! That's why I say it is unclear.

I am not aware that X.org or Mesa have membership of Khronos, but individual open-source contributors may have day jobs in companies or universities that are Khronos members. I don't know if this gives any protection or not.

My feeling is that there is no intent to prevent open-source implementations; but that is not the same as giving legal permission.

View this comment - View article - View full comments

Quoting: ShmerlIf I understand correctly, Khronos only includes patent-free extensions in the versioned OpenGL specification.

No. Khronos operate an IP framework, the essence of which is that Khronos members agree not to assert any patents they hold against other members implementing a Khronos specification. I'm not sure how legally strong that provision is.

No mention is made concerning implementation of Khronos specifications by non-members, or what happens if non-members hold patents that might interfere with specifications - although one would assume Khronos then use alternatives where possible.

So the situation still seems a little unclear, although there is evident goodwill towards open implementations.

View this comment - View article - View full comments

This is quite nice, but possibly more important is the Vulkan Portability Initiative [External Link]

The aim here is to identify the subset of Vulkan that can map directly to D3D12 and Metal, provide open-source libraries to effect the mapping and cross-compilers for spir-v to the D3D12/Metal intermediate shader languages.

That would possibly offer developers a single API ( Vulkan ) to target almost every platform at minimal performance cost.

The question would then be whether that is good enough for the main AAA developers ( it certainly would be for smaller teams ), and whether the parties that control D3D12 and Metal attempt to sabotage the initiative...

View this comment - View article - View full comments

Quoting: Purple Library Guy

Quoting: Shmerl

Quoting: Metallinatus

Quoting: ShmerlWhat stops anyone from partnering with Dell, and making them provide Linux options on all their models, and not just on a couple of laptops? I agree though it requires money. I'd also like to see KDE used for such purpose.

Honestly, if someone tried that, Microsoft would strike back their own deal with Dell to keep it from happening....

They can be hit with anti-trust pretty hard if they'd do that.

Maybe in the EU. Antitrust in the United States is effectively a dead letter at the moment. The monopolists have the richest lobbyists, and the richest lobbyists rule the US, ergo no antitrust enforcement.

Not entirely sure the EU is any more effective. They do give some anti-competitive companies a good kicking in the balance sheet, but not always for the right reasons, and almost always way too late to prevent damage to competition...

View this comment - View article - View full comments

Quoting: GuestWhile performance could have been better at release, to the best of my knowledge the game actually did work ok on supported systems when it was released, and I don't think there were that many issues (if you could run the game). Only nvidia blob drivers were supported of course, and it was tested in house quite a bit as far as I know - but of course, releasing into the wild showed a lot more problems that they simply hadn't encountered during testing.
I do think they should have released it with a beta tag first, but hindsight is wonderful like that, and quite frankly I've seen a lot of games with a lot more problems that have had a more favourable reception at full launch.
And while I did buy the game, I did not have a supported platform (fglrx drivers at the time, on an underpowered system). The game ran. Not fast (unplayable to be honest), but it ran without any graphical glitches, crashes, or anything like that. Couldn't even start the game via wine. So from that perspective, the port was, for me, a lot better than many others.

Similarly, I bought this ( and many other ) Linux games knowing that AMD might not be supported initially. I played it for 30 minutes trying to find a setting where it would not CTD, shrugged my shoulders and left it for a few weeks. When I went back to it, it had been updated and has worked fine ever since.

To be honest I was only faintly aware that there was a lot of anger at the time; most of it seemed to be clueless people talking about VP and how they hated them using a wrapper. I know VP have a wrapper tech if the source code for a game isn't available, but what I have on my disk now certainly looks like a native port.

View this comment - View article - View full comments

Quoting: Shmerl

Quoting: etonbearsEven Valve, a company that seems to have a good reason to promote Linux, has very deep pockets, and requires the consent of only one person ( Gabe Newell owns over 50% of voting stock ), has really not spent the money necessary to move the market; possibly out of concern that Valve would get into a pissing contest with Microsoft.

Valve's weak point is marketing. They utterly failed to push their Steam Machines. I really don't get why they treated their hardware partners that way. They don't have anything to fear from MS. If MS let's say goes, and bans Steam from Windows, so many people will be outraged, that MS will quickly back from that decision, otherwise risking a lot of people switching to Linux.

May be it was always just a leverage tool, and not a serious project? Though that would be pretty weird, and again very bad towards their hardware partners.

It is hard to say. Gabe Newell was very clear that he saw Windows Store as an existential threat to Valve's business, particularly with the implied threat of "Universal Windows Platform" applications being the only ones allowed on Windows. So diversifying their business to other platforms is obviously a good idea. At the same time, Windows is 93% or more of Valve's revenue, so they need to avoid pushing so hard that Microsoft react in a way that causes immediate damage to their business.

Valve wanted to get as many other companies to support them as possible and build a viable gaming ecosystem not controlled by a single entity like Microsoft, but seem to have been keen to avoid looking like it was all about Valve. Valve have obviously spent ( and continue to spend ) money to make a fixed Linux target ( set of libraries ) for games developers to aim at, and this is probably the single most important enabler allowing many developers to produce Linux ports. They also continue to produce and enhance tools useful for Linux game developers, and fund other aspects of Linux development that they think are useful, which seems like continued committment.

It is unclear whether Valve have directly funded companies porting games to Linux; it is possible they have, but no-one has confirmed it. Valve have a reputation for making good decisions, so they may have simply been good at persuading developers that supporting Linux is in their own interest. I really don't think that this is just about leverage ( I certainly hope not ), since an open market has to remain a credible threat to Microsoft in the long term. If developers don't make money from Linux ports they will not continue to produce them, and the threat/leverage will disappear.

I see Steam Machines as a different case. They were part of the Steam Hardware push, aimed at providing a console experience on a PC platform. There is actually no requirement for a Steam Machine to run SteamOS; most do, although the more expensive designs dual boot Windows as well. Valve invested heavily to produce their controller and streaming link, but for the machines themselves they wanted, as with software, to encourage 3rd parties to enrich the ecosystem.

The trouble is, 3rd parties have not been able to match the price/performance you can get from a console, because Steam Machines do not contain fixed components to optimize games against. Obviously you can get a very expensive Steam Machine, in a console format, that is much better than XBox/PS4; but who would buy that? As you say, Valve are not good at traditional marketing, and I think the notion of an upgradeable Steam Machine console will only make sense if MS/Sony are forced by the pace of hardware improvement to obsolete their consoles every couple of years.

To me, the whole games industry, and the decisions they take, seem like a complex mix of financial and power politics between participating companies. Personally, I never expect promises to be honored, dates to be kept, or high quality at initial delivery. I am patient enough to not buy pre-release, or even at release until a game is shown to actually work on my platform. It is still hard being a Linux gamer, but it is a lot more fun than it used to be.

View this comment - View article - View full comments