viennacl / viennaclbench-dev

A GUI for displaying benchmark results obtaind for operations in ViennaCL
Other
5 stars 3 forks source link

Qt5 Build Process #3

Closed matusi143 closed 10 years ago

matusi143 commented 10 years ago

When making the following modification to the *.pro file:

Add include folders

INCLUDEPATH += "C:\Users\matth_000\AMD APP SDK\2.9\include" INCLUDEPATH += C:\ViennaCL-1.5.1 INCLUDEPATH += C:\boost_1_54_0

DEPENDPATH += "C:\Users\matth_000\AMD APP SDK\2.9\include" DEPENDPATH += C:\ViennaCL-1.5.1 DEPENDPATH += C:\boost_1_54_0

The following build errors occur:

Issue: :-1: error: D8021 : invalid numeric argument '/Wno-unused-local-typedefs' :-1: error: D8021 : invalid numeric argument '/Wno-unused-local-typedefs' :-1: error: D8021 : invalid numeric argument '/Wno-unused-local-typedefs'

Logs: 14:19:31: Running steps for project ViennaCL_Benchmark... 14:19:31: Configuration unchanged, skipping qmake step. 14:19:31: Starting: "C:\Qt\Tools\QtCreator\bin\jom.exe" install C:\Qt\Tools\QtCreator\bin\jom.exe -f Makefile.Release install C:\Qt\5.3\msvc2013_64\bin\uic.exe ..\viennacl-benchmark-gui-master\src\mainwindow.ui -o ui_mainwindow.h cl -c -nologo -Zm200 -Zc:wchar_t -FS -Wno-unused-local-typedefs -Wno-unused-parameter -DVIENNACL_WITH_OPENCL -O2 -MD -GR -W3 -w34100 -w34189 -EHsc -DUNICODE -DWIN32 -DWIN64 -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_OPENGL_ES_2 -DQT_OPENGL_ES_2_ANGLE -DNDEBUG -I"..\Users\matth_000\AMD APP SDK\2.9\include" -I"..\ViennaCL-1.5.1" -I"..\boost_1_54_0" -I"C:\viennacl-benchmark-gui-master..........\AMDAPPSDK\2.9\lib\x86_64" -I"..\Qt\5.3\msvc2013_64\include" -I"..\Qt\5.3\msvc2013_64\include\QtWidgets" -I"..\Qt\5.3\msvc2013_64\include\QtGui" -I"..\Qt\5.3\msvc2013_64\include\QtANGLE" -I"..\Qt\5.3\msvc2013_64\include\QtCore" -I"release" -I"." -I"." -I"..\Qt\5.3\msvc201364\mkspecs\win32-msvc2013" -Forelease\ @C:\Users\MATTH~1\AppData\Local\Temp\main.obj.5480.157.jom cl : Command line error D8021 : invalid numeric argument '/Wno-unused-local-typedefs' cl -c -nologo -Zm200 -Zc:wchar_t -FS -Wno-unused-local-typedefs -Wno-unused-parameter -DVIENNACL_WITH_OPENCL -O2 -MD -GR -W3 -w34100 -w34189 -EHsc -DUNICODE -DWIN32 -DWIN64 -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_OPENGL_ES_2 -DQT_OPENGL_ES_2_ANGLE -DNDEBUG -I"..\Users\matth_000\AMD APP SDK\2.9\include" -I"..\ViennaCL-1.5.1" -I"..\boost_1_54_0" -I"C:\viennacl-benchmark-gui-master..........\AMDAPPSDK\2.9\lib\x86_64" -I"..\Qt\5.3\msvc2013_64\include" -I"..\Qt\5.3\msvc2013_64\include\QtWidgets" -I"..\Qt\5.3\msvc2013_64\include\QtGui" -I"..\Qt\5.3\msvc2013_64\include\QtANGLE" -I"..\Qt\5.3\msvc2013_64\include\QtCore" -I"release" -I"." -I"." -I"..\Qt\5.3\msvc201364\mkspecs\win32-msvc2013" -Forelease\ @C:\Users\MATTH~1\AppData\Local\Temp\qcustomplot.obj.5480.157.jom cl -c -nologo -Zm200 -Zc:wchar_t -FS -Wno-unused-local-typedefs -Wno-unused-parameter -DVIENNACL_WITH_OPENCL -O2 -MD -GR -W3 -w34100 -w34189 -EHsc -DUNICODE -DWIN32 -DWIN64 -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_OPENGL_ES_2 -DQT_OPENGL_ES_2_ANGLE -DNDEBUG -I"..\Users\matth_000\AMD APP SDK\2.9\include" -I"..\ViennaCL-1.5.1" -I"..\boost_1_54_0" -I"C:\viennacl-benchmark-gui-master..........\AMDAPPSDK\2.9\lib\x86_64" -I"..\Qt\5.3\msvc2013_64\include" -I"..\Qt\5.3\msvc2013_64\include\QtWidgets" -I"..\Qt\5.3\msvc2013_64\include\QtGui" -I"..\Qt\5.3\msvc2013_64\include\QtANGLE" -I"..\Qt\5.3\msvc2013_64\include\QtCore" -I"release" -I"." -I"." -I"..\Qt\5.3\msvc201364\mkspecs\win32-msvc2013" -Forelease\ @C:\Users\MATTH~1\AppData\Local\Temp\benchmark_vector.obj.5480.188.jom cl : Command line error D8021 : invalid numeric argument '/Wno-unused-local-typedefs' jom: C:\build-ViennaCL_Benchmark-Desktop_Qt_5_3_0_MSVC2013_64bit-Release\Makefile.Release [release\qcustomplot.obj] Error 2 cl : Command line error D8021 : invalid numeric argument '/Wno-unused-local-typedefs' jom: C:\build-ViennaCL_Benchmark-Desktop_Qt_5_3_0_MSVC2013_64bit-Release\Makefile.Release [release\benchmark_vector.obj] Error 2 jom: C:\build-ViennaCL_Benchmark-Desktop_Qt_5_3_0_MSVC2013_64bit-Release\Makefile.Release [release\main.obj] Error 2 jom: C:\build-ViennaCL_Benchmark-Desktop_Qt_5_3_0_MSVC2013_64bit-Release\Makefile [release-install] Error 2 14:19:31: The process "C:\Qt\Tools\QtCreator\bin\jom.exe" exited with code 2. Error while building/deploying project ViennaCL_Benchmark (kit: Desktop Qt 5.3.0 MSVC2013 64bit) When executing step 'Make' 14:19:31: Elapsed time: 00:01.

