Ceres Solver Version 2.1.0 Release Candidate 1

111 views
Skip to first unread message

Sameer Agarwal

unread,
Mar 4, 2022, 2:51:25 PM3/4/22
to ceres-...@googlegroups.com
Hi Everyone,

The first release candidate for Ceres Solver Version 2.1.0 is here. 


This release brings a number of significant changes:
  1. CUDA support is here! This will help accelerate DENSE_QR, DENSE_NORMAL_CHOLESKY and above all DENSE_SCHUR. 
  2. The LocalParameterization interface is deprecated, Manifold interface is the new hotness. This (2.1.0) is a transition release. Currently you can use them both and changing your code to use a Manifold instead of a LocalParameterization will not affect solution quality. In the next release (2.2.0) LocalParameterization will be deleted and we will actually start using their capabilities inside the solver.
  3. Jets have undergone significant changes. It is now possible to safely compare a Jet against a scalar (or literal) without constructing a Jet first (even if it’s nested). Besides that, 
  4. Much improved Windows Support.
  5. The CMake based build system has been significantly overhauled to be simpler and more robust across platforms.
Besides the above, there is the usual bevy of bug fixes and improvements all over the code base.

Please give this release a spin and report back with your experiences. We want to hear about your experience (positive and negative) porting your code to using Manifolds, using CUDA and building on platforms other than linux and macos.

Issues can be reported on GitHub or on this mailinglist.

Thank you,
Sameer for the Ceres Solver Team

1262871536

unread,
Mar 4, 2022, 2:51:31 PM3/4/22
to Sameer Agarwal' via Ceres Solver <>
这是来自QQ邮箱的假期自动回复邮件。

您好,我最近正在休假中,无法亲自回复您的邮件。我将在假期结束后,尽快给您回复。

Yan Cui

unread,
Mar 17, 2022, 5:24:05 PM3/17/22
to Ceres Solver
Hi Sameer,

Thanks for the highlights, and for the next release 2.2.0 when LocalParameterization will be deleted, may I ask how does the rough timeline look like?

Thank you,
Yan

Sameer Agarwal

unread,
Mar 17, 2022, 5:32:04 PM3/17/22
to ceres-...@googlegroups.com
Yan,
I do not have a fixed timeline, but I expect that LocalParameterization will be removed by end of Q2 (so june or so). I do not have an ETA for 2.2.0, I suspect not before the end of year.
Sameer


--
You received this message because you are subscribed to the Google Groups "Ceres Solver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceres-solver...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/84b7604a-1455-4c9a-ae46-985cca090f49n%40googlegroups.com.

Yan Cui

unread,
Mar 17, 2022, 5:37:29 PM3/17/22
to Ceres Solver
Sounds great, and thank you Sameer.

Yan

Sameer Agarwal

unread,
Mar 19, 2022, 10:59:07 AM3/19/22
to ceres-...@googlegroups.com
Folks,
It has been fairly quiet except for some windows related issues from Patrik Huber. If I do not hear otherwise my plan is to release 2.1 on Monday March 28th.
It will be a while before the next stable release and that will be an API breaking release, so I strongly recommend testing this release with your setup.
Sameer


Patrik Huber

unread,
Mar 19, 2022, 7:21:17 PM3/19/22
to ceres-...@googlegroups.com
Hi Sameer,

Thank you for all your great work!

I've played around with manifolds and some AutoDiffCostFunctions over the past few days, and it all worked great so far under Windows with VS2022.

I've just very briefly tried compiling Ceres under a few different CMAKE_CXX_STANDARD modes, and a few things came up. It was all a bit in a rush, as I am leaving for a one-week seminar abroad - I might not have time to follow any of this up next week but I still quickly wanted to post it, and I can try my best next week to reply if needed.

First, one small observation: I noticed that there are no additional CMake targets when building with BUILD_BENCHMARKS=ON. Is that expected? (i.e. there seem to be no benchmark targets whatsoever)

Next, I compiled with CMAKE_CXX_STANDARD=17, Ceres itself and the examples compiled fine, but some of the tests give the following compiler error:
image.png
I think one of them is internal/ceres/CMakeFiles/jet_test.dir/jet_test.cc.obj. Most of the tests do seem to compile without error.
I haven't actually run the tests that did compile as I ran out of time, but I can try to do that next week or the week after if it helps. I will be using the C++17 and C++20 modes going forward.

