Support OpenGL for package validation.

[denelon]

Description of the new feature/enhancement

Add support for packages with a dependency on OpenGL.
Some packages require OpenGL. The validation environment does not currently support this as a dependency.

Proposed technical implementation details (optional)

Once support for package dependencies is enabled, the validation environment should be able to test packages with the OpenGL dependencies.

Examples:
#705
#1067

[latere-a-latere]

Thanks for the effort of making this issue, @denelon, but I just went to check out RemoteFX and apparently when I used it a year ago for #1067 it was already unsupported and being deprecated - And it has been fully removed in the April security update of this year.

Because of security concerns, RemoteFX vGPU is disabled by default on all versions of Windows starting with the July 14, 2020 Security Update and removed starting with the April 13, 2021 Security Update.

I'm gonna look into getting the alternative, Discrete Device Assignment (DDA) working under Windows 10, though I'm not quite sure if it's possible at all sinds the docs only talk about Windows Server 2016 and up.

If that's not going to work, well, then I don't know how we can possibly validate manifests for programs that require OpenGL inside the validation environment - the standard display driver simply doesn't cut it.

[denelon]

I guess I need to update the Issue. Thank you so much for digging into this!

[denelon]

We also have an interesting challenge with some device drivers requiring specific hardware to be present.

[latere-a-latere]

@denelon I've done a bunch of digging and from what I understand DDA is not available on desktop versions of Windows 10 - You can only use it on server 2016 and up.

The only solutions currently available to consumers are qemu and VirtualBox, as far as I am aware. Naturally this is far from ideal: it's hard if not impossible to migrate the win10 dev environment to these platforms (and probably against the license agreement) and I doubt you guys would want to built this into the pipeline.

Do you think you could ask the Hyper-V team if there is currently any way of getting opengl in Hyper-v to work on consumer editions of Windows?

[denelon]

I'll see if the team knows anyone who works on Hyper-v.

[jedieaston]

It's worth noting that Windows Sandbox supports graphics acceleration (see here for more info), so if you need a local environment to test packages that need OpenGL, that would work. There's a lot of limitations (one of these days I'm going to buy a ticket to Build so I can go ask the engineers responsible why I can't have more than one Sandbox open at a time, or even better, just create Hyper-V containers myself that have graphics), but it works. Tools\SandboxTest.ps1 is a good way to validate a package.

[latere-a-latere]

@jedieaston Unfortunately, even using a configuration file that has vGPU set to Enable I'm not getting any usable OpenGL:

The minimum version required is 2.0, anything lower than that doesn't really work for the majority of applications.

[denelon]

@jenatali and I just had a talk, this might be one option for getting openGL support in a VM:
https://devblogs.microsoft.com/directx/announcing-the-opencl-and-opengl-compatibility-pack-for-windows-10-on-arm/

[jenatali]

Yeah, right now you'd need the insider version of that package installed, but then it will enable OpenGL support on top of WARP (Windows Advanced Rasterization Platform), which is our D3D software renderer used in VMs with no hardware acceleration.

[jedieaston]

I did some more digging into this, turns out apparently vGPU support is just broken in Windows 10 20H2/21H1. This probably isn't a option, but OpenGL (and DirectX too, as I tried a game with DirectX on 21H1 and it didn't work) is available and works fine in Sandboxes created on build 21382.1000 of Windows 10 (possibly older versions, I enrolled my system into Insider Fast and was given that build):

Does anyone know if this is intended behavior? I think vGPU not working in Sandbox on 21H1 is a bug (as it has been documented since 1909 or so as being an available feature), but I don't know what to do other then send it into the Feedback Hub black hole.

[denelon]

If you don't mind, send a report to Feedback Hub and share the link here. I'll see if I can route it to the right team.

[jedieaston]

Whoop, there it is.

[pbozzay]

Hey @jedieaston - I work on Sandbox. Thanks for investigating; this does seem like a regression. Did you submit a repro trace by chance? I don't see traces attached to that FBH report, but if we were able to gather them it would help corroborate my current theory.

[jedieaston]

I did two recordings, although I don't know if they went through -- let me try again.

[jedieaston]

@pbozzay I just tried it from another system and it looks like Feedback Hub sent the data, let me know if you can't see it and I can try something else.

[pbozzay]

Thanks, I see more data now. Can you tell me what you get when you go here, on both devices (working/broken)?
http://aka.ms/gpucheck

[jedieaston]

Stable (21H1):

Insider Fast (21382):

[pbozzay]

Hi @jedieaston - I think I see the issue. I believe you may have accidentally put the tag inside of the LogonCommand node; the XML parser simply ignores this setting in this case. On current builds we enable vGPU by default, which is why it's still working for you there.

This is what I see from your feedback:

