[Settings] Restore Target Graphics Platform dropdown

[phr00t]

Release Type: Github

Version: Latest (as of Feb 7th 2019, master branch)

Platform(s): Windows 10 x64

Describe the bug Rendering options on a new project only list OpenGL & DirectX options. No Vulkan.

To Reproduce Steps to reproduce the behavior:

1. Start a new project in GameStudio
2. Pull down the Rendering options & see Vulkan is missing.

Expected behavior Xenko is advertised as a Vulkan 3D engine, but it doesn't detect Vulkan on my fairly typical gaming setup (GTX 1070, Windows x64, NVIDIA 417.71 drivers).

Screenshots

[tebjan]

hi @phr00t, i think this is only the feature level of the graphics API. you select the actual API in the game setting, if i am not mistaken.

[phr00t]

Thank you for the response, @tebjan -- although opening the pulldown menu in GameSettings -> Rendering gives me the same options, without Vulkan.

[tebjan]

you are right, i don't see it either in latest beta.

[dfkeenan]

Are you looking in the "Target graphics platform" dropdown in Game Settings? That's where the documentation says it is.

[tebjan]

yup, exactly this dropdown is missing. @xen2

previous versions:

[xen2]

Yes sorry about that. Graphics platform is now selected using the runtime identifier. I think on Windows it might be enough to use <RuntimeIdentifier>win-vulkan</RuntimeIdentifier>.

Note that this won't work well on .NET Core (it would need win-vulkan-x86, which doesn't exist yet).

However the idea was more to create package with runtime.json, i.e. Xenko.ForceGraphicsApi.OpenGL. BTW, if you have any proposition for names... (note that this package wouldn;t contain any API specific code, only update the runtime identifier).

[phr00t]

Not sure I fully understand... Xenko is using .NET core on Windows (and all platforms), so win-vulkan won't work well anywhere, correct?

What names are we suppose to be propositioning? Does it really matter what the name is?

Why should "Vulkan" ever not be listed? Even if the machine you are developing on, for some very odd reason, didn't support Vulkan -- you could still build for other machines that likely would, correct? If Vulkan didn't work on a target machine, DirectX or Open GL should automatically be used as a fallback, like Unity provides.

[xen2]

Default Windows project is net461, so just adding RuntimeIdentifier should work.

I was asking for proposition of a good nuget package name that would force graphics API selection. Basically you add this nuget package in your executable project, and Xenko runtime will be forced to use this graphics API.

[phr00t]

Is this where adding RuntimeIdentifier should work, somewhere in here?

https://github.com/phr00t/xenko/blob/master/sources/core/Xenko.Core/build/Xenko.Core.targets

... where should it be best added?

It sounds like that would only work for Windows, though? Would that let me pick Vulkan as a graphics API? When I build for MacOS & Linux with Vulkan selected, would that use Vulkan on those platforms (MoltenVK on MacOS)?

What about this changes here?

https://github.com/phr00t/xenko/blob/master/sources/targets/Xenko.GlobalSettings.targets

Do changes need to be made to this file? If so, what kind?

https://github.com/phr00t/xenko/blob/master/sources/engine/Xenko/runtime.json

Are you trying to force Vulkan, or just make it selectable with these changes?

[phr00t]

After setting "Vulkan" as the default graphics API at the top of the following file, rearranging the following line to put win-vulkan at the start causes Xenko to not build properly:

https://github.com/phr00t/xenko/blob/master/sources/targets/Xenko.GlobalSettings.targets#L41

In the Discord chat, someone mentioned adding win-vulkan to the .csproj RuntimeIdentifier, but I'm not sure that is the right place... take for example the default RuntimeIdentifier for Linux is linux-x64 in the .csproj file, where no graphics API is specified (like linux-vulkan or linux-opengl).

Anyway, at a loss at trying to fix this myself... :/

[xen2]

The idea is to add the <RuntimeIdentifier>win-vulkan</RuntimeIdentifier> to your MyGame.Windows.csproj file (in a PropertyGroup).

Anyway, if you don't need it right away, please just wait that we add an easier way to set it (using a NuGet package).

[phr00t]

If I want Linux to use Vulkan, do I change the linux-x64 identifier in the csproj to linux-vulkan? Or is it not possible to use Vulkan on other platforms until this is fixed?

[phr00t]

It appears having win-vulkan as a RuntimeIdentifier builds, although I haven't verified Vulkan is actually being used yet.

linux-vulkan & osx-vulkan gives the following error when trying to build:

Error:NETSDK1056: Project is targeting runtime 'osx-vulkan' but did not resolve any runtime-specific packages. This runtime may not be supported by the target framework.

So, there is no workaround for Linux & MacOS Vulkan support until this issue is resolved with a NuGet package?

[xen2]

Yes, you will need to wait for a fix. Note that macOS is Vulkan-only, so that won't be an issue.

[phr00t]

Fair enough.

I'm curious: why go the NuGet package route to select a graphics API instead of adding "Vulkan" to the Rendering API pulldown list next to DirectX and OpenGL? It seems that pulldown is more integrated into the editor and where I'd expect developers to see it.

[xen2]