Next, with CMAKE_CXX_STANDARD=20, Ceres & examples compile fine again but gmock has issues. I guess it's not really an issue for using Ceres, but longer-term it would probably be good to have tests running on Windows in C++20 mode.
image.png
Finally, just to complete this test parcour, it all compiles fine with -DCMAKE_CXX_STANDARD=14, which I think might be the default that CMake (or Ceres) chooses (otherwise I wouldn't have been able to run all the tests successfully last week).

If there's anything else you can think of that should be tested under Windows, I'd be happy to try. I won't be able to test CxSparse or SuiteSparse though, that's a configuration I currently don't use.

Best wishes,
Patrik


--
You received this message because you are subscribed to the Google Groups "Ceres Solver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceres-solver...@googlegroups.com.

Patrik Huber

unread,
Mar 19, 2022, 7:26:44 PM3/19/22
to ceres-...@googlegroups.com
(Also, I am really impressed that there wasn't a single compile error in Ceres itself or the examples, in any of the modes! That's really a bit of a miracle - or, really impressive work and testing by you guys, and also from the MSVC compiler, which by now looks to be impressively standard-compliant. Maybe one more thing I could test is compilation with /permissive- flag.)

Sameer Agarwal

unread,
Mar 19, 2022, 8:03:02 PM3/19/22
to ceres-...@googlegroups.com, Sergiu Deitsch
Thanks Patrik!
My replies are inline.


On Sat, Mar 19, 2022 at 4:21 PM Patrik Huber <patri...@gmail.com> wrote:
Hi Sameer,

Thank you for all your great work!

I've played around with manifolds and some AutoDiffCostFunctions over the past few days, and it all worked great so far under Windows with VS2022.

I've just very briefly tried compiling Ceres under a few different CMAKE_CXX_STANDARD modes, and a few things came up. 
It was all a bit in a rush, as I am leaving for a one-week seminar abroad - I might not have time to follow any of this up next week but I still quickly wanted to post it, and I can try my best next week to reply if needed.

First, one small observation: I noticed that there are no additional CMake targets when building with BUILD_BENCHMARKS=ON. Is that expected? (i.e. there seem to be no benchmark targets whatsoever)

Thats odd, it requires that the benchmark library be installed. Did you do that? if not then it will not enable any new targets. 
 

Next, I compiled with CMAKE_CXX_STANDARD=17, Ceres itself and the examples compiled fine, but some of the tests give the following compiler error:
image.png
I think one of them is internal/ceres/CMakeFiles/jet_test.dir/jet_test.cc.obj. Most of the tests do seem to compile without error.
I haven't actually run the tests that did compile as I ran out of time, but I can try to do that next week or the week after if it helps.

+Sergiu Deitsch added tests related to this, he also just fixed a bug related to this on ARM based macs. Perhaps he can say more.
 
I will be using the C++17 and C++20 modes going forward.

Next, with CMAKE_CXX_STANDARD=20, Ceres & examples compile fine again but gmock has issues. I guess it's not really an issue for using Ceres, but longer-term it would probably be good to have tests running on Windows in C++20 mode.
image.png

I suspect this is because the version of gtest that is currently shipping with ceres is a little outdated. It might be time to update it. I will take a look.
 
Finally, just to complete this test parcour, it all compiles fine with -DCMAKE_CXX_STANDARD=14, which I think might be the default that CMake (or Ceres) chooses 
(otherwise I wouldn't have been able to run all the tests successfully last week).

Yes, that is the default for ceres right now, though I suspect we will move to c++17 in the 2.2 timeframe.
 
If there's anything else you can think of that should be tested under Windows, I'd be happy to try. I won't be able to test CxSparse or SuiteSparse though, that's a configuration I currently don't use.

This is all very helpful! Thank you for the detailed feedback.
Sameer

 

Sameer Agarwal

unread,
Mar 19, 2022, 8:05:44 PM3/19/22
to ceres-...@googlegroups.com, Sergiu Deitsch
On Sat, Mar 19, 2022 at 4:26 PM Patrik Huber <patri...@gmail.com> wrote:
(Also, I am really impressed that there wasn't a single compile error in Ceres itself or the examples, in any of the modes! That's really a bit of a miracle - or, 
really impressive work and testing by you guys, and also from the MSVC compiler, which by now looks to be impressively standard-compliant. 
Maybe one more thing I could test is compilation with /permissive- flag.)

We use ceres at head at google, so that gives us an incentive to keep the code fairly clean and up to date. With regards to windows, a lot of the credit in this
release goes to +Sergiu Deitsch, who fixed a whole host of compatibility issues both at source as well as build level.

Yes please do test with more stringent flags and let us know how things go.

Sameer

 

Sergiu Deitsch

unread,
Mar 19, 2022, 9:17:54 PM3/19/22
to ceres-...@googlegroups.com
Patrik,

what /fp: mode did you use? The error message indicates that it was not /fp:precise which is the default.

Either way, it looks like we may need to temporarily override the floating-point mode to ensure the test compiles.

Sergiu Deitsch

unread,
Mar 20, 2022, 6:48:11 AM3/20/22
to ceres-...@googlegroups.com
Patrik,

You may have found a new issue in Visual Studio STL (there were few of those) which is related to its C++17 standard conformance mode. I posted the details here:

Luckily, it is straightforward to workaround the issue in Ceres.

On Sun, Mar 20, 2022 at 12:21 AM Patrik Huber <patri...@gmail.com> wrote:

Patrik Huber

unread,
Mar 27, 2022, 8:36:44 AM3/27/22
to ceres-...@googlegroups.com
Hi Sergiu (& Sameer),

I seem to be stumbling upon STL and MSVC bugs - not the first one... :-). It works now with your workaround from the latest Ceres head.

>> what /fp: mode did you use? The error message indicates that it was not /fp:precise which is the default.

That's an interesting one - I haven't changed any defaults or flags. I used "File -> Open -> CMake..." in VS2022, and then basically leave everything as-is in CMakeSettings.json in VS.
compile_commands.json tells me the following command-line is used for compilation (this is the Ceres head version already):

{
  "directory": "D:/ceres/ceres-solver/out/build/x64-Release",
  "command": "C:\\PROGRA~1\\MIB055~1\\2022\\COMMUN~1\\VC\\Tools\\MSVC\\1431~1.311\\bin\\Hostx64\\x64\\cl.exe  /nologo /TP -DGFLAGS_IS_A_DLL=1 -DGLOG_NO_ABBREVIATED_SEVERITIES -DGOOGLE_GLOG_DLL_DECL=__declspec(dllimport) -DGOOGLE_GLOG_DLL_DECL_FOR_UNITTESTS=__declspec(dllimport) -DNOMINMAX -D_USE_MATH_DEFINES -D_VARIADIC_MAX=10 -ID:\\ceres\\ceres-solver\\internal\\ceres -I\"C:\\Program Files\\NVIDIA GPU Computing Toolkit\\CUDA\\v11.1\\include\" -ID:\\ceres\\ceres-solver\\internal -ID:\\ceres\\ceres-solver\\include -ID:\\ceres\\ceres-solver\\out\\build\\x64-Release\\include -external:I D:\\vcpkg\\installed\\x64-windows\\include -external:I D:\\vcpkg\\installed\\x64-windows\\include\\eigen3 -external:W0 /DWIN32 /D_WINDOWS /W3 /GR /EHsc /MD /Zi /O2 /Ob1 /DNDEBUG /wd4018 /wd4267 /wd4099 /wd4996 /wd4800 /wd4244 /wd4251 /bigobj -std:c++17 /Fointernal\\ceres\\CMakeFiles\\jet_test.dir\\jet_test.cc.obj /FdTARGET_COMPILE_PDB /FS -c D:\\ceres\\ceres-solver\\internal\\ceres\\jet_test.cc",
  "file": "D:\\ceres\\ceres-solver\\internal\\ceres\\jet_test.cc"
},

There isn't any /fp: mode specified, so I would assume the compiler uses the default?


>> Thats odd, it requires that the benchmark library be installed. Did you do that? if not then it will not enable any new targets. 

Ah, that's indeed my mistake - no, I haven't. Sorry for not checking back with the docs on this one.

Thanks a lot for all the work on MSVC compatibility!

Best wishes,
Patrik


Reply all
Reply to author
Forward
0 new messages