Subscribe to this thread
Home - Cutting Edge / All posts - Manifold System 9.0.170.3
adamw


8,882 post(s)
#13-Jan-20 15:51

9.0.170.3

Here is a new build.

manifold-9.0.170.3-x64.zip

SHA256: 1f99e5e5d8bfd9b59af8e6147f42cba5b6cf016fde49cd4b5662dd21cf7e8a8b

manifold-viewer-9.0.170.3-x64.zip

SHA256: d8e10d4e0933b907043f0055430f8ed41a38c2cde8b8b245504e0949479326ef

adamw


8,882 post(s)
#13-Jan-20 15:53

Components

All build components have been updated to newest versions available.

We switched to a new version of the MSVC compiler and did the usual dance with the numerous optimization choices. We see slight general increases in performance with some places benefiting more than others, but most importantly, no regressions.

GPGPU code is recompiled using CUDA 10.2. With the next version of CUDA we might no longer be able to support devices of compute capability 3.0 (Kepler), depending on whether NVIDIA will still support them.

ECW code is updated to use the newest ECW modules, fixing a couple of minor bugs during reads.

MRSID code is updated to use the newest MRSID modules, fixing a couple of minor bugs as well.

V8 is updated to the newest version used by Chrome, providing noticeable savings in the amounts of used memory (very welcome as scripting engines used by browsers are historically way too aggressive on that front).

Analysis

Renamed transforms: Closest Euclidean, Xxx -> Closest Euclidean Xxx.

Renamed transforms: Closest Path, Xxx -> Closest Path Xxx, renamed parameter: Use equal weights -> Use equal costs.

(Fix) Closest Path transforms treat zero costs as invalid (can be thought of as infinite). (Negative costs already were invalid.)

(Fix) Tile distance / viewshed / watershed computations correctly handle images with YX coordinate systems.

TileDistanceMake / Par query functions are split by distance type. The new TileDistanceMakeWeighted / Par functions create a distance object for path distances. The remaining TileDistanceMake / Par functions create a distance object for Euclidean distances.

New transforms: Closest Slope Path Distance / Length / Source - compute path distance generating costs from raster slopes. Parameters: Min slope / Max slope - control minimum and maximum value for the allowed slopes, slopes equal or lower than minimum or equal or higher than maximum are considered to be untraversable. Min cost / Flat cost / Max cost - specify costs for minimum slope, zero or flat slope, maximum slope. The defaults for Min slope / Max slope are -90 / 90 (note that neither value is reachable). The defaults for Min cost / Flat cost / Max cost are 0 / 1 / 2.

New query functions: TileDistanceMakeSlope / Par - power the Closest Slope Path transforms.

UI

Transform templates for tile fields in tables (operating on table window) automatically determine the number of channels in tile values from metadata and filter available transforms accordingly. (As a side effect, this gets rid of the double Limit Xxx transforms for tile fields, leaving only the versions of those transforms that operate on pixel values, not on whole tile values taken as binary data.)

Editing component names in the Rename Related dialog is smarter at finding and adjusting similar names (numeric postfixes are ignored so that 'Mexico 2' and 'Mexico Table 2' get renamed together, etc).

The map window allows switching out of cursor modes for inserting new geometry on Alt-click (pick) or Ctrl-click (select) if there is no current geometry being edited - eg, right after adding an object.

Circle and ellipse arcs are rendered more accurately. (We first made several adjustments to the linearization code which made it 4x more economic at small curves, and then increased the maximum number of intermediate coordinates allowed per curve segment accordingly - the result is smoother curves with no cost to rendering. The improvement applies to exports and transforms as well.)

(Fix) The map window no longer fails to show the snap reticule for the tracker tool when it is just starting its line. (The snap was working, but the reticule was not showing.)

The Delete Related / Rename Related dialogs select the clicked component on startup. (The Show Related dialog was already doing that.)

Turning off background for a map in the Layers pane preserves the background color. (Previously, turning off background was resetting its color to black.)

The map window allows unselecting all data in all layers (including hidden ones) using the new Edit - Select None Map command.

The Layers pane allows right-clicking a map layer and making it active using the new Active command in the context menu. Making the layer active from the Layers pane will both switch the active tab in the map window and switch the active component within that tab if the tab hosts a group of layers. If the layer is already active, the Active command will show this using an icon.

The Layers pane allows right-clicking a layout frame and making it active. The frame has to be visible.

The Layers pane allows right-clicking a table field and making it active. The field has to be visible.

Alt-clicking the name of a map layer / layout frame / table field in the Layers pane makes it active in the window.

The table window allows right-clicking a field header and showing the field in the Layers pane using the Show in Layers command.

The table window allows right-clicking a field header and sorting records using values in that field using the new Order Ascending / Order Descending commands. If the current order is already based on the clicked field, the commands will indicate that using icons. (If the current order is based on multiple fields, neither of the icons will be 'pushed in', because invoking the relevant command will alter the order and make it based on the clicked field alone.)

The table window no longer shows the Use as Identity command for binary fields. (It was doing nothing, binary fields cannot be used as identity.)

The table window allows right-clicking a field header and resizing the field to fit its values using the Best Fit / Best Fit Title commands. (We used to have these commands earlier, we took them off in part because of changes to the internals of the table window. Now they are back, adjusted to behave well.) Using Best Fit commands on binary fields does not retrieve field values and instead uses width that is wide enough to fit most reasonable values of the relevant type.

The New Map dialog is reworked to always display a list of components in the data source that the map is going to be created in. The toolbar above the list of components includes a button that switches between showing all available components and only those components that have been picked for the map. If the dialog is started on a single component, it starts in the mode that shows all available components, and the context component is picked for the map. If the dialog is started on multiple components, it starts in the mode that shows only the components picked for the map and with the context components all picked.

Data

Exporting labels to DXF writes text height tag to make exported files readable in various versions of AutoCAD.

(Fix) Reading an NTF NITF file with embedded JPEG2000 no longer fails with an error. (JPEG2000 data currently remains inaccessible - we are working on reading it seamlessly - but at least there is no error.)

Reading ECW reads 16-bit values in raw format. (Previously, these values were mapped to 8-bit RGB.)

Reading ECW supports multi-channel images (ECW v3).

End of list.

Tentative plans for the next build are to add support for legends.

tjhb
9,095 post(s)
#18-Jan-20 02:23

GPGPU code is recompiled using CUDA 10.2. With the next version of CUDA we might no longer be able to support devices of compute capability 3.0 (Kepler), depending on whether NVIDIA will still support them.

If the next version of CUDA will no longer support any version of Kepler (neither 3.0 nor 3.5), I hope that Manifold might issue a new public release of 9 (perhaps even using 10.1) before permanently reducing compatibility.

That would preserve our investments (and reduce landfill).

For example I have a faithful, acceptably-fast HP laptop that may need to remain on Manifold 9.0.170.0 indefinitely, because its Quadro card has no drivers that support CUDA beyond version 10.1.

My massive Kepler Titan card does have CUDA 10.2 driver support, but maybe that will be it.

That would be a real bummer. I will test with 170.3 and report.

adamw


8,882 post(s)
#18-Jan-20 07:22

We will issue a new public build before that for sure.

In general, even if NVIDIA soon issue a new version of CUDA that will no longer support Kepler devices, we can continue to stay with the current version of CUDA that does support them for some time. If the rate at which NVIDIA deprecates support for devices ever becomes a pressing issue (it has been pretty accommodating so far, but if it ever gets too fast), we can extend our code so that it can both get the benefits from the latest version of CUDA if it is available and fallback to a lower version of CUDA otherwise. This is some extra work, but it is doable.

tjhb
9,095 post(s)
#18-Jan-20 19:56

Thanks Adam, that’s fantastic.

tjhb
9,095 post(s)
#21-Jan-20 03:49

Above I said I would test GPGPU availability with 170.3 and report.

This is using an HP ZBook with a Quadro K1100M GPU (Kepler, CC 3.0). This has NVIDIA drivers up to version 426.32 (R418) released 19 November 2019, supporting CUDA 10.1.

CUDA 10.2 support requires an NVIDIA driver version >= 441.22 (R440) as per the CUDA Toolkit release notes. If a card does not have such a recent NVIDIA driver, we would not expect GPGPU to fire under CUDA 10.2.

With Manifold 9.0.170.2 (built against CUDA 10.1) I get full GPU utilization.

With Manifold 9.0.170.3 (CUDA 10.2) I get no GPU utilization on this GPU, as expected.

My GeForce Titan card (Kepler, CC 3.5) (and jsperr's two of the same cards) does have an R440 driver, so GPU will continue to be utilized with 9.0.170.3. Same with a GeForce 1060 (Pascal, CC 6.1) on another machine. I will report back if either of those expectations is wrong.

tjhb
9,095 post(s)
#21-Jan-20 06:20

Will some older Kepler cards (mostly CC 3.0) perhaps get R440 drivers over the coming weeks? It seems possible.

The CUDA 10.2 release notes say that CC 3.0 cards will not be supported by future CUDA Toolkit releases, with the implication that they are still supported (or at least not already unsupported) in the current release. So perhaps there will be new drivers soon.

I can't find a clear steer on that from Nvidia.

jsperr72 post(s)
#01-Feb-20 23:46

With Manifold 9.0.170.2 (built against CUDA 10.1) I get full GPU utilization.

With Manifold 9.0.170.3 (CUDA 10.2) I get no GPU utilization on this GPU, as expected.

I ran the same experiment on the North Island classifying project with the same results and then installed CUDA 10.2 and the NVIDIA 441.87 Windows 10 Driver for my GeFprce GTX TITAN.

10.2 is about 5% faster than 10.1 (95 seconds vs 101 seconds) and both 9.0.170.2 and 9.0.170.3 ran with near identical speed under the new 10.2 installation.

I'm still looking for a utility that sets or verifies the GPU card is favored to doing 64 bit floating Point operation as my old driver allowed.

drtees90 post(s)
#21-Jan-20 16:46

A few years back, I ordered up a new computer with an nVidia Quadro K620 graphics card in anticipation that Manifold 9 would be coming out. I wanted a machine that had serious CUDA potential since most of the talk about the upcoming M9 was how it would leverage the GPU for faster performance. I never thought that the card might not be supported by future versions of CUDA or that M9 might not utilize its GPUs due to its age.

The Quadro K620 utilizes the Maxwell architecture. I have searched the net to see if this card supports the latest versions of CUDA, but without success. I am assuming at the moment that it does since Maxwell is supposed to be a successor version to Kepler. How much longer can I expect the Quadro K620 to be supported? Does it even make sense to replace it since it appears that multi-core CPUs provide more processing potential compared to multi-core GPUs.

tjhb
9,095 post(s)
#21-Jan-20 23:10

I have searched the net to see if this card supports the latest versions of CUDA, but without success. I am assuming at the moment that it does since Maxwell is supposed to be a successor version to Kepler.

That's right, the Quadro K620 is fully supported for CUDA 10.2.

You can see this by going to the Nvidia drivers page and searching on Quadro > Quadro Series > Quadro K620...

The most recent driver for Windows 10 is version 441.66 (release 440 update 4), which is later than the 441.22 required to support CUDA 10.2 (as noted above).

Provided you install that driver, you will continue to have CUDA GPU support under Manifold 9.0.170.3 and beyond. If you use a driver older than release 440, then you won't.

As you say, this is a Maxwell card (despite the unhelpful K prefix in its name). There is no suggestion of CUDA support for Maxwell cards being deprecated yet or soon.

drtees90 post(s)
#21-Jan-20 23:46

Thank you! I was obviously not searching using the correct questions. I was on nVidia's web site, but didn't see anything that would indicate what level of CUDA the card supported. That, and my grasp of what goes on with an operating system began to wane in by Windows 95! To use a phrase my computer sciences professor used in my first programming class (1979), "you don't and you don't need to know." He was talking about how memory is allocated when setting up variables in BASIC, but it works with how the operating system functions.

jsperr72 post(s)
#19-Jan-20 17:39

I'm in the same boat -- it seems like it was just a year ago that I had to upgrade my GPGPU's to Kepler.

I don't have a huge budget so I purchased a pair of used GK-110 based cards based on their capability to configure 1/3 of the cores for Floating Point 64 operations. I had some driver issues and hardware mounting challenges but finally got everything working well.

Despite it's age and realizing I may be nearing the limits of how far I can extend the platform, I'm really happy with the Manifold 9 performance of my low budget Lenovo D-20 ThinkStation.

tjhb
9,095 post(s)
#19-Jan-20 20:01

Two! Yay.

Mike Pelletier


1,684 post(s)
#20-Jan-20 01:43

Make that 3. I also have a wonderful HP laptop with a Kepler :-)

oeaulong

237 post(s)
#27-Jan-20 18:47

I am stalled in the 10.1 eddy as well. New Machine with no budget? I will have to say goodbye to Mfd soon.

tjhb
9,095 post(s)
#27-Jan-20 21:02

Nicely put, but I thought Adam’s responses were very encouraging.

Don’t do anything drastic!

dchall8
685 post(s)
#19-Jan-20 18:21

I had to run and check my GPU. I just bought a Geforce GT 730, not the newest technology card and not massive, but my computer is 6 years old. Apparently "early models of the GT 730 were Kepler." I could not find the answer with a Belarc scan, so I dug the box out of my box repository. This is exactly why I save boxes. The box says GeForce GT 730 Fermi, so I should be good until I modernize all my hardware.

tjhb
9,095 post(s)
#19-Jan-20 19:58

Unfortunately not. Support for Fermi (the generation before Kepler) was dropped in 9.0.169.1.

GPGPU code requires CUDA devices of compute capability 3.0+ (Kepler or higher, cards with Kepler started appearing in 2012). All GPGPU modules have been adjusted to use Kepler features.

dchall8
685 post(s)
#21-Jan-20 06:52

I missed that. Guess I need to go shopping.

adamw


8,882 post(s)
#20-Jan-20 10:38

Tim is correct. :-(

In the list of GPUs on NVIDIA:

https://developer.nvidia.com/cuda-gpus

...GeForce 730 has two entries:

GeForce GT 730 - compute capability 3.5

GeForce GT 730 DDR3, 128bit - compute capability 2.1

If your card is in the first entry, it's Kepler and we currently both render through it and can use it in analysis. If it is in the second entry, it's Fermi and we only render through it.

I guess the replies in this thread make a case for putting effort into supporting older GPGPUs longer than the rate with which they get deprecated by NVIDIA (wrt CUDA).

tjhb
9,095 post(s)
#21-Jan-20 00:30

I guess the replies in this thread make a case for putting effort into supporting older GPGPUs longer than the rate with which they get deprecated by NVIDIA (wrt CUDA).

It seems also worth bearing in mind that driver support also dies out for old cards.

Since April 2018, Geforce drivers with new features have only been published for Kepler cards and later. Drivers with critical security updates were maintained for Fermi a bit longer, until January 2019 (in theory).

For example, the last driver for the Geforce 560 Ti (a Fermi card) was version 391.35 (R390 supporting CUDA 9.1), dated 27 March 2018.

Perhaps a case could be made for dropping support for an Nvidia card or generation (or at least, not investing extra work) at the point when Nvidia stops publishing new drivers for it (not even security updates).

adamw


8,882 post(s)
#21-Jan-20 11:18

Yes, that's also a factor.

I have to say, we don't really like being currently partly forced on this deprecation train. We'd like to have more control over what gets deprecated and when. In that vein, we'll likely invest into adjusting our code to work with whatever NVIDIA driver / CUDA version is installed. That would likely mean shipping different GPGPU modules for different compute architectures, but that's not a big price to pay for making sure that if a card + driver worked in 9 as GPGPU once, they will continue working as GPGPU until we, 9, have an actual internal architectural reason to stop supporting them (which will probably be a very rare event).

HMS39 post(s)
#21-Jan-20 14:10

That would be great. Mostly of my daily operations run through a workstation still running with a Quadro (Fermi) card. It'd be great if I could take advantage of all the 9 capacities without having to go through a massive upgrade.

adamw


8,882 post(s)
#22-Jan-20 13:55

Status update:

We are planning to issue the next build early next week. The main focus is the first iteration of legends.

adamw


8,882 post(s)
#30-Jan-20 08:56

A follow-up:

We are running late, working on the various small issues related to legends and layouts. We should be done in a few days.

In the meantime, we added a couple of the quality-of-life UI features in unrelated areas.

Also: not in this build, but we will multi-target GPGPUs, and as part of that we will restore CUDA on Fermi cards. So, don't throw your older GPGPUs just yet, they will continue to serve you well.

HMS39 post(s)
#30-Jan-20 12:45

Two great news Adam!

Manifold User Community Use Agreement Copyright (C) 2007-2019 Manifold Software Limited. All rights reserved.