Linux Build

[isaacbrodsky]

This depends on a branch of the deps, which depends on a modified version of vcpkg. I was able to successfully build and run the tests and the animometer example.

[ilijapuaca]

Pushed additional updates to #92 which now has CI running on macOS. Once we have dependency situation figured out, we could restore Linux clang as CI target?

[isaacbrodsky]

Builds except for the flight-paths example which depends on microsoft/vcpkg#11016.

I changed GCC to 9 to match the other build script.

[isaacbrodsky]

Now ready for review. Main changes are:

• Mainly, changes to the dependencies submodule to build on Linux (mainly enabling optional features on Arrow in vcpkg)
• GCC requires viewport-uniforms fields be ordered a certain way; I assume this is a safe change but good to check on Mac that there's nothing unexpected in rendering
• Minor fixes; missing includes and accidental platform specific type.

Benefits of this PR:

• Can build the repo and run the tests under Linux (no support for running graphics)
• CI tests this and uses the Linux build to run the tests under Valgrind, so we can detect memory issues that way.

[ilijapuaca]

Awesome, we should land this one with all the arrow stuff out of the way. A few questions:

• Does drawing work on Linux? You mentioned animometer example was running on using OpenGL, what about flight paths?
• Seeing quite a few warnings in travis build, is that also the case when you build locally? Just making sure it's consistent, most of them are type related and should be easy to fix once I get around to fixing gcc build on macOS
• Is this something we should be worried about?

==8479== LEAK SUMMARY:
==8479==    definitely lost: 3,848 bytes in 35 blocks
==8479==    indirectly lost: 832 bytes in 26 blocks
==8479==      possibly lost: 0 bytes in 0 blocks
==8479==    still reachable: 0 bytes in 0 blocks
==8479==         suppressed: 0 bytes in 0 blocks
==8479== Rerun with --leak-check=full to see details of leaked memory

[ilijapuaca]

Just curious, what kind of order does gcc try to enforce? This doesn't seem to match order within the actual struct

[isaacbrodsky]

GCC was complaining that the initializers weren't in the order the fields were declared in.

[ilijapuaca]

The order they are currently in on this branch does not match what's on master, that's why it looked pretty random to me. Perhaps we need to rebase to make sure it works after we merge

[isaacbrodsky]

Awesome, we should land this one with all the arrow stuff out of the way. A few questions:

* Does drawing work on Linux? You mentioned animometer example was running on using OpenGL, what about flight paths?

At the moment it does not work. animometer does not render with this error:

$ build/gcc/cpp/examples/luma.gl/animometer 
Info: vkCreateInstance failed with VK_ERROR_INCOMPATIBLE_DRIVER
Error: Validation error: Pipeline attachment state is not compatible
Error: Validation error: Object is an error.
Error: Validation error: Pipeline attachment state is not compatible
Error: Validation error: Object is an error.
Error: Validation error: Pipeline attachment state is not compatible
Error: Validation error: Object is an error.
...

Same issue on flight-paths right now.

* Seeing quite a few warnings in travis build, is that also the case when you build locally? Just making sure it's consistent, most of them are type related and should be easy to fix once I get around to fixing gcc build on macOS

Yes, the messages are consistent with my local build.

* Is this something we should be worried about?

==8479== LEAK SUMMARY:
==8479==    definitely lost: 3,848 bytes in 35 blocks
==8479==    indirectly lost: 832 bytes in 26 blocks
==8479==      possibly lost: 0 bytes in 0 blocks
==8479==    still reachable: 0 bytes in 0 blocks
==8479==         suppressed: 0 bytes in 0 blocks
==8479== Rerun with --leak-check=full to see details of leaked memory

It's not a big deal but I would prefer to eliminate leaks from the tests if possible. Usually this happens because when writing the test we might not bother to free some allocated memory, since the application will be torn down after the test.

[ilijapuaca]

$ build/gcc/cpp/examples/luma.gl/animometer
Info: vkCreateInstance failed with VK_ERROR_INCOMPATIBLE_DRIVER
Error: Validation error: Pipeline attachment state is not compatible
Error: Validation error: Object is an error.
Error: Validation error: Pipeline attachment state is not compatible
Error: Validation error: Object is an error.
Error: Validation error: Pipeline attachment state is not compatible
Error: Validation error: Object is an error.

This indicates that it's trying to use Vulkan, and I'm not sure what kind of state that's in. Perhaps it's just a matter of drivers on your machine not being compatible, but we can just switch up the order in which they are prioritized and bump OpenGL up if that works

[isaacbrodsky]

$ build/gcc/cpp/examples/luma.gl/animometer
Info: vkCreateInstance failed with VK_ERROR_INCOMPATIBLE_DRIVER
Error: Validation error: Pipeline attachment state is not compatible
Error: Validation error: Object is an error.
Error: Validation error: Pipeline attachment state is not compatible
Error: Validation error: Object is an error.
Error: Validation error: Pipeline attachment state is not compatible
Error: Validation error: Object is an error.

This indicates that it's trying to use Vulkan, and I'm not sure what kind of state that's in. Perhaps it's just a matter of drivers on your machine not being compatible, but we can just switch up the order in which they are prioritized and bump OpenGL up if that works

I think that was how I previously got it to work - looks like at some point it reverted to trying Vulkan.

Edit: Recompiling Dawn without Vulkan still gives this error. Possibly deck.gl is trying to use the wrong renderer, though, since Vulkan shouldn't have been used in the first place.