karlrupp commented 10 years ago

This is due to the flags -Wno-unused-local-typedefs -Wno-unused-parameter which are only available with GCC 4.8 and above. These should not be hard-coded, or at least guarded such that they are only active with GCC.

matusi143 commented 10 years ago

Thanks Karl, I am using msvc-12.0 (VS2013) and soon clang 3.5.0 both on Windows 8.1. It would be desirable not to have to use GCC.

namikk commented 10 years ago

I've made some progress with QMake+OpenCL build and QMake+MSVC compatibility.

My initial goal was to address the current build issues with CMake+MSVC build, but I soon realized that won't end well since I'm not that good with CMake. Instead I focused on enabling OpenCL with QMake, and fixing compatibility issues when compiling with MSVC. It's still far from operational, but we're getting there.

-About enabling OpenCL with QMake: The .pro file will now attempt to automatically locate OpenCL using OPENCLROOT environment path. A similar approach is used in the CMake build. The OPENCLROOT environment variable needs to point to the root folder of your OpenCL folder and should contain the /include and /lib/x86 folders. In case OPENCLROOT is not set, manual setup is possible by changing the hardcoded default path OPENCLROOT = "C:\AMDAPPSDK\2.9". OpenCL can be enabled only in release mode.

There are still, however, some missing things in this OpenCL configuration attempt. Even though it compiles fine, at runtime I get a lot of 'screaming' from ViennaCL. Most of the benchmark tests fail to execute, and instead give outputs of the following type:

ViennaCL: Setting handle kernel argument 0x57c1dd8 at pos 3 for kernel kernel_0_0 ViennaCL: Setting unsigned int kernel argument 1920 at pos 4 for kernel kernel_0_0 ViennaCL: Setting unsigned int kernel argument 0 at pos 1 for kernel trans_lower_trans_solve ViennaCL: Setting unsigned int kernel argument 0 at pos 2 for kernel trans_lower_trans_solve ViennaCL: Setting unsigned int kernel argument 1 at pos 3 for kernel trans_lower_trans_solve

and a thousand more outputs of the same type, but with different numbers. I'm assuming there are certain ViennaCL config settings I didn't define. Perhaps Karl and Philippe will know what needs to be defined.

-About QMake+MSVC: I didn't know MSVC was so inflexible and stubborn. After lots of code refactoring and adapting, I was able to barely pass compilation with Qt5.3.1 MSVC10 32bit. The build fails when linking Boost libraries. For some mysterious reason, MSVC seems to be attempting to link against static libs and fails with the following error: LNK1104: cannot open file 'libboost_serialization-vc100-mt-1_55.lib'. I tried forcing it to use dynamic libs with various combinations of these qmake commands: DEFINES += BOOST_ALL_DYN_LINK=1 DEFINES += BOOST_ALL_DYN_LINK=ON DEFINES += BOOST_ALL_DYN_LINK="ON" DEFINES += "BOOST_ALL_DYN_LINK=ON" QMAKE_CXXFLAGS += -DBOOST_ALL_DYN_LINK

and these variables: Boost_USE_STATIC_LIBS, Boost_USE_MULTITHREADED, Boost_USE_STATIC_RUNTIME

Nothing helped. I currently have no idea how to make MSVC link against dynamic boost libs.

Will update if I make any significant progress in the future.

Regards, Namik

On Mon, Jun 30, 2014 at 2:27 AM, matusi143 notifications@github.com wrote:

Thanks Karl, I am using msvc-12.0 (VS2013) and soon clang 3.5.0 both on Windows 8.1. It would be desirable not to have to use GCC.

— Reply to this email directly or view it on GitHub https://github.com/viennacl/viennacl-benchmark-gui/issues/3#issuecomment-47486183 .

matusi143 commented 10 years ago

Namik,

I was able to hack together a build to get it to compile is MSVC 2013. Adding boost/stage/lib to your library directories and this link will hopefully point you in the right direction on some of the other issues.

http://stackoverflow.com/questions/9628527/linker-error-lnk1104-with-libboost-filesystem-vc100-mt-s-1-49-lib

I will take your latest build tonight and let you know step by step what I did to get it to 'almost work'. I will start with CMake and go through the *.sln file compile parameter changes necessary to get past the linking steps.

Thanks, -Matt

matusi143 commented 10 years ago

Namik,

Just curious if you are seeing the same issues I am after resolving the boost linking issue by using the /MDd compile flag and setting incremental linking to NO.

-Matt

Error 2564 error LNK1120: 3 unresolved externals C:\viennacl-benchmark-gui-master\build\Debug\ViennaCL_Benchmark.exe ViennaCL_Benchmark

Error 2563 error LNK2001: unresolved external symbol "public: virtual int __cdecl Benchmark_Scheduler::qt_metacall(enum QMetaObject::Call,int,void * *)" (?qt_metacall@Benchmark_Scheduler@@UEAAHW4Call@QMetaObject@@HPEAPEAX@Z) C:\viennacl-benchmark-gui-master\build\benchmark_scheduler.obj ViennaCL_Benchmark

