POT 텍스처가 냄비보다 느리게 작동하는 이유는 무엇입니까?

Question

나는 POT.FPS가 28-30로 이동하는 기능을 직접 적응하지 않고 텍스처

public static int loadTexture(Bitmap bmp) 
{ 
    final int[] textureHandle = new int[1]; 

    GLES20.glGenTextures(1, textureHandle, 0); 
    if (textureHandle[0] != 0) 
    { 

     // Bind to the texture in OpenGL 
     GLES20.glBindTexture(GLES20.GL_TEXTURE_2D, textureHandle[0]); 

     // Set filtering 
     GLES20.glTexParameteri(GLES20.GL_TEXTURE_2D, GLES20.GL_TEXTURE_MIN_FILTER, GLES20.GL_LINEAR); 
     GLES20.glTexParameteri(GLES20.GL_TEXTURE_2D, GLES20.GL_TEXTURE_MAG_FILTER, GLES20.GL_LINEAR); 
     //GLES20.glGenerateMipmap(textureHandle[0]); 
     //adapt texture to POT 
     int adaptedWidth= (int) Math.pow(2,Math.ceil(Math.log(bmp.getWidth())/Math.log(2d))); 
     int adaptedHeight= (int) Math.pow(2,Math.ceil(Math.log(bmp.getHeight())/Math.log(2d))); 
     Log.d("texture",adaptedWidth+","+adaptedHeight); 

     Bitmap tmp = Bitmap.createScaledBitmap(bmp, adaptedWidth, adaptedHeight, false); 
     Log.d("asize",tmp.getWidth()+","+tmp.getHeight()); 
     // Load the bitmap into the bound texture. 
     GLUtils.texImage2D(GLES20.GL_TEXTURE_2D, 0, tmp, 0); 
     //GLUtils.texImage2D(GLES20.GL_TEXTURE_2D, 0, bmp, 0); 
     tmp.recycle(); 
     // Recycle the bitmap, since its data has been loaded into OpenGL. 
     //bmp.recycle(); 
    } 

    if (textureHandle[0] == 0) 
    { 
     throw new RuntimeException("Error loading texture."); 
    } 
    return textureHandle[0]; 
} 

나는 (비 POT입니다) 내 비트 맵을로드하는 경우 나는이 code.Hovever으로 14 ~ 17 FPS를 얻었다을로드하려면 다음을 사용하십시오 POT 텍스처가 POT보다 빨리 작동해야한다고 생각했습니다. 설명이 있습니까?

UPD : 렌더링 코드 :

@Override 
public void onDrawFrame(GL10 gl) { 
    //curScale=modelMatrix[SCALE_X]; 
    TimeMeasurer.reset(); 
    long curTS= SystemClock.uptimeMillis(); 
    long frameRenderTime=curTS-ts; 
    //Log.d("renderer","FPS:"+1000.0/frameRenderTime); 
    Log.d("renderer","frame render time:"+frameRenderTime); 
    ts=curTS; 
    GLES20.glClear(GLES20.GL_DEPTH_BUFFER_BIT | GLES20.GL_COLOR_BUFFER_BIT); 
    if (piecesMesh!=null) { 
     Matrix.setIdentityM(MVPMatrix,0); 
     Matrix.multiplyMM(MVPMatrix,0,projMatrix,0,modelMatrix,0); 
     drawPassivePieces(); 
     drawActivePieces(); 
     if (helper!=null) { 
      drawHelper(); 
     } 
    } 
    TimeMeasurer.measure("onDrawFrame execution time:"); 
} 
private void drawPassivePieces() { 
    //shadows 
    shadowProgram.useProgram(); 
    shadowProgram.setUniforms(MVPMatrix,textureMaskId); 
    shadowMesh.bindPieceData(shadowProgram,false); 
    shadowMesh.drawPieces(false); 
    shadowMesh.disableAttributes(shadowProgram); 
    //pieces 
    piecesProgram.useProgram(); 
    piecesProgram.setUniforms(MVPMatrix, textureImageId, textureMaskId); 
    piecesMesh.bindPieceData(piecesProgram,false); 
    piecesMesh.drawPieces(false); 
    piecesMesh.disableAttributes(piecesProgram); 

} 
private void drawActivePieces() { 
    //shadows 
    shadowProgram.useProgram(); 
    shadowProgram.setUniforms(MVPMatrix,textureMaskId); 
    shadowMesh.bindPieceData(shadowProgram,true); 
    shadowMesh.drawPieces(true); 
    shadowMesh.disableAttributes(shadowProgram); 
    //pieces 
    piecesProgram.useProgram(); 
    piecesProgram.setUniforms(MVPMatrix, textureImageId, textureMaskId); 
    piecesMesh.bindPieceData(piecesProgram,true); 
    piecesMesh.drawPieces(true); 
    piecesMesh.disableAttributes(piecesProgram); 
} 
public void drawHelper() { 
    helperProgram.useProgram(); 
    helper.bindData(helperProgram); 
    helper.draw(); 
    helper.disableAttributes(helperProgram); 
} 

Answer 1

자세한 성능 분석이 없으면 추측 이상의 것을 수행 할 수 없습니다.

하나의 가능한 원인은 렌더링이 텍스처 샘플링의 메모리 대역폭으로 제한된다는 것입니다. 텍스처를 크게 만들면 액세스되는 총 메모리 양이 많아 져 속도가 느려집니다.

또는 위와 매우 관련이 있습니다. 샘플링 된 텍셀이 메모리에서 더 멀리 퍼져 나가면 텍스쳐 샘플링의 캐시 히트 율이 떨어집니다. 이는 텍스처를 업 스케일링 할 때 발생합니다. 캐시 적중률이 낮 으면 성능이 저하됩니다.

ES 2.0의 제한된 NPOT 지원으로 인해 필요한 경우가 아니면 인위적으로 필요 이상으로 텍스처를 인공적으로 만들어서는 안되며 사용하는 하드웨어가 OES_texture_npot 확장을 광고하지 않습니다. 나는 누군가가 오랫동안 POT 텍스처를 선호하는 하드웨어를 만들었다는 것을 의심한다.

Answer 2

는 POT 텍스처를 사용하는 큰 장점이 있습니다. OpenGLES 2.0에서는 반복과 같은 밉맵 및 유용한 텍스처 주소 지정 모드를 사용할 수 있습니다. 어쨌든 텍스처가 POT 인 것처럼 많은 구현체가 메모리를 할당하므로 메모리를보다 효율적으로 활용할 수도 있습니다.

그러나이 경우 POT가 아닌 텍스처를 가져 와서 크기를 조정하면 성능이 약간 저하 될 것으로 예상됩니다. 밉맵을 사용하지 않기 때문에 잠재적 인 잠재력을 놓치고 있습니다. 더 큰 텍스처를 사용하면 이미지의 유용한 부분이 이전보다 훨씬 많은 메모리에 퍼져 있기 때문에 GPU의 텍스처 캐시에 대해 더 많이 묻습니다.

밉 매핑이없는 경우 큰 텍스처는 작은 텍스처보다 성능이 떨어지고 리 스케일링 프로세스는 텍스처를 더 크게 만드는 것입니다.

차이점이 너무 두드러지다는 것에 놀랍니다. 크기 조정의 크기가 너무 크거나 예기치 않은 텍스쳐 포맷이나 필터 모드를 선택하는 것과 같은 예기치 않은 작업을하지 않았습니까?