Vector Types (GLM)

[ptheywood]

Vector types (vec4 etc. ) make stuff nicer.

CUDA now includes simple versions of these, but doens't provdie all of the functionality.

Use GLM again, but RTC might not get along with GLM.

Should include examples which make use of vector types (boids)

[Robadob]

Required CMake changes, could perhaps set include dir to a variable for ease
Note, this just adds the root of the repo, so that glm is required at start of glm includes.

Probably requires a tweak to ensure all examples use the same copy, haven't tested it in that context.

CMakeLists.txt

# Pull in GLM
MACRO (download_glm)
    configure_file(cmake/glm/CMakeLists.txt.in glm-download/CMakeLists.txt)
    # Run CMake generate
    execute_process(
        COMMAND ${CMAKE_COMMAND} -G "${CMAKE_GENERATOR}" .
        RESULT_VARIABLE result
        WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/glm-download
        )
    if (result)
        message(WARNING 
                "CMake step for glm failed: ${result}\n")
    endif()
    # Run CMake build (this only downloads, it is built at build time)
    execute_process(
    COMMAND ${CMAKE_COMMAND} --build .
    RESULT_VARIABLE result
    WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/glm-download
    )
    if (result)
        message(WARNING 
                "Download step for glm-download failed: ${result}\n"
                "Attempting to continue\n")
    endif()
ENDMACRO()
download_glm()
# Then this after project has been created
target_include_directories("${PROJECT_NAME}" SYSTEM PRIVATE ${CMAKE_CURRENT_BINARY_DIR}/glm-src)

cmake/glm/CMakeLists.in

cmake_minimum_required(VERSION 2.8.2)

include(ExternalProject)

project(glm-download NONE)
ExternalProject_Add(glm
    GIT_REPOSITORY    "https://github.com/g-truc/glm.git"
    GIT_TAG           "0.9.9.7"
    SOURCE_DIR        "${CMAKE_CURRENT_BINARY_DIR}/glm-src"
    BINARY_DIR        ""
    CONFIGURE_COMMAND ""
    BUILD_COMMAND     ""
    INSTALL_COMMAND   ""
    TEST_COMMAND      ""
    )

[ptheywood]

FLAMEGPU_DEPENDENCY_INCLUDE_DIRECTORIES and FLAMEGPU_DEPENDENCY_LINK_LIBRARIES were introduced when I added NVTX support in common.cmake, so you should be able to do

set(FLAMEGPU_DEPENDENCY_INCLUDE_DIRECTORIES ${FLAMEGPU_DEPENDENCY_INCLUDE_DIRECTORIES} ${CMAKE_CURRENT_BINARY_DIR}/glm-src)

Although you'll need to make sure that this happens after initialisation of the variable.

https://github.com/FLAMEGPU/FLAMEGPU2_dev/blob/b5b56412b9ae49a7caca44cddbc180e5225fb9e5/cmake/common.cmake#L66

[Robadob]

The question in my mind is whether CMAKE_CURRENT_BINARY_DIR will be wrong, for subprojects.

[Robadob]

Oh, also FLAMEGPU_DEPENDENCY_LINK_LIBRARIES might be redundant. CMake already forwards linking dependencies.

[ptheywood]

Oh, also FLAMEGPU_DEPENDENCY_LINK_LIBRARIES might be redundant. CMake already forwards linking dependencies.

target_link_libraries is not automatic for custom find_package commands at least, The variable is used to minimise the number of target_link_libraries commands needed in each of the two link sections.

Potentially it's not needed for the executables macro, as they might be implied from the static libraries link targets, but I'm unsure about this / there is no harm in it anyway.

[Robadob]

If i tell CMake that FPGU lib target needs to link against SDL2 (it can't, static libs don't 'link'). Anything which is told to link against FGPU lib target will also link against SDL2.

That's what i meant.

Not aware of a way to share include dirs like this though.

[ptheywood]

Yeah so it's probable redundent in the executable macro/func but still useful for the library macro/func.

Cmake is set up on linux that you can build it just for an example, I'm not sure how that will play with the library built separately and purely linked against. I'm not sure how this plays on windows either, as I only tested it on linux (maybe windows a long while ago).
This may actually have stopped working once compiled parts were moved into the build directory rather than the root, I've not tested this recently.

[Robadob]

Building from individual example CMakeLists.txt should still work, I checked it built after my visualisation changes the other day.

[ptheywood]

Vecotor types will potentially be a big improvement over non-vector types in the C++ interface (esp. in messages) by reducing the curve overheads by 1/N. i.e. a vec4 wil have 1/4 of the curve overheads of 4 float accesses.

[Robadob]

Given how fiddley RTC can be, I'm curious to find out how happy NVRTC is building agent functions that use GLM.

[Robadob]

First attempt at building RTC with GLM. Tweaked JitifyCache to also pass the glm-src directory from vis. Appears to me as though Jitify's include parsing doesn't handle relative include paths, when recursing the include tree.

[Robadob]

Having fixed that Jitify issue (locally), get some new errors, which might be harder to fix.

---------------------------------------------------
--- JIT compile log for inputdata_program ---
---------------------------------------------------
detail/setup.hpp(695): error: namespace "std" has no member "make_unsigned"

detail/func_common.inl(585): error: namespace "std" has no member "isnan"

detail/func_common.inl(624): error: namespace "std" has no member "isinf"

detail/func_common.inl(742): error: namespace "std" has no member "fma"

4 errors detected in the compilation of "inputdata_program".

isnan isinf are cuda intrinsic, it's complaining because of the use of std::isnan and std::isinf, nvcc doesn't like them being preprended with std:: either.

fma is quite literally standard library fused multiply add function, cuda docs have the f/d versions, so again probably supported sans std::.

Have managed to fix 3 of the issues by making GLM detect NVRTC properly (g-truc/glm#1073)

make_unsigned is some template magic from the type_traits header, so probably requires some jitify magic.

With std::make_unsigned added to the Jitify<type_traits> shim (NVIDIA/jitify#89), GLM include to an RTC agent function now builds!.

[ptheywood]

From CINECA profiling, we know that for very scattered accesses (unsorted agent message reads) that fewer, larger reads (AoS) can improve performance. This is essentially a vector type.

[Robadob]

#597
This can be closed?

[ptheywood]

I think so, the RTC version will come out from behind the flag as part of #602

[Robadob]

I think so, the RTC version will come out from behind the flag as part of #602

The whole thing is behind a flag currently. Although there's nothing stopping people from including GLM themselves.