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

64-bit MS Windows builds #1413

Closed
totaam opened this issue Jan 17, 2017 · 12 comments
Closed

64-bit MS Windows builds #1413

totaam opened this issue Jan 17, 2017 · 12 comments

Comments

@totaam
Copy link
Collaborator

totaam commented Jan 17, 2017

Split from #678, related to #1253.

Following the Building MSWindows, we can get a 64-bit build environment with almost everything needed.

TODO:

  • pygtkglext is broken, we cannot load the "_gdkgl.pyd" - complains a bout a missing symbol / dll
  • NVENC / CUDA setup
  • keyboard layout mapping is wrong?
  • update the install script to include "64-bit" in the installer filename - see building all the dependencies from source on win32 #678#comment:37
@totaam
Copy link
Collaborator Author

totaam commented Jan 18, 2017

2017-01-18 12:17:40: antoine uploaded file nvenc7.pc (0.3 KiB)

pkgconfig file for nvenc7

@totaam
Copy link
Collaborator Author

totaam commented Jan 18, 2017

2017-01-18 12:17:58: antoine uploaded file nvapi.pc (0.2 KiB)

pkgconfig file for NVAPI

@totaam
Copy link
Collaborator Author

totaam commented Jan 18, 2017

2017-01-18 12:32:38: antoine commented


Packaging

64-bit packaging improvements in r14814: we can have both versions installed now.

CUDA / pycuda

  • install latest CUDA (tested with 8.0)
  • download pycuda and build it (tested with 2016.1.2):
python ./configure.py --cuda-root="c:\\Program Files\\NVIDIA GPU Computing Toolkit\\CUDA\\v8.0"

