Performance issues...random

[SHCanada2]

I've noticed the undo and other things(today I right clicked on a PBR camera in th project browser) sometimes takes a very long time(> 1 min) to complete (of course the object browser has a preview so perhaps that is why it takes so long, but why longer than opening up the camera in its own tab?). Today I added a revision to layout and then I clicked the undo. CA sat there spinning for a minute or so, and the kicker is the GPU is going crazy in task manager with CA occupying it. I have 5 "update on demand" PBR layout boxes in my layout . Anyone else seeing this? and if so, do you have layout boxes with PBR (i.e. not images)?

 

Its not repeatable on demand. Its like something is triggering the PBR, but even if it was, the :"sitting there spinning" is lasting a lot longer than the PBR actually takes to complete when the PBR is open.

 

.....maybe all 5 are bing updated periodically even though nothing was changed that affected them ....

 

intreresting that the GPU memory is also pinned. I haven't noticed that before.

 

 

 

[SHCanada2]

yup something to do with the layout. once I close it, the memory is released and GPU drops to 0

 

[Smn842]

I've had the GPU issue with layouts and several PBRs and first reported that to support almost 18 months ago. For layouts with many PBRs it can exhaust VRAM and freeze the PC until Chief eventually crashes.  For fewer PBRs there can be delays and high VRAM use.

 

I didn't get very far with support as once they knew I have two GPUs they said that wasn't a supported configuration.  However the problem still occurs even with one GPU so that's not the cause. It appears Chief is holding onto video resources when updating multiple PBRs for layout rendering and it gets even worse if printing it to PDF.

 

I now just avoid a layouts with too many PBRs.

[VHampton]

Suggestion...

 

• Keep the PBR viewport out of the layout sheet's borders. 
• Save the viewport off to the side as a way to gain quick access to the camera which is set to update manually. 

 

Never have cameras set to refresh automatically. 

 

• Send whatever that camera view is to Layout as an image. 

 

PBR's watercolors, active cameras, and even line drawing cameras become a fairly large memory request even with the most robust hardware when they live on a layout page.  Secondly, even static camera views (on a layout page) can turn a PDF in an astronomical size when going to print. 

 

On CA's sample projects. there's not an active camera in layout ever. All image files. 

In sum, image files only in layout will shut this bad behavior down quickly.

 

Hope this helps. 

[SHCanada2]

I thought the whole point of update on demand is so it does nothing on the PBR, until I ask it to update (or it prints). 

 

seems odd

 

I'll send it in

 

thanks

[VHampton]

PBR is a memory hog in general. Tech support will confirm. 

 

Maybe save that camera in plan - and send to layout as necessary - but again - only as an image file. 

[Chopsaw]

11 minutes ago, SHCanada2 said:

I thought the whole point of update on demand is so it does nothing on the PBR, until I ask it to update (or it prints). 

 

seems odd

 

I'll send it in

 

I had the same sort of thing going on with just two live views in layout and tech support suggested cutting my sample count down to 20. 

[SHCanada2]

I can try the sample size cut down.

 

I personnally hate the continual sending of images.

 

Ultimately, I would just like to know why it doesn't seem to obey the "update on demand" and if there is a way to make it only update when I tell it to.

 

[Kbird1]

It's been an Issue Forever, so I work the same way as VHampton and have Saved Layout Cameras in the Project Browser

I just reopen and Resend as Images when needed after Revisions for example..... and at the Final Review Stage.

 

I do wish there was a default for the Sent Image Size though , to save a bit of Work.

 

M.

[Chopsaw]

19 minutes ago, SHCanada2 said:

Ultimately, I would just like to know why it doesn't seem to obey the "update on demand" and if there is a way to make it only update when I tell it to.

 

I think the manual update option is the key thing.  People don't mind waiting for good things. 

[SHCanada2]

i may be imagining things, but it seems like this got worse after the last update a couple months ago.

 

So I just printed to pdf my layout, and tried to close the layout without saving and the GPU is going crazy for like a minute and a half, before the layout would finally close

 

we will see what they say

 

[Kbird1]

13 minutes ago, SHCanada2 said:

but it seems like this got worse after the last update a couple months ago.

 

I have not looked into it yet but am wondering if Microsoft has added another CPU Mitigation during one of it's Updates recently as things seem "Laggyier" in general now.

 

M. 

[SHCanada2]

yeah its something weird, if you look at the GPU processor it is up and down like a yo yo

 

[Kbird1]

22 minutes ago, Kbird1 said:

Microsoft has added another CPU Mitigation during one of it's Updates recently

 

It seems M$ did add another CPU Mitigation Last Month for a vulnerability called Downfall......

 

Downfall is a new CPU vulnerability affecting all modern Intel CPUs before its 12th Gen Alder Lake CPUs. 11th Gen Rocket Lake, 10th Gen Comet Lake, 9th Gen Coffee Lake Refresh, 8th Gen Coffee Lake, and 7th Gen Kaby Lake CPUs are all affected. The exploit takes advantage of a new transient execution attack, GDS or Gath Data Sampling, that enables attackers to steal sensitive information from a system's most secure environments, including the user kernel, processes, virtual machines, and trusted execution environments

 