Error 2561 error LNK2001: unresolved external symbol "public: virtual struct QMetaObject const * __cdecl Benchmark_Scheduler::metaObject(void)const " (?metaObject@Benchmark_Scheduler@@UEBAPEBUQMetaObject@@XZ) C:\viennacl-benchmark-gui-master\build\benchmark_scheduler.obj ViennaCL_Benchmark

Error 2562 error LNK2001: unresolved external symbol "public: virtual void * __cdecl Benchmark_Scheduler::qt_metacast(char const *)" (?qt_metacast@Benchmark_Scheduler@@UEAAPEAXPEBD@Z) C:\viennacl-benchmark-gui-master\build\benchmark_scheduler.obj ViennaCL_Benchmark

karlrupp commented 10 years ago

On the boost issue: This is and will always be a nightmare, unless we drop any use of Boost.

I should be able to try the CMake and QMake builds tomorrow and at least fix the detection of OpenCL under CMake.

karlrupp commented 10 years ago

@namikk : On the verbose output: Did you define any of the VIENNACLDEBUG* preprocessor defines? This is typical output with such debug functionality enabled. It should not show up in default builds.

namikk commented 10 years ago

@Matthew

Adding boost/stage/lib to your library directories and this link will hopefully point you in the right direction on some of the other issues.

Just curious if you are seeing the same issues I am after resolving the boost linking issue by using the /MDd compile flag and setting incremental linking to NO.

Thank you very much. It finally works! Here's what I did:

  1. added stage/lib folder: INCLUDEPATH += C:\boost\boost_1_55_0\stage\lib
  2. added libs from the stage/lib folder: LIBS += "-LC:/boost/boost_1_55_0/stage/lib/"
  3. added a single define: DEFINES += BOOST_ALL_DYN_LINK
  4. disabled incremental linking(later I found out it is disabled by default): QMAKE_LFLAGS_RELEASE = /INCREMENTAL:NO
  5. mistakenly added: QMAKE_CXXFLAGS += /MT, luckily BOOST_ALL_DYN_LINK corrected this and used /MD instead. So it should be QMAKE_CXXFLAGS += /MD for dynamic linking in release, and QMAKE_CXXFLAGS += /MDd for dynamic linking in debug.

The project compiled and ran without problems using Qt5.3.1 MSVC10 32bit. Matthew, your errors might be due to leftover files from previous builds. These 5 things I added came into effect only after I manually deleted the entire target build folder. Try doing the same and see if it helps.

@Karl

I should be able to try the CMake and QMake builds tomorrow and at least fix the detection of OpenCL under CMake.

Detection under CMake depends on the OPENCLROOT environment variable.

One issue is that FindOpenCL.cmake file needs to be manually copied to CMake's module folder, instead of shipping it with the project and loading it when running CMake. I didn't know how to achieve this so it has to be done manually at the moment.

Another possible issue is that OPENCLROOT variable cannot be user defined through CMake. I didn't want to mess around FindOpenCL.cmake file so I didn't implement support for user definable OpenCL root path.

The errors reported by Matthew, in my opinion, are mostly due to MSVC's incompatibility. If we intend to support MSVC then solving Matthew's CMake MSVC errors are top priority.

On the verbose output: Did you define any of the VIENNACLDEBUG*

preprocessor defines? This is typical output with such debug functionality enabled. It should not show up in default builds.

No, I don't think so. What are the needed defines? Can I find them somewhere in ViennaCL sources? Also, why debug? The runtime errors I'm seeing (ViennaCL: Setting unsigned int kernel argument 1920 at pos 4 for kernel kernel_0_0 ViennaCL: Setting unsigned int kernel argument 0 at pos 1 for kernel trans_lower_trans_solve etc..) occur in release mode when using QMake build file with Qt5.x MinGW.

