Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vulkan Not Detected / Not an Option #370

Open
phr00t opened this issue Feb 7, 2019 · 27 comments
Open

Vulkan Not Detected / Not an Option #370

phr00t opened this issue Feb 7, 2019 · 27 comments

Comments

@phr00t
Copy link
Contributor

@phr00t phr00t commented Feb 7, 2019

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
xenko-no-vulkan

@phr00t phr00t added the bug label Feb 7, 2019
@tebjan

This comment has been minimized.

Copy link
Contributor

@tebjan tebjan commented Feb 7, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@phr00t phr00t commented Feb 7, 2019

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

@tebjan

This comment has been minimized.

Copy link
Contributor

@tebjan tebjan commented Feb 7, 2019

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

@dfkeenan

This comment has been minimized.

Copy link
Contributor

@dfkeenan dfkeenan commented Feb 7, 2019

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

@tebjan

This comment has been minimized.

Copy link
Contributor

@tebjan tebjan commented Feb 8, 2019

yup, exactly this dropdown is missing. @xen2
image

previous versions:
image

@xen2

This comment has been minimized.

Copy link
Member

@xen2 xen2 commented Feb 8, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@phr00t phr00t commented Feb 9, 2019

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

This comment has been minimized.

Copy link
Member

@xen2 xen2 commented Feb 9, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@phr00t phr00t commented Feb 9, 2019

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?

@xen2 xen2 added this to the 3.1 milestone Feb 9, 2019
@xen2 xen2 added the area-Graphics label Feb 9, 2019
@phr00t

This comment has been minimized.

Copy link
Contributor Author

@phr00t phr00t commented Feb 10, 2019

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

This comment has been minimized.

Copy link
Member

@xen2 xen2 commented Feb 10, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@phr00t phr00t commented Feb 10, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@phr00t phr00t commented Feb 11, 2019

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

This comment has been minimized.

Copy link
Member

@xen2 xen2 commented Feb 11, 2019

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

@phr00t

This comment has been minimized.

Copy link
Contributor Author

@phr00t phr00t commented Feb 11, 2019

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

This comment has been minimized.

Copy link
Member

@xen2 xen2 commented Feb 11, 2019

@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

This comment has been minimized.

Copy link
Contributor Author

@phr00t phr00t commented Feb 11, 2019

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

This comment has been minimized.

Copy link
Member

@xen2 xen2 commented Feb 11, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@phr00t phr00t commented Feb 11, 2019

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

This comment has been minimized.

Copy link
Member

@xen2 xen2 commented Feb 12, 2019

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

@xen2

This comment has been minimized.

Copy link
Member

@xen2 xen2 commented Feb 12, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@phr00t phr00t commented Feb 12, 2019

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

This comment has been minimized.

Copy link
Member

@xen2 xen2 commented Feb 12, 2019

@phr00t yes: GraphicsDevice.Platform (static member)

@phr00t

This comment has been minimized.

Copy link
Contributor Author

@phr00t phr00t commented Feb 14, 2019

Got a problem with d52b6ac @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

This comment has been minimized.

Copy link
Member

@xen2 xen2 commented Feb 15, 2019

@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.

@xen2 xen2 removed this from the 3.1 milestone Feb 15, 2019
@phr00t

This comment has been minimized.

Copy link
Contributor Author

@phr00t phr00t commented Feb 15, 2019

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

This comment has been minimized.

Copy link
Contributor

@profan profan commented Sep 15, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.