직장에서 우리는 2K (2048 * 1556 픽셀) OpenEXR 필름 시퀀스를 재생하는 응용 프로그램을 보유하고 있습니다. 그것은 잘 작동합니다 .. 3GB (꽤 일반적인) 이상의 시퀀스가있을 때를 제외하고, 모든 머신이 8-16GB의 메모리를 가지고 있음에도 불구하고 메모리에서 오래된 프레임을 언로드해야합니다 (리눅스 BIGMEM을 통해 어드레싱 가능).32 비트 OS에서 3GB 이상의 비디오 프레임을 메모리에 저장
실시간으로 재생하려면 프레임을 메모리에 캐시해야합니다. 운영체제는 수년 전의 32 비트 Fedora Distro입니다 (가까운 장래에 64 비트로 업그레이드 할 수 없음). 프로세스 당 제한은 프로세스 당 3GB입니다.
기본적으로 메모리에 3GB 이상의 데이터를 캐시 할 수 있습니까? 나의 초기 아이디어는 여러 프로세스간에 데이터를 분산시키는 것이었지만, 이것이 가능한지 전혀 알 수 없었다.
RAM 드라이브를 생성하고 그 파일을로드하는 방법은 ... RAM 드라이브가 BIGMEM을 지원한다고 가정 할 때 당신을위한 물건.
여러 프로세스를 사용할 수 있습니다. 각 프로세스는 파일 공유보기를 공유 메모리 세그먼트로로드하고 플레이어 프로세스는 필요에 따라 세그먼트를 차례로 매핑합니다.
하나의 가능성은 mmap을 사용하는 것일 수 있습니다. 데이터의 다른 부분을 동일한 가상 메모리 영역에 매핑/매핑 해제 할 수 있습니다. 한 번에 하나의 세트 만 매핑 할 수 있지만 충분한 실제 메모리가있는 한 데이터는 상주해야합니다.
애플리케이션을 수정할 수 있다고 가정합니다. 그렇다면 가장 쉬운 방법은 응용 프로그램을 여러 번 시작 (각 3GB 청크마다 한 번씩)하고 각각에 비디오 덩어리를 저장하고 다른 프로그램을 사용하여 동기화하여 각각이 프레임 버퍼 (또는 다른 비디오 출력).
동기화가 다소 복잡해 지겠지만, 각 앱에 자체 프레임 버퍼가 있고 동기화 프로그램이 다음 앱으로 전환 할 때 비디오 컨트롤러를 올바른 프레임 버퍼로 가리키는 경우 단순화 할 수 있습니다.
내 흥미 무슨 문제 :
(편집 : ... 내가 문제의 모든 흥분 ...하지만 오, 난 그냥 롭의 램 드라이브 게시물을 읽을 조금 더가하는 제안하는 그래서 나는 ...
이가 가능할 것이다)RAM 디스크의 크기는 OS와 파일 시스템에 따라 다르기 때문에 모든 문제가있는 부분이 어디인지 추측 할 수 있습니다. 여러 개의 램 디스크를 만들어야하고 코드가 서로 번갈아 가야 할 수도 있습니다. 또는 여러 램 디스크에 RAID-0 스트라이프 세트를 설정할 수 있습니다. 또는 OS 제한 사항이 있고 몇 개의 그랜드 (4K?)를 삭제할 수 있다면 하드웨어 RAID-0 스트립 세트에 새롭고 빠른 솔리드 스테이트 드라이브를 설치하십시오. 또는 ...
재미 있고 재미있는 재미.
후속 조치를 따르십시오!
@dbr는 말했다 :
는 2K 파일을 쉽게 배열에서 직접 재생할 수 있습니다 터무니 파이버 채널 RAID 어레이와 리뷰 기계가있다. 문제는 아티스트 - 워크 스테이션에서 발생하므로 4000 달러짜리 RAID 어레이가 아닐 수도 있습니다.
글쎄, ~ 30GB의 제한을 수용 할 수 있다면, SSD 드라이브로 충분할까요? 그것들은 각각 제가 생각하기에 1 억 ~ 1 억 달러가 들며, 데이터 전송률로도 충분할 것입니다. 순수 RAM 방식보다 훨씬 저렴합니다. 더 작은 크기도 있습니다. ~ 60GB로 충분하다면 2 배의 비용으로 JBOD 어레이 2를 사용하지 않고 RAID 컨트롤러를 건너 뛸 수 있습니다. 하이 엔드 SSD 옵션 만 살펴보십시오. 로우 엔드는 영광스러운 메모리 스틱으로 채워집니다. : P
다중 프로세스 기술은 Adobe Premiere CS4에서 64 비트로 이동하기 전에 사용되었습니다. –