Security Researcher's Webpage on Downfall

https://downfall.page/

and

https://www.tomshardware.com/news/intel-downfall-vulnerability

and

https://www.tomshardware.com/news/microsoft-offers-instructions-to-disable-downfall-mitigations-on-windows

( *** a comment in this article says the disabling code provided is not correct)

 

M.

[SHCanada2]

a bit of an update: The problem where the GPU memory stays pinned at ~ my max of 8GB, is repeatable. Occurs after printing to PDF on a layout I have which has 8 PBR views on it

 

if I close the layout the GPU memory drops to zero.

 

Support is looking into it

 

[VHampton]

Observation... Live camera views on layout take forever to print. PBR's in particular. 

 

The original post says that you've got PBR cameras on the layout page. 

 

What happens when they (the live cameras) get sent to layout as an image file. 

 

Meaning keep all live camera views out of the bounds of the layout borders. 

 

The print process should be an entirely different experience. 

[SHCanada2]

1 hour ago, VHampton said:

What happens when they (the live cameras) get sent to layout as an image file. 

 

5 seconds to print, but it also takes  the following time to "manage" the image files:

1. open each from layout: 2s
2. Render the 300 samples: 6 seconds
3. Export image to file at 1800 pixels per inch: 1 second

 

That doesnt include sending it to layout, it assumes the "export to the same filename" method (I don't remember who said they do this, in order to not have to resize the image all the time)

multiple that by 8=72

so 1min 17 seconds total

 

it takes ~2 min to print the layout with the PBR layout boxes ...the first time. any subsequent times because the memory is pinned now takes a long time, PBR camera are also down to 1 sample/s, from what I normally get which is ~40 sample per second. If I close the layout and reopen, everything is fine. CA is now aware of this issue, and I would assume they will correct it.

 

So yes I could uses images, but seems like an awful lot of click click, rinse repeat.

 

if the memory issues was sorted out, and released, then I would be taking a ~45 second hit when printing compared to managing the image files. In my view, something that is done repetitively manually should not be quicker than doing it automatically. If the automatically (PBR layout boxes) is markedly slower, perhaps then CA should look at creating image files for the PBR box when printing PBR boxes. 

 

In my view, looking ahead into the future, there will be more and more PBR used and it would be worthwhile for CA to make the printing of the PBR as efficient as possible.

 

For me, once I setup the PBR cameras, I dont really look at them, I'll work on the plan's little details using the elevations, floor view, or external non pbr camera , and then I just print the layout. I really dont want to constantly think to myself, "did I do something that affects the PBR camera and now I have to export the image?"

 

I just want to print to pdf

 

 

 

 

 

 

[VHampton]

Gotcha... and I agree. There are indeed steps involved. 

 

However... no matter how much memory one's set-up may involve, a PDF using live cameras can easily reach well over 30 to 50 MB depending on what the PDF is formatted to. Even an Active Camera view can increase the size of a PDF to the point where it can't even be emailed. 

 

In terms of the PIA in having to always resend images, that kind of comes with the territory to some degree. It helps keep the PDF size down for starters. 

 

Anyway, good luck with the tech support. Their findings may be pretty much the same. None of their sample plans even dating back to the earliest X versions has ever had a live camera in layout. That's primarily due to the memory issue which you're experiencing, and the increase to a PDF file. 

 

Printing multiple views of live PBR cameras can lock up almost any computer even w/ 64 GB of memory and over 16GB on the graphics card. 

 

 

[SHCanada2]

1 hour ago, VHampton said:

However... no matter how much memory one's set-up may involve, a PDF using live cameras can easily reach well over 30 to 50 MB depending on what the PDF is formatted

well, I've been doing some testing over the last year. I used to always print to ARCH D but that took forever. So I changed to tabloid. I've tried different DPIs.

 

Today I print at 300 DPI, 11x17, 29 pages with 8 PBRs is 5MB file size. Elevations are plot line.

 

The most I ever see is around 15MB PDF file size. Not sure what I am doing different if you are getting 30-50MB PDF files

[VHampton]

 

 That's actually not so bad.

 

BTW... I do the same.  Meaning set aside a rendering set on 11 x 17 for the views and leave the projects set on larger format. Presumably the PBR views use up every bit of the Tabloid paper size (less the borders and title block).  Again 5 MB and 15MB total is excellent. 

 

BTW... I rarely get those numbers anymore because the camera views are static vs active. 

 

A typical set can get into the 50 plus sheet range after it includes structurals, mechanicals, electrical, schedules, and interiors. Throw in a PBR view, or live camera, and a full set can reach the 30MB range no problem.

 

Pattern files are also known to skew the size. Over the years for example, I've learned never to use a "sand" fill for stucco. That can send the PDF print into some really wild numbers. 

 

 Anyway... it sounds like the printing issue might be resolved?  Hopefully tech support can help. Those folks are great.