Curv running on Windows 10 under WSL

[Doug Moen]

After talking to @ComFreek on github, I got Curv running on Windows 10, using WSL, which is Microsoft's Linux emulator.

It works, but 3D rendering is kind of slow. WSL doesn't support GPU access, so OpenGL rendering is done in software.

See the updated BUILD.md file if you want to try this. If you want to dive into the arcana of how to run Linux GUI applications in WSL, look at https://github.com/curv3d/curv/issues/88

Doug Moen

[Andy Baker]

WSL2 which is currently available in preview does support  GPU access (I think... Hoping so anyway as I want to get CUDA stuff running on it)

> which is Microsoft's Linux emulator.

My understanding is that it's much more than an emulator. You're running a full Linux kernel close to the metal. Other than some hardware abstractions it should be faster than any VM based solution. Docker uses it on Windows.

[Doug Moen]

The WSL2 FAQ says no GPU access: https://docs.microsoft.com/en-us/windows/wsl/wsl2-faq#can-i-access-the-gpu-in-wsl-2-are-there-plans-to-increase-hardware-support

Fortunately, there is now a WIN32 port of Curv thanks to ComFreek.

--

You received this message because you are subscribed to the Google Groups "Curv" group.

To unsubscribe from this group and stop receiving emails from it, send an email to curv+uns...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/curv/593801dc-8e41-4a53-bc4b-86b2a6d87b20%40googlegroups.com.

[Andy Baker]

Oh well. My optimism might have got the better of me. It does say:

> In initial releases of WSL 2 hardware access support will be limited, e.g: you will be unable to access the GPU, serial or USB devices. 

> However, adding better device support is high on our backlog

So is there is some hope on the horizon. I'll check out the Win32 Curv however. That's great news.

On Saturday, 11 April 2020 13:46:08 UTC+1, Doug Moen wrote:

The WSL2 FAQ says no GPU access: https://docs.microsoft.com/en-us/windows/wsl/wsl2-faq#can-i-access-the-gpu-in-wsl-2-are-there-plans-to-increase-hardware-support

Fortunately, there is now a WIN32 port of Curv thanks to ComFreek.

On Sat, Apr 11, 2020, at 7:32 AM, Andy Baker wrote:

WSL2 which is currently available in preview does support  GPU access (I think... Hoping so anyway as I want to get CUDA stuff running on it)

> which is Microsoft's Linux emulator.

My understanding is that it's much more than an emulator. You're running a full Linux kernel close to the metal. Other than some hardware abstractions it should be faster than any VM based solution. Docker uses it on Windows.

On Monday, 2 March 2020 00:10:17 UTC, Doug Moen wrote:

After talking to @ComFreek on github, I got Curv running on Windows 10, using WSL, which is Microsoft's Linux emulator.

It works, but 3D rendering is kind of slow. WSL doesn't support GPU access, so OpenGL rendering is done in software.

See the updated BUILD.md file if you want to try this. If you want to dive into the arcana of how to run Linux GUI applications in WSL, look at https://github.com/curv3d/curv/issues/88

Doug Moen

--

You received this message because you are subscribed to the Google Groups "Curv" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cu...@googlegroups.com.

[Andy Baker]

Unless I'm overlooking it there doesn't seem to be a binary build available. I'm fairly technically literate but in my experience there's only a 50/50 chance that something that requires compiling from source is going to work so it serves as a rather massive barrier to entry. I know things are different on Linux but Mac and PC builds are usually a sign I'll end up wasting an afternoon and filling up my hard drive.

I'm sure I'm not the only person who feels this way. It would probably ease casual adoption by curious tinkerers if there was builds to download.

(again - apologies if I've just overlooked their existence)

[Doug Moen]

You are right, there's no prebuilt Windows binary. Curv.exe isn't self contained, it relies on DLLs that are installed using the dev environment, and it relies on the c++ compiler for stl file export. There's no GUI, so you need to invoke curv from the dev environment (MSYS2) command line shell.

Packaging Curv.exe for binary distribution and casual use by tinkers looks like a significant project. A GUI and a Windows installer would seem to be prerequisites.

To unsubscribe from this group and stop receiving emails from it, send an email to curv+uns...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/curv/30922846-5d08-4b31-8152-ca705025c883%40googlegroups.com.

[Andy Baker]

> You are right, there's no prebuilt Windows binary. Curv.exe isn't self contained, it relies on DLLs that are installed using the dev environment, and it relies on the c++ compiler for stl file export

I'm probably misunderstanding something but why wouldn't it work to just zip up the .exe plus the dlls? 

To view this discussion on the web, visit https://groups.google.com/d/msgid/curv/30922846-5d08-4b31-8152-ca705025c883%40googlegroups.com.

[ComFreek]

Hey there,

I am ComFreek - the one who contributed the Windows port (with lots of helpful comments by Doug).

 

Packaging Curv.exe for binary distribution and casual use by tinkers looks like a significant project. A GUI and a Windows installer would seem to be prerequisites.

Actually, I agree with Andy here. The .travis.yml file [1] I contributed already runs a successful Windows build on Travis CI, i. e. it produces a curv.exe runnable in that environment.

The only things missing for an automated Windows release are:

• Locating DLLs used by curv.exe from within Travis CI
• Deploy curv.exe and those DLLs to some location

For the second point, it seems Travis CI does not offer any free temporary storage (e.g. in contrast to AppVeyor). So the binaries would either need to be uploaded to some external provider (I heard AWS had good APIs for use in Travis) or directly to GitHub. The latter should probably only be done upon a release. I don't know what the best workflow is here to control that. Is a pseudocommit triggering that deployment a good solution? What do other projects do?

[1]: https://github.com/curv3d/curv/blob/master/.travis.yml

To view this discussion on the web, visit https://groups.google.com/d/msgid/curv/30922846-5d08-4b31-8152-ca705025c883%40googlegroups.com.