Valid config will use vGPU in its own node:

<!-- 21H1 -->
<Configuration>
  <vGPU>Enable</vGPU>
  <LogonCommand> 
  ... 
  </LogonCommand>
</Configuration>

Now, one issue here is that we added functionality called VGPU "vendor extensions" after 21H1. OpenGL may rely on that functionality. Vendor extensions are enabled by default in newer builds (e.g. Insider Fast), or you can explicitly enable them like this:

<!-- Insider Fast build -->
<Configuration>
  <vGPU>EnableVendorExtensions</vGPU>
  <LogonCommand> 
  ... 
  </LogonCommand>
</Configuration>

Enabling vendor extensions may be the difference between OpenGL working or not, which may mean that on 21H1 Sandbox doesn't support OpenGL.

[latere-a-latere]

@pbozzay Having updated to 21H1 earlier last week, I just went to try sandbox with the vGPU setting and we're getting somewhere!

This is the basic config I used:

<Configuration>
  <vGPU>Enable</vGPU>
</Configuration>

dxdiag also shows Direct3D working. However, OpenGL still doesn't seem to work and crashes applications trying to use it. I've tried the following:

• Furmark, Super Tux, Osu!Lazer 2021.5240
  • Doesn't start, logs an error to eventlog
• OpenGL Extensions Viewer
  • Shows directx12 but crashes during opengl detection
• GfxBench
  • Silent crash during device detection
• OpenTTD 1.11.2 (OpenTTD switched to OpenGL in 1.11.0)
  • Fatal application failure on start but at least here I got a crash report clearly showing something going wrong when loadin the opengl driver: https://gist.github.com/MarNicGit/a17c3c5f453d6a7f6ce526071a53d2ff
• Unigine Heaven Benchmark 4.0 basic edition
  • Runs in DX11 and DX9 mode but silently crashes when trying to run in OpenGL mode
    • Interestingly, the benchmark claims to run at 60 to 70fps in dx11 while it is clearly stuttering all over the place. Probably unrelated though.
• 3DMark Basic Edition 5.38.896.0
  • Time Spy (DX12) and Night Raid (DX12) failed: Window/swapchain initialization failed: DXGI call IDXGIFactory2::CreateSwapChainForHwnd failed [0X887A0005]
  • Fire Strike (DX11) failed: Workload produced no results

Do you know if it is possible to install the insider build without switching my entire windows install to insider?

[denelon]

Do you know if it is possible to install the insider build without switching my entire windows install to insider?

I don't know, I'll see if I can find out.

[denelon]

Maybe you could create a VM with an insider build, but I don't know if the Sandbox works in that kind of scenario.

[jedieaston]

@pbozzay D'oh! Thanks for the help.

Maybe you could create a VM with an insider build, but I don't know if the Sandbox works in that kind of scenario.

This works but you need to enable nested virtualization in Hyper-V so Windows Sandbox can be enabled. And then since you can't pass through a GPU, I don't know if you'd get acceleration or not.

[pbozzay]

@marnicgit @jedieaston that's good progress. Unfortunately in this case I suspect this won't work without upgrading to a new insider build that has VendorExtensions. I believe if you join an insider preview build, you can then revert back to 21H1 and retain your personal files/programs (admittedly this isn't ideal).

[latere-a-latere]

@pbozzay Thanks for the heads up, I'll look into switching to insider later tomorrow after watching MS Build.

[latere-a-latere]

Now on Windows Insider, build 21390.01, with EnableVendorExtensions in the config for good measure:

Running the same programs as my earlier test, I quit after trying OpenGL Extensions Viewer, OpenTTD and Furmark and experiencing identical behavior compared to my first test. Doesn't look like the vendor extensions enabled OpenGL :(

However, one thing I did notice is that all crashes are BEX/BEX64 events; Buffer Overflow Exceptions. Maybe that's a lead to what is causing this issue?

[pbozzay]

My first guess is that enabling vendor extensions hasn't "changed" anything for some reason. I've reached out to the vGPU owners inside of Microsoft and will let you know what they think.

[latere-a-latere]

@jedieaston I just noticed you had working OpenGL on build 21382, could you check if this is still the case when using the following config?

<Configuration>
    <vGPU>EnableVendorExtensions</vGPU>
</Configuration>

I'm curious if this might be related to you using an Nvidia GTX960 and me using an AMD 5700XT.

[jedieaston]

OpenGL confirmed when using that exact configuration on 21382.

Maybe AMD doesn't have a vendor extension.

[latere-a-latere]

@jedieaston Thanks! That should help narrow things down a lot.

[RoadToDream]

This has to be included in the Sandbox documents.... Even explicitly enable vGPU in the configuration, OpenGL will not work properly.