GPU에서 룩업 테이블을 사용할 때 최적의 메모리 액세스?

학사 프로젝트를 위해 GPU에서 isosurface 알고리즘을 탐색하고 있습니다 (특히 실제 필드가 아닌 이진 입 / 출력 복셀 데이터에만 집중). 그래서 OpenFrameworks에서 좋은 오래된 행진 큐브를 실행하고 CPU를 GLSL 컴퓨팅 쉐이더로 포팅하려고 시도하고 다이빙 전에 함정을 고려하는 단계에 CPU 구현이 있습니다. 전에는 모두 나에게 새로운 것입니다.

첫 번째 문제는 작업 그룹에서 수십 또는 수백 개의 스레드에서 효율적으로 조회 테이블을 사용하는 방법입니다. GPU는 작업마다 다른 종류의 메모리를 가지고 있지만 각 작동 방식이나 사용할 유형을 완전히 확신하지 못한다는 것을 알고 있습니다.

Paul Bourke의 클래식 copypasta 테이블은 256 * 16 배열이므로 스칼라 바이트 유형을 사용하는 경우 4kb 텍스처 또는 SSBO로 압축 될 수 있습니다.

문제는 다른 스레드가 서로 넘어지지 않도록하는 방법입니다. 각 작업 그룹의 많은 큐브는 동일한 구성을 가질 수 있으므로 동시에 버퍼의 동일한 위치에 액세스하려고합니다. 이 문제를 해결하기위한 해결 방법이나 최적화가 있습니까?

— 러스
소스

읽기 전용 조회 테이블 인 경우 버퍼 / 텍스처 만 사용할 수 있습니다. 일반 텍스처 형식 중 하나로 포장하거나 DX11 / OpenGL의 새로운 기능 중 일부를 사용하여 사용자 정의 형식을 가질 수 있습니다. DX11 랜드의 UAV 또는 OpenGL 랜드의 텍스처 / shader_image_load_store

— RichieSams

또한이 프리젠 테이션을 살펴보십시오. cvg.ethz.ch/teaching/2011spring/gpgpu/cuda_memory.pdf CUDA를위한 것이지만 기본 하드웨어에서 무슨 일이 일어나고 있는지에 대한 더 나은 아이디어를 제공해야합니다

— RichieSams

완전한 대답은 아니지만 캐시에 적합하고 캐시 누락이 적을수록 메모리 사용량이 적을수록 좋습니다. 곡선의 점을 텍스처로 베이킹하는 것처럼 보간 가능한 값이있는 경우 메모리가 적은 고품질 곡선 조회 테이블을 얻는 방법으로이를 확인할 수 있습니다. blog.demofox.org/2016/02/22/…

— Alan Wolfe

GPU 컴퓨팅 셰이더를위한 룩업 테이블을 배치하는 가장 좋은 장소는 룩업 테이블의 크기와 액세스 빈도 / 일관성에 따라 다릅니다. 귀하의 경우 (4kb 언급) 공유 로컬 메모리가 가장 좋습니다 (같은 커널에서 다른 목적 으로이 메모리가 필요하지 않다고 가정). 이 메모리는 API마다 이름이 다르지만 아키텍처는 동일하며 동일한 성능 지침을 따릅니다.

CUDA : 스레드 그룹 공유 메모리
DirectCompute : 그룹 공유 메모리
OpenCL : 로컬 메모리
금속 : 스레드 그룹 메모리
OpenGL : 공유 메모리

조회 테이블을 전역 메모리에 읽기 전용 버퍼로 저장하면 실행중인 특정 GPU의 캐시 크기에 따라 성능도 향상 될 수 있습니다.

나는 이것이 읽기 전용 조회 테이블이라고 가정합니다. 읽기-쓰기 룩업 테이블은 완전히 다른 짐승이며, 거기에는 좋은 옵션이 없습니다.

— 그로버 만하임
소스

읽기 전용 버퍼가 공유 로컬 메모리에 4kb의 읽기 전용 데이터를 저장하는 것보다 더 나은 경우도 있습니다. 예를 들어, 로컬 메모리에 저장하면 모든 스레드 그룹에 대해 고유 한 데이터 사본이 있음을 의미 할 수 있습니다. 버퍼가 캐시에 맞으면 캐시가 읽기 전용 액세스 패턴에 대해 로컬 메모리보다 성능이 우수 할 수 있습니다.

— John Calsbeek

의견을 보내 주셔서 감사합니다. 나는 지금이 사용하던 프로젝트를 완료, 그냥 읽기 전용 : 꽤 잘 작동 질감, A 완충액 r8ui를 사용하여 상처 한

— 러스