배열 구조체 또는 배열 구조 성능

Question

저는 MacMini '11을 AMD Radeon HD 6630M과 함께 사용하고 있습니다. 배열의 구조를 사용하여 메쉬를 그리는 중입니다. 60 fps (CVDisplayLink 사용)입니다. 내장 속성이있는 쉐이더를 사용합니다. 인생은 좋습니다. "현대"GPU에서 선호되는 것으로 알고 있기 때문에 구조체 배열 (인터리브)을 사용하도록 전환합니다. 속성은 셰이더에서 정의됩니다. 메쉬가 아름답게 그려집니다. 그러나 이렇게하면 프레임 속도가 약 33 % (40fps까지) 떨어집니다. 그리고 그 전화의 사본이 여러 개 있습니다. 사용 악기는 :

Using structure of arrays (60 fps) 
Running Time Self Symbol Name 
3.0ms 0.0% 3.0 0x21b76c4   ATIRadeonX3000GLDriver 
2.0ms 0.0% 0.0 gldUpdateDispatch ATIRadeonX3000GLDriver 
2.0ms 0.0% 0.0 gleDoDrawDispatchCore  GLEngine 
2.0ms 0.0% 0.0  glDrawElements_ACC_Exec GLEngine 
2.0ms 0.0% 0.0  glDrawElements  libGL.dylib 
2.0ms 0.0% 0.0  -[Mesh draw]  me 

Using array of structures (40 fps) 
Running Time Self  Symbol Name 
393.0ms 7.4% 393.0 0x86f6695    ? 
393.0ms 7.4% 0.0 gleDrawArraysOrElements_ExecCore GLEngine 
393.0ms 7.4% 0.0 glDrawElements_IMM_Exec  GLEngine 
393.0ms 7.4% 0.0  glDrawElements   libGL.dylib 
393.0ms 7.4% 0.0  -[Mesh draw]   me 

libGL가 서로 다른 방향으로 갈 결정을하고있다처럼 보이는, 그리고 구조의 배열이라고 점점되지 않습니다 X3000 드라이버처럼 보인다 : 시간 프로파일, 나는 다음과 같은 비교를 얻을. Apple 소프트웨어 에뮬레이터에서 실행됩니까? 배열 구조 만 유지해야합니까? 이걸 본 사람 있어요?

---

속성에 대한 코드는 애플의 예에서이며, 그 지역에서 어떠한 성능 저하가 내 응용 프로그램 (최소 10 개 다른 지역) 전반에 걸쳐 사용된다. 이것은 느린 버전에서입니다. 앞서 언급했듯이 데이터가 인터리브되지 않기 때문에 빠른 버전에서 기본 제공 특성을 사용하고 있습니다. 렌더링 속도가 느리다. 나는이 희망

당신이 찾고있는 무엇 :

// Step 5 - Bind each of the vertex shader's attributes to the programs 
[self.meshShader addAttribute:@"inPosition"]; 
[self.meshShader addAttribute:@"inNormal"]; 
[self.meshShader addAttribute:@"inTexCoord"]; 

// Step 6 - Link the program 
if([[self meshShader] linkShader] == 0){ 
    self.posAttribute = [meshShader attributeIndex:@"inPosition"]; 
    self.normAttribute = [meshShader attributeIndex:@"inNormal"]; 
    self.texCoordAttribute = [meshShader attributeIndex:@"inTexCoord"]; 

... 


- (void) addAttribute:(NSString *)attributeName 
{ 
    if ([attributes containsObject:attributeName] == NO){ 
     [attributes addObject:attributeName]; 
     glBindAttribLocation(program, [attributes indexOfObject:attributeName],  
     [attributeName UTF8String]); 
    } 
} 

업데이트 : 추가 조사 후 : 1) 나는 dhpoWare의 modelObj 로더 (수정)를 사용하고의 인터리브 배열을 사용하기 때문에 해요 구조와 마찬가지로 성능 측면에서도 구조의 배열처럼 작용합니다. 나는 악기를 잘못 해석하고있을 수 있습니다. modelObj 코드는 glDrawElements_IMM_Exec을 호출합니다. 또한 roundabout 방식으로 gleDoDrawDispatchCore를 호출합니다. glDrawElements_IMM_Exec에서 많은 호출이 누적되고 있는지, 그리고 gleDoDrawDispatchCore를 통해 이들을 블래스트하는지 확실하지 않습니다. 던노. 2) GLEngine이 외부 고리가없는 내 사용되지 않는 내부 3D 개체 메서드 중 하나를 호출하기 때문에 Instruments에 문제가 있다고 생각합니다. Xcode 중단 점을 설정하여 두 번 확인했는데 절대로 넘어지지 않았습니다. 더 이상 3DS를하지 않습니다.

나는 계속 주변을 둘러 보며 답을 얻지 못할 것 같아. 누군가 구조의 배열이 갈 길이라는 의견에 대해 저에게 의견을 제시한다면 그것은 인정 될 것입니다.

해결 방법 : VBO를 프런트 엔드에 추가했는데 모두 정상입니다. 원래 코드는 OpenGL ES 2.0 가이드에서 왔으며 VBO를 추가하면 내 문제가 해결됩니다. 60, 1 ms 드라이버 호출시의 프레임 속도. 코드는 다음과 같습니다.

glGenVertexArrays(1, &vaoName); 
glBindVertexArray(vaoName); 

// new - create VBO 
glGenBuffers(1, &vboName); 
glBindBuffer(GL_ARRAY_BUFFER, vboName); 

// Allocate and load position data into the VBO 
glBufferData(GL_ARRAY_BUFFER, sizeof(struct vertexAttribs) * self.numVertices,            
        vertexAttribData, GL_STATIC_DRAW); 
// end of new 

NSUInteger vtxStride = sizeof(struct vertexAttribs); 
//GLfloat *vtxBuf = (GLfloat *)vertexAttribData; // no longer use this 
GLfloat *vtxBuf = (GLfloat *)NULL;    // use this instead 

glEnableVertexAttribArray(self.posAttribute); 
glVertexAttribPointer(self.posAttribute, VERTEX_POS_SIZE, GL_FLOAT, GL_FALSE, 
         vtxStride, vtxBuf); 
vtxBuf += VERTEX_POS_SIZE; 

glEnableVertexAttribArray(self.normAttribute); 
glVertexAttribPointer(self.normAttribute, VERTEX_NORM_SIZE, GL_FLOAT, GL_FALSE, 
         vtxStride, vtxBuf); 
vtxBuf += VERTEX_NORM_SIZE; 

glEnableVertexAttribArray(self.texCoordAttribute); 
glVertexAttribPointer(self.texCoordAttribute, VERTEX_TEX_SIZE, GL_FLOAT, GL_FALSE, 
         vtxStride, vtxBuf); 
... 

Answer 1

구조체의 메모리에 단위 스트라이드 액세스를 달성하기위한 배열은 대략 경험적입니다. GPU뿐만 아니라 Intel Xeon Phi와 같은 CPUS 및 Co 프로세서에도 적용됩니다.

귀하의 경우,이 코드 부분이 GPU로 전송되는 것을 믿지 않습니다. 대신 성능 저하는 비 단위 메모리 액세스 (CPU 대 메모리) 때문입니다.