@phr00t Good question Ideally, it should be a pulldown to edit this RuntimeIdentifier. The only issue is that we have no UX workflow for .csproj PropertyGroup editing yet (it's not a package properties nor a GameSettings).

So the idea was to use nuget package in the meantime, to be later replaced with a proper UX (note: if proper UX is not that long to do, might go for that directly).

Anyway, I was thinking, to have workaround for the .NET Core use cases, an even simpler way would be to just add the linux-vulkan-x64, linux-vulkan-x86, etc. variants. I might do that right away so that people have a workaround and I don't need to do the NuGet packages or proper RuntimeIdentifier UX in a rush.

[phr00t]

Please add RuntimeIdentifier variants for Linux. This would implement a workaround for the last use case. You will need that variant for the UX to set, so it is progress towards the proper fix too. The NuGet package method seemed like a harder way to implement a bandaid fix, so I'd recommend skipping that.

[xen2]

Just now that I remember about it, one disadvantage of additional RuntimeIdentifier (with later some UX for it) is that I would define a few RuntimeIdentifier like linux-vulkan-x64 but if you want to use any more specific identifier (i.e. let's say fedora-vulkan-x64) or any custom identifier, I don't think I can replicate all of them and keep them up to date.

The NuGet approach wouldn't have this issue. It works by adding let's say linux-vulkan to linux if you reference Xenko.GraphicsPlatformApi.Vulkan so any RuntimeIdentifier that inherits from linux (including linux-x64 and fedora-x64 works out of the box). I am still not 100% sure about the NuGet approach either (esp. I already add win => win-d3d11 by default and not sure what are priority orders in case of conflicts).

Anyway, not sure what I will do longer term (if anybody has opinion, let me know).

For the short-term, I guess I will just add those additional RuntimeIdentifier (for win, linux, macos) as this is the simplest and more straightforward approach (let's keep it simple), and we can always revisit that later.

[phr00t]

Unity doesn't need as specific RuntimeIdentifiers as "fedora" -- "linux" is good enough. I wouldn't worry about solving that niche problem -- save that for someone who has a very specific need that would probably customize Xenko themselves to do. The overall majority, if not all indie developers (using Unity as an example) shows "Linux + vulkan" is enough.

Moving forward, adding the additional RuntimeIdentifier (we just need Linux for now, correct?) will do for a decent workaround. Getting the UX to set it will be good enough to close this issue.

[xen2]

I agree with your point. Will add RuntimeIdentifier right away then.

[xen2]

PS: the fedora example was far-fetched, but win vs win7 vs win10 might definitely happen (MS sometimes distribute different dll for those). However, I could define all of those quite common one so not a problem.

[phr00t]

Sounds good.

Is there a way to check the rendering API being used during runtime? I'd like to verify win-vulkan is working as a RuntimeIdentifier (no rush though).

[xen2]

@phr00t yes: GraphicsDevice.Platform (static member)

[phr00t]

Got a problem with https://github.com/xenko3d/xenko/commit/d52b6ac6a4e01968c211f5f95806b530f3b0aedb @xen2

linux-vulkan-x64 gives the following error:

"[C:\Program Files\dotnet\sdk\2.1.504\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(198,5)]: Error:Assets file 'D:\Phr00tsSoftware\XenkoProjects\SpaceEscape\MyGame21\MyGame21.Linux\obj\project.assets.json' doesn't have a target for '.NETCoreApp,Version=v2.1/linux-vulkan-x64'. Ensure that restore has run and that you have included 'netcoreapp2.1' in the TargetFrameworks for your project. You may also need to include 'linux-vulkan-x64' in your project's RuntimeIdentifiers."

linux-vulkan gives the following error:

"[D:\Phr00tsSoftware\XenkoProjects\SpaceEscape\MyGame21\MyGame21.Linux\MyGame21.Linux.csproj(0,0)]: Error:NETSDK1056: Project is targeting runtime 'linux-vulkan' but did not resolve any runtime-specific packages. This runtime may not be supported by the target framework."

Doesn't look like you can workaround Linux Vulkan support yet. :(

[xen2]

@phr00t Seems to work fine here. Sometimes VS takes a little bit of time before properly restoring.

BTW, I will schedule the UX part for post-3.1 so removing the milestone.

[phr00t]

I see what is happening: it builds fine in Visual Studio, but NOT from GameStudio (with the error above).

Post-3.1 UX solution is fine with me as long as this workaround is working.

[profan]

A nice thing for the runtime identifier stuff in the meanwhile would be to at least by default include a <RuntimeIdentifier>platform-whatever</RuntimeIdentifier> entry in the csproj for the given platform targets so it's clearer for people how it's actually happening and where to change it if necessary.

I just ran into this stuff by trying to figure out how to use opengl explicitly on windows as I was trying to test if my issue was specific to dx drivers or not.. not a great experience overall

[meriaizen86]

Any thoughs on reimplementing Vulkan runtime support in Game Studio?

Thanks in advance.

[Eideren]

Changed title to refocus the issue towards what it was initially, see https://github.com/stride3d/stride/issues/370#issuecomment-462304893 for more info about that.

[thargy]

Stride still doesn't have this drop-down, and the various runtime identifiers (other than win-x64) appear to have disappeared, so what is the recommended way of doing this (e.g. selecting DirectX 12)?

[tebjan]

This is now done via the API identifier: https://gamedev.stackexchange.com/questions/182684/how-to-use-the-vulkan-graphics-backend-in-the-stride-game-engine

[thargy]

Thanks @tebjan, I figured that out, sadly only Direct3D11 is included in the current 4.0 release, so to get any platform working on windows requires you to build the Stride engine yourself, which is an overly complex process. (See discord chat - never managed to get it working properly)

[thargy]

Also, note that the property was renamed from StrideGraphicsApi to StrideGraphicsApis.

• Ah that's for when building the runtimes, it only currently makes sense to use one API per project as you can't dynamically switch APIs at runtime, so you should use StrideGraphicsApi for your own project.