remove "/EHsc" and "/FORCE" from siteconf.py.
Add BOOST_USE_WINDOWS_H=1 in EXTRA_DEFINES of setup.py to workaround this boost bug: [http://stackoverflow.com/questions/18134148/]

python ./setup.py build -c mingw32
python ./setup.py install

Optional: rm -fr build && python3 ./setup.py clean then repeat the build with python3.

NVAPI

  • download NVAPI
  • unzip it into /mingw64/lib/NVAPI/
  • place the pkg-config file [/attachment/ticket/1413/nvapi.pc] in /mingw64/lib/pkgconfig/
    Fails: does not build with mingw, not sure how easy it would be to fix (uses DX / MSVC macros)

NVENC

  • download NVENC 7.0 from [https://developer.nvidia.com/nvidia-video-codec-sdk] - NOT 7.1 which is buggy (see recognising nvenc 7.1 fails #1414)
  • unzip it into /mingw64/lib/Video_Codec_SDK_7.0.1
  • place the pkg-config file [/attachment/ticket/1413/nvenc7.pc] in /mingw64/lib/pkgconfig/
  • build xpra with --without-nvapi (--with-nvenc7 should not be needed, nvenc should be detected automatically)

r14815 makes it possible to build the codec using Cython.
Still TODO: the CUDA kernels cannot be compiled with nvcc and mingw, or at least I haven't been able to figure out how. (the documentation does seem to indicate that it should be possible)
Options:

  • pre-compile the binary kernels on Linux - annoying, but easy to implement
  • spawn a build command that uses MSVC (setup the environment and run nvcc.exe)
  • fix the build with mingw - not sure how
  • implement ARGB source and make the CUDA CSC step optional

@totaam
Copy link
Collaborator Author

totaam commented Jan 21, 2017

  • r14824 + r14829: use BAT file to generate the kernels using MSVC
  • r14825: remove nvapi, use pynvml

Remaining tasks:

Maybe also:

@totaam
Copy link
Collaborator Author

totaam commented Jan 23, 2017

The gtkglext problem is upstream and is not in our (to be upstreamed) port of pygtkglext. Created a ticket for it: mingw-w64-x86_64-gtkglext DLL wrongly imports DllMain.

@totaam
Copy link
Collaborator Author

totaam commented Jan 24, 2017

Found a solution: build gtkglext with "-mwindows", so we now have opengl with 64-bit builds! (PS: it seems that simply building from source is enough)

@totaam
Copy link
Collaborator Author

totaam commented Jan 24, 2017

r14852 fixes the keyboard with 64-bit builds. (was a ctypes method signature error)

It's likely that there are other places where we should be more strict with C API signatures. 64-bit builds are more likely to expose these problems.

64-bit builds are also likely to be much faster at video decoding.

@afarr: over to you to find some bugs. Please bug smo to make sure you can reproduce these builds on your own environment.

I have uploaded 3 different types of r14852 builds you can test - this should help us figure out if the bug is caused by the move to msys2 (#678) or 64-bit builds.

Here's how to differentiate them from now on:

  • "Xpra-Legacy_Setup*.exe": builds made on the old XP VM (seems to be missing sound)
  • "Xpra-x86_64_Setup*.exe": 64-bit msys2 builds
  • "Xpra_Setup*exe": 32-bit msys2 builds

@totaam
Copy link
Collaborator Author

totaam commented Jan 26, 2017

2017-01-26 00:15:26: maxmylyn commented


Alright, so I pulled down all three installers and gave it a whirl against a 2.0 r13454 server (latest package available on my Fedora 25 machine, for some odd reason sound is completely borked when I build from source - am investigating):

Legacy:

  • sound is missing
  • Error about importing propsys
  • cannot import OpenGL - client exists with an import error
  • can connect with --opengl=no...which I was going to do anyways because Intel

Launcher output:

2017-01-25 13:47:58,256 propsys missing
Traceback (most recent call last):
  File "xpra\platform\win32\gui.pyc", line 53, in <module>
ImportError: No module named propsys
2017-01-25 13:47:58,256 Warning: propsys support missing, window grouping is not available
2017-01-25 13:47:58,348 Xpra gtk2 client version 2.0-[r14852](../commit/6c1ee272ad4becbf1933937589a823757b54fd17) 32-bit
2017-01-25 13:47:58,348  running on Microsoft Windows 8.1
Warning: failed to import GStreamer 1.x:
 No module named gi
2017-01-25 13:47:58,536 Error: failed to query sound subsystem:
2017-01-25 13:47:58,552  query did not return any data
xpra main error:
Traceback (most recent call last):
  File "xpra\scripts\main.pyc", line 136, in main
  File "xpra\scripts\main.pyc", line 1204, in run_mode
  File "xpra\scripts\main.pyc", line 2051, in run_client
  File "xpra\client\ui_client_base.pyc", line 434, in init_ui
  File "xpra\client\gtk_base\gtk_client_base.pyc", line 643, in init_opengl
  File "xpra\platform\win32\gui.pyc", line 189, in gl_check
ImportError: No module named OpenGL.platform

But other than that it appears to work fine.


  • 32-bit 2.0:

Appears to work fine, however there's a typo when importing gsview:

2017-01-25 14:43:42,215 Error initializing printing support:
2017-01-25 14:43:42,215  cannot find gsprint.exe in 'C:/Program Files (x86)/Xpra\gsview'

The last slash is a backslash not a forward slash.

Other than that seems to work fine.


  • 64-bit 2.0:

Same error with gsview:

2017-01-25 15:09:02,451 Error initializing printing support:
2017-01-25 15:09:02,451  cannot find gswin32c.exe in 'C:/Program Files/Xpra\gsview'

Although I do wonder if it's possible to use the 32-bit gsview for printing

@totaam
Copy link
Collaborator Author

totaam commented Jan 26, 2017

  • legacy build issues should be fixed: opengl (r14855), sound (r14857), propsys (r14858)
  • the printing issues were due to the missing ghostscript / gsview on the build machine (fixed), r14859 also makes us prefer the 64-bit version of the tools if we find it installed (note: running 32-bit applications on a 64-bit system is not a problem)

@totaam
Copy link
Collaborator Author

totaam commented Jan 26, 2017

2017-01-26 22:58:00: maxmylyn commented


No obvious bugs with the r14860 clients (connected against a 14862 2.0 server), but I do have one piece of feedback for you:

The session info does not denote what architecture the client and server are running, and since we'll be mixing 32 and 64 bit builds, it would make sense to put that information in the Session Info page.


Passing back to you - if you feel it's unnecessary, then go ahead and close (unless you have anything else that needs to be done) as I can't seem to find anything wrong with any of the builds. Anecdotally, video performance feels better because I can play FTL at a notably better FPS with the 64-bit build. I wish I had some hard data to back that up, but until then anecdotal evidence will have to suffice.

@totaam
Copy link
Collaborator Author

totaam commented Feb 18, 2017

Performance is notoriously hard to measure.

Good point about the ability to distinguish builds, r15115 adds the "64bit" string to the about dialog.

@totaam totaam closed this as completed Feb 18, 2017
@totaam
Copy link
Collaborator Author

totaam commented Nov 1, 2019

pycuda update: had to do this to get pycuda 2019.1.2 to build on MSYS2:

pushd src/cpp
ln -sf ../../bpl-subset/bpl_subset/boost pycudaboost
popd
pacman -S mingw-w64-x86_64-python3-mako mingw-w64-x86_64-python3-decorator

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant