Subscribe to this thread
Home - General / All posts - Bad (error?) effect during Make Image command
Berkers7 post(s)
#29-Jul-18 19:36

Hello,

When I try to Make Image of my composition (DEM + Drawings) I get effect like this.

Perhaps you know what causes that and how to come this over ?

I have Manifold 8.0.29.0, Win 7

Thank you,

R

Attachments:
Moab.jpg

tjhb

8,168 post(s)
#29-Jul-18 20:40

If you make repeated images of exactly the same extent, do you get exactly the same display corruption?

If you export the image, does it display crrectly on another computer?

Berkers7 post(s)
#29-Jul-18 20:55

It happens always when I want Make Image bigger than 10 000 x 10 000 pixels. Every time. And last couple of years. So I decided to ask :)

When I make for example 20 000 x 20 000 px image the left upper part is OK (clear), but all the rest is with this pattern. Is this some kind of limitation ?

Doesn't matter the comp is busy or not. 32 GB RAM.

No, when I export this captured image, it is also exported with this pattern error.

Berkers7 post(s)
#29-Jul-18 21:42

My impression was there were some memory problems, when the snapshot (Make Image) is too big.

My Windows is old (by this I mean it hasn't been re-installed 5 or 7 years). Partly because I have plenty of GIS program on it, partly od laziness, because why to change something what is working OK.

I have other laptops, but weak. Too weak for that job I think.

tjhb

8,168 post(s)
#29-Jul-18 22:12

Thanks. These probably seem like dumb questions (and might be).

Does the corruption happen on more than one machine?

Can you say what graphics card you have, and how much video RAM it has, and what graphics driver you have installed?

My initial thought was that the RAM on your graphics card might be faulty, or possibly system RAM.

If you get exactly the same result (pixel-for-pixel) when making the same screenshot multiple times in a sequence, then it is unlikely to be system RAM, more likely to be the graphics card (but still that's guessing).

I would definitely try a newer graphics driver if there is one. If not, an older one.

Berkers7 post(s)
#29-Jul-18 22:29

I can answer you on the graphics card now (don't be smiling about parameters ;)

NVIDIA GeForce GTX 560 SE, 1GB GDDR5

driver: NVIDIA 2017-10-27 23.21.13.8813

I haven't tested in on other machines, I admit. I have only this one big machine as a Working Horse. The others are weak, mostly for www and as terminals to that big one.

I will try to test it on other computer tomorrow. I hope I can push it on weak laptop.

Seriously I had no idea it could be the fault of graphics card.

tjhb

8,168 post(s)
#29-Jul-18 23:23

Nothing wrong with that graphics card at all. It's still a good card, Fermi generation, good enough for Manifold 9 (and Viewer) as well as Manifold 8. It does have only 1 GB of graphics RAM though...

Let's do some maths, and make some wild guesses about how things work.

You say you consistently see the corruption making an F6 image over 10000x10000 pixels.

First obvious point: that requires rendering a much larger image than your monitor can display at once.

But I assume that Manifold still asks the graphics driver, and probably the graphics card, to do the rendering--otherwise we would not consistently see a match between on-screen display and an F6 rendering. (I know, that is begging the question--you are not seeing a consistent match, but corruption. But let's come at that in another way below.)

How much memory is needed to render an image of this size? 10000x10000 pixels x 3 bytes (24 bit) RGB gives 2,400,000,000 bytes, divide by 1024^3, -> roughly 2.24 GB. So already, a 10000x10000 pixel image needs much more than 1 GB of graphics RAM, it won't all fit on the card. For 15000x15000 the requirement is about 5 GB, and for 20000x20000 about 9 GB.

So where does the extra RAM come from? It depends: it could be that image is rendered all in one pass, or it might be rendered in tiles which are then combined. I don't know which.

Let's say (really a guess) that Manifold simply asks the graphics driver to render an image of X x Y pixels, and leaves it up to the driver to find the memory to write output to. Let's guess again that the graphics driver first uses up any spare graphics RAM (in your case, 1 GB less whatever is already used for display), then spills to system RAM (up to 32 GB, less what is already used by Windows). And that the driver renders from top left to bottom right. Hopefully that's all at least plausible.

In your case, when rendering a large image, you consistently get clean output in the top left, corrupt display elsewhere.

So it could be (can't put it more strongly than that, even this is tenuous) that your video card and graphics RAM are absolutely fine, explaining why the first part of the image to be rendered is clean; but that you have one or more sticks of faulty system RAM, meaning that later parts to be rendered are corrupted.

So I would run a thorough test of all your system memory. The good thing is that it is very easy to test RAM, and replacement RAM is cheap. The bad thing is that if you have faulty RAM, it may have been compromising your data generally, not just image rendering.

I would recommend Passmark Burn-in-Test for testing RAM but there are other good options.

Berkers7 post(s)
#30-Jul-18 22:48

Good shot, tjhb

On other computer it is OK.

I would never expected that I have problems with RAM.

But they went through Passmark Burn-in-Test normal and tortures with no errors. Hmm...

Berkers7 post(s)
#30-Jul-18 22:51

Well, I can make this kind of snapshots on other computer. But this is strange kind of by-pass ;)

tjhb

8,168 post(s)
#30-Jul-18 23:57

Sounds like you have hammered your RAM and it has seemed to pass. What next?

I have previously had all RAM pass basic tests, until I used the Passmark option

BurnInTest Preferences > RAM > Ram mode and test pattern > Multi-process torture test

with 10 concurrent processes.

When that failed, it turned out that although the individual sticks of RAM had the same brand and model number, their chips were from different manufacturers, with slightly different default timings, and were incompatible under stress.

Or it could still be the graphics RAM. (I will look up a test utility and report back.)

Or even a faulty CPU. That's very very very rare. Hard to detect--and easy to assume it's impossible. I have had it happen once--but I only "know" that because, after testing different motherboards, RAM, and disks (so much time), the computer in question was stolen from my car, then no issue. Lucky thief.

adamw

8,037 post(s)
#01-Aug-18 16:53

It might be a different version of the driver / OS. (That is, the version of the driver on the machine that produces garbled images has a bug.)

Berkers7 post(s)
#08-Aug-18 20:50

No, I am sorry, but it is not the problem of NV drivers :) I got the most recent and the problem still exists.

But I wanted to thank you. You pointed me the problem, and I am actually happy. I can make this kind of snapshots on different machine, even if it is weak (even on weak laptop it is done quite quick. Surprise).

Perhaps it is a time to build a new, much powerful machine. I should have done it two or three years ago. But these RAM prices are discouraging me.

You know that subject.

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