Whats interesting is that these errors are gone when using the same QMake build file but with Qt5.3.1 MSVC10 32bit(the one I just fixed with Matthew's help).

Regards, Namik

On Sun, Jul 6, 2014 at 11:49 PM, Karl Rupp notifications@github.com wrote:

@namikk https://github.com/namikk : On the verbose output: Did you define any of the VIENNACLDEBUG* preprocessor defines? This is typical output with such debug functionality enabled. It should not show up in default builds.

— Reply to this email directly or view it on GitHub https://github.com/viennacl/viennacl-benchmark-gui/issues/3#issuecomment-48128173 .

matusi143 commented 10 years ago

Namik,

The program built just fine with the following compiler options:

/GS /TP /GL /W3 /Zc:wchar_t /I"C:\viennacl-benchmark-gui-master\build" /I"C:\viennacl-benchmark-gui-master" /I"C:\viennacl-dev-master" /I"C:\Program Files (x86)\AMD APP SDK\2.9\include" /I"C:\boost_dev\boost_root" /I"C:\Qt\5.3\msvc2013_64\include" /I"C:\Qt\5.3\msvc2013_64\include\QtCore" /I"C:\Qt\5.3\msvc2013_64\mkspecs\win32-msvc2013" /I"C:\Qt\5.3\msvc2013_64\include\QtGui" /I"C:\Qt\5.3\msvc2013_64\include\QtANGLE" /I"C:\Qt\5.3\msvc2013_64\include\QtWidgets" /Gm- /O2 /Ob2 /Fd"ViennaCL_Benchmark.dir\Release\vc120.pdb" /fp:precise /D "WIN32" /D "_WINDOWS" /D "VIENNACL_WITH_OPENCL" /D "NDEBUG" /D "QT_CORE_LIB" /D "QT_GUI_LIB" /D "QT_WIDGETS_LIB" /D "_FILE_OFFSET_BITS=64" /D "QT_NO_DEBUG" /D "CMAKE_INTDIR=\"Release\"" /D "_MBCS" /errorReport:prompt /WX- /Zc:forScope /GR /Gd /MD /Fa"Release/" /EHsc /nologo /Fo"ViennaCL_Benchmark.dir\Release\" /Fp"ViennaCL_Benchmark.dir\Release\ViennaCL_Benchmark.pch"

addition parameter: -fPIC

I had to copy a ton of qt5 *.dll files to my windows/system32 directory to get it to actually run though.

Now it runs but closes almost immediately, no UI is built and it closes before I can interact with it. I am going to put in some debug to see if I can see the messages in the program.

For future users, you may want to call out all the dll files you need to copy to windows/system32 and the cmake process still requires me to add all the cmake files for things like the qt5 core, widgets and printer support during the build process.

Thanks, -Matt

matusi143 commented 10 years ago

Namik,

The specific error when running is:

This application failed to start because it could not find or load the Qt platform plugin "windows". Available platform plugins are: minimal, offscreen, windows. Reinstalling the application may fix this problem.

-Matt

namikk commented 10 years ago

Matthew,

manually copying Qt .dll files into system32 is definitely not acceptable. I'm really curios why it couldn't find Qt automatically. CMake comes with the FindQt module by default, so there shouldn't be any problems with locating Qt dlls, provided system path and environment variables are set. Try defining the following system environment variables:

-Path to qmake.exe: Variable name: QT_UIC_EXECUTABLE Variable value: F:\Qt5.2\5.2.0\mingw48_32\bin\qmake.exe

-Path to Qt's dlls: Variable name: QT_ROOT Variable value: F:\Qt5.2\5.2.0\mingw48_32\bin Sometimes this variable is called qt, so add that too Variable name: qt Variable value: F:\Qt5.2\5.2.0\mingw48_32\bin

Maybe even try adding the bin folder to system Path, just in case...

CMake should be able to properly find Qt with these variables.

Regards, Namik

On Mon, Jul 7, 2014 at 1:41 AM, Matthew Musto notifications@github.com wrote:

Namik,

The specific error when running is:

This application failed to start because it could not find or load the Qt platform plugin "windows". Available platform plugins are: minimal, offscreen, windows. Reinstalling the application may fix this problem.

-Matt

— Reply to this email directly or view it on GitHub https://github.com/viennacl/viennacl-benchmark-gui/issues/3#issuecomment-48130647 .

karlrupp commented 10 years ago

Some progress on the CMake front: It is no longer necessary to copy the FindOpenCL.cmake file to a system location. @namikk and @matusi143 , please remove your copies from the system location. Relevant commit: https://github.com/viennacl/viennacl-benchmark-gui/commit/284c1851f159519bab0c534e4c09b2e72cb045d8

Also, I fixed a use of the Qt4 macro qt4_use_modules(), which requires CMake 2.8.11 or above, here: https://github.com/viennacl/viennacl-benchmark-gui/commit/5060f4d97796ef25dbbb3fb80ef6f7f78112ed68 I based the workaround on this discussion: http://comments.gmane.org/gmane.comp.programming.tools.cmake.devel/6002 which works with my CMake 2.8.7 installation.

@namikk : My build using CMake completes, but running 'ViennaCL_Benchmark' only prints some output to the terminal. Isn't this supposed to be a GUI?

matusi143 commented 10 years ago

@karlrupp thank you for the updates. I just ran the latest version with your submit from about 20 minutes ago. Things went very smoothly. I too am just seeing output to the terminal rather than a GUI and for some reason my AMD driver crashes with the double precision benchmark so I don't get to the end to see if a GUI pops then. @namikk adding those environmental variables worked well. I removed the dlls in system32 and things ran well.

matusi143 commented 10 years ago

@karlrupp I take back my earlier comment about not seeing any output. It seems that when I plug my laptop in (A10-5750M) the driver does not crash on the double precision blas benchmark (I will investigate my power management settings). Regardless, once the cmd prompt finished printing the output the gui does open. It isn't fully populated yet but it does work! Great job @namikk!

namikk commented 10 years ago

@karlrupp Thanks for the updates. Finding OpenCL now works properly with the shipped FindOpenCL file.

My build using CMake completes, but running 'ViennaCL_Benchmark' only prints some output to the terminal. Isn't this supposed to be a GUI?

About that, I was doing some experiments with custom widgets when I switched to fixing QMake+MSVC build. The UI is currently disconnected and that's why there's only console output. I'm working on fixing it and getting an initial basic view up and running. Should be done by the end of the day.

@matusi143 Glad to hear the environment variables helped. I'm curious why your laptop's AMD driver crashed when not plugged in. @karlrupp Could the benchmark be so GPU intensive that it can't run without extra juice?

On Tue, Jul 8, 2014 at 12:59 AM, Matthew Musto notifications@github.com wrote:

@karlrupp https://github.com/karlrupp I take back my earlier comment about not seeing any output. It seems that when I plug my laptop in (A10-5750M) the driver does not crash on the double precision blas benchmark (I will investigate my power management settings). Regardless, once the cmd prompt finished printing the output the gui does open. It isn't fully populated yet but it does work! Great job @namikk https://github.com/namikk!

— Reply to this email directly or view it on GitHub https://github.com/viennacl/viennacl-benchmark-gui/issues/3#issuecomment-48252368 .

karlrupp commented 10 years ago

@namikk : I haven't heard of problems in battery-powered runs so far with OpenCL, but I know that some dedicated GPUs have reduced speed (and maybe functionality?) without power cord. Maybe the OpenCL SDK does not properly check for the features in low power mode?

@matusi143 : If you run some simpler ViennaCL-benchmarks, e.g. examples/benchmarks/vectorbench-opencl, does the same problem show up?

matusi143 commented 10 years ago

@karlrupp : Interestingly enough, it seems it is only the most demanding of the benchmarks (blas) that very consistently crashes the AMD driver. It happens during the more demanding double precision section. When I plug in it runs just fine. I ran all of the other examples on battery power without issue. On my HP laptop with an AMD A10-5750M (richland apu) I did notice about a 2x performance difference in gflops between battery and the cord which is more than I expected but consistent with power throttling.