지원 티켓 만들기
팔로우

Q100253 : Mari 성능 문제 해결

개요

대부분의 다른 소프트웨어 패키지와 마찬가지로 Mari은 성능이 저하 될 수 있습니다. 종종 이것은 그래픽 카드에 엄청난 크기의 프로젝트로 인해 과부하가 걸리는 것과 관련이 있지만 하드웨어를 변경하기 전에 사용자가 해결할 수있는 성능 저하의 원인과 이유가 있습니다. 이 기사에서는 이러한 사례 중 일부를 다루고 문제 해결 제안을 제공합니다.


증상 및 해결 방법

  1. 프로젝트에 여러 객체가 있습니다.
    Mari 는 하나의 객체에서만 작동하도록 최적화되어 있습니다. 가시성에 관계없이 프로젝트에 여러 객체가 있으면 성능이 저하 될 수 있습니다. 이러한 처벌은 장면에있는 물체의 양에 따라 증가합니다.

    팁 : 원본 모델링 패키지에서 alembic 또는 fbx 파일로 내보내기 전에 개체에 다른 재질을 지정하면 Mari은 해당 정보를 존중하고이를 사용하여 선택 세트를 만듭니다.

  2. 프로젝트에서 자원을 효율적으로 사용하지 않습니다.
    많은 레이어를 사용하여 작업하는 경우 "완성 된 레이어"를 캐시하는 것이 좋습니다.
    효율적인 방법으로 해상도와 비트 심도를 사용하고 있는지 확인하십시오. 8 비트 텍스처를 페인팅하는 경우 8 비트 페인트 버퍼를 사용할 수 있습니다. 그러나 페인트 버퍼와 가상 텍스처 아틀라스는 페인팅하는 레이어보다 낮은 비트 심도로 설정되지 않습니다.

    추가 성능 최적화 제안은 다음 문서에서 찾을 수 있습니다. Q100188 : 최상의 성능을위한 Mari 프로젝트 최적화

  3. 느린 뷰포트 탐색
    이것은 종종 GPU와 쉐이더 및 모델의 복잡성에 달려 있습니다. 보다 복잡한 쉐이더는 필연적으로 성능 저하를 가져옵니다. 이것은 또한 실제 변위와 그림자를 표시함으로써 크게 영향을받습니다.

    변위와 그림자를 비활성화하면 성능이 크게 향상됩니다.

    4k 모니터에서 작업하는 경우 Mari은 기존 HD 모니터보다 뷰포트에서 더 많은 픽셀을 렌더링해야합니다. 이 때문에 뷰포트의 렌더링 시간이 픽셀 수가 적은 모니터를 사용할 때보 다 빠르지 않을 수 있습니다. 뷰포트가 여러 모니터에 겹쳐있는 경우 GPU가 두 개의 디스플레이를 동시에 제공해야하므로 성능이 약간 떨어집니다.

  4. Mari 종종 Windows에서 멈 춥니 다.
    이것은 Windows 및 GPU 드라이버에서 설정 한 TDR 시간 (시간 감지 및 복구)과 관련이있을 수 있습니다. Mari이 GPU를 강렬하게 사용하기 때문에 일부 계산은 2 초 이상 지속될 수 있습니다 (기본 TDR 한도). 즉, Windows가 작업을 취소하고 GPU를 재설정하여 정지 상태가됩니다. 이 문제를 해결하려면 레지스트리의 TDR 시간 초과 값을 늘릴 수 있습니다.

    참고 : 레지스트리를 직접 편집하면 시스템이 시작될 수 없으며 운영 체제를 다시 설치해야하는 심각한 예기치 않은 결과가 발생할 수 있습니다. 파운드리는 시스템 레지스트리를 수정하여 시스템에 초래 된 어떠한 손상에 대해서도 책임을지지 않습니다.

    TDR 레지스트리 키에 대한 자세한 내용은 다음 Microsoft 문서 를 참조 하십시오.

  5. 텍스처 내보내기 속도가 느립니다.
    이것은 텍스처의 다양한 요소 (비트 수 및 해상도), 레이어 수 및 텍스처를 병합 한 경우 내보내는 패치의 양에 따라 달라집니다.

    많은 양의 UDIM이있는 프로젝트에서 작업하는 경우 마지막 반복 이후에 변경된 패치 만 내보내는 것이 좋습니다. 레이어 / 채널 / 패치가 변경되었는지 확인하려면 Mari 세션의 시작과 끝 부분에서 해시를 비교할 수 있습니다. 해시에 차이가있는 경우 레이어, 채널 또는 패치가 "더티 (dirty)"이며 다시 내보낼 수 있습니다.

  6. 느린 개폐 시간

    이미지 관리자가 수백 개의 참조 이미지로 채워지는 것은 일반적인 실수입니다. 각 이미지는 프로젝트 내에 저장되므로 결과물과 함께 저장해야합니다. 예기치 않게 프로젝트 저장 및 열기 시간이 느린 경우 이미지 관리자가 불필요하게 프로젝트 크기를 늘릴 수 있습니다. 실제 모델과 텍스처의 크기가 작을 때 큰 프로젝트 크기를 설명하기도합니다.

    팁 : 이미지 관리자에서 모든 이미지를 삭제하면 절차 노드가 다음에 열 때 사용하는 이미지가 자동으로 복원됩니다.

  7. 권장 파일 시스템

    Linux 사용자는 Mari이 프로젝트를 읽고 쓰는 방식에 더 적합하기 때문에 EXT3 또는 EXT4 파일 시스템을 사용하면 성능을 크게 향상시킬 수 있습니다.

    Mari 는 아카이브를 저장할 때 캐시 디렉토리에 많은 수의 작은 파일을 씁니다. 예를 들어 오래된 대장간 본문 예제와 같은 프로젝트에는 각각 10-90 kB의 75000 개의 파일이 있습니다. 내부 테스트 결과 EXT3이나 NTFS와 같은 파일 시스템이 많은 수의 작은 파일을 처리 할 때 최상의 성능을 제공한다는 사실을 알았습니다.

    비교해 보면 XFS 파일 시스템을 사용하여 동일한 성능을 보지 못했으며 사용자가 EXT (EXT3, EXT4 등)에 비해 다소 느리게 작동한다고보고했습니다. 이것이 Mari이 현재 XFS 파일 시스템을 사용할 때 경고를 표시하는 이유입니다.


    아직도 문제가 있습니까?

    이 문서에 설명 된 단계를 수행 한 후에도 여전히 문제가 발생하는 경우 지원 티켓을 열고 발생한 문제 및 지금까지 수행 한 문제 해결 단계를 알려주십시오. 조사해야 할 정보는 Q100090 : 마리 문제 신고 아래에 설명되어 있습니다.
    지원 티켓을 여는 방법에 대한 자세한 내용은 ' 지원 포털 사용 '문서를 참조하십시오.

도움이 되었습니까?
/

We're sorry to hear that!

Please tell us why.
7명 중 3명이 도움이 되었다고 했습니다.

댓글