ASTC Format (2)

이 포스팅 쓰고 한 일년만에 다시 테스트 : http://illu.tistory.com/1194

좌로부터(from the left)

ETC RGB : 170.7kb

ETC2 RGB : 170.7kb

ASTC RGB 4x4 : 341.4kb

ASTC RGB 8x8 : 85.4kb

RGB 24bit : 1.3MB

left ETC2 RGB, right ASTC RGB 6x6 154.7 kb

HDR 소스 테스트 좌로부터 ETC, ETC2, ASTC 6x6

HDR Source Test. from the left ETC, ETC2, ASTC 6X6

지난 포스팅에서 안드로이드는 지원 디바이스는 Adreno 420이상, Mali T600 이상 기기라고 했었다.

Adreno 420의 경우 현재 ES 3.2 지원 디바이스이며,

Adreno 420 GPU supported OpenGL ES 3.2

Mali T 600의 경우 3.1을 지원한다.

Mali T600 GPU supported OpenGL ES 3.1

Android 개발자 페이지에서는 ES3.1+AEP를 요구한다(고팀장님 자료공유 땡큐함당)

https://android-developers.googleblog.com/2015/01/efficient-game-textures-with-hardware.html?m=1

Adaptive Scalable Texture Compression (ASTC)

The Android Extension Pack has ASTC as a standard format, removing the need to have different formats for different devices.

이게 3.1+AEP 표준이라는건지 지원안한다는건지 애....매...하다...

어쨌건 이대로 지원한다고 하면 Adreno 420이상 Mali T760이상을 요구한다.

국내 출시된 주요 스마트본 기기의 GPU를 살펴보면(국내외 출시 주요 모델 한정)

Summary of Smartphone GPU specification on South Korea.

Android

Galaxy S4 : Adreno 330/ PowerVR SGX544(ES 2.0 지원 기기)

Galaxy S5 : Adreno 330(LTE Cat.6 지원모델)/ Adreno 420

Galaxy S6 : Mali T760

Galaxy Note 3 : Mali T628 / Adreno 330

Galaxy Note 4 : Mali T760(Mali GPU는 이모델부터 ES 3.2를 지원한다)

Galaxy Note 5 : Mali T760

LG G3 : Adreno 330 / Adreno 420(Cat.6 지원모델)

LG G4 : Adreno 418(ES 3.1 지원모델)

LG G5 : Adreno 530(ES 3.1 + AEP)

LG G6 : Adreno 530

LG V10 : Adreno 418

LG V20 : Adreno 530

Xiaomi Mi 4 : Adreno330, Adreno 405(Mi 4i)

Xiaomi Mi 5 : Adreno 530

Xiaomi Note : Adreno 330 / Adreno 430(Note Pro)

Xiaomi Note 2 : Adreno 530

Xiaomi Note 3 : Adreno 512

Xiaomi Redmi : PowerVR SGX544(ES 2.0)

Xiaomi Redmi 2 : Adreno 306, Mali T628(Redmi 2A, ES 3.1)

Xiaomi Redmi 3 : Adreno 405 / Adreno 505(Redmi 3S)

Xiaomi Redmi 4 : Adreno 505 / Ardreno 308(4A)

Experia 라인업은 2차 라인업기기 모두 해당(most of 2nd line up models)

라인업에서 해당 기기 이상은 모두 ES 3.2 지원기기로 봐도 무방

IOS

iPhone 5s : PowerVR G6430(ES 3.1)

iphone 5c : PowerVR SGX543(ES 2.0)

iphone 6 : PowerVR GX6450(ES 3.1)

iphone 6+ : PowerVR GT7600(ES 3.1)

iphone 7, 7+, SE : PowerVR GT7600(ES 3.1)

iphone 8, 8+, X : A11 bionic(스펙 미공개 - 개발자 페이지에는 Metal과 ES 3.0 지원 목록만 공유)

iPad 4세대 : PowerVR SGX 544(ES 2.0)

iPad 5세대 : PowerVR GT7600

iPad Air : PowerVR G6430(ES 3.1)

iPad mini : PowerVR G6430(ES 3.1)

결론은... 아직 쓰기... 애매하다......

ASTC Algorithm : https://community.arm.com/graphics/b/blog/posts/astc-does-it

아래는 알고리즘 해설 부분 번역기 돌린거.(교정은 시간나는대로)

간단한 해설은 : https://blog.naver.com/tigerjk0409/221235264616

텍스처 압축에서 낮은 비트 전송률은 블록 단위로 픽셀을 압축하여 얻을 수 있습니다. 일반적으로 블록은 완전히 자체 포함되어 있으므로 압축을 풀기 위해 다른 데이터가 필요하지 않습니다. 조회 테이블이나 사전이 없습니다. 예를 들어 ETC를 사용하면 4 비트 4 블록을 64 비트 워드로 압축하고 낮은 비트율의 기본 색상과 텍셀 오프셋 당 더 낮은 비트율을 사용하여 픽셀 당 4 비트를 얻을 수 있습니다. 이 알려진 데이터 속도는 텍셀 좌표를 블록 위치로 신속하게 변환 할 수 있으므로 압축 해제 할 데이터 오프셋으로 변환 할 수 있음을 의미합니다. 픽셀 당 4 비트는 알고리즘의 최대 품질과 마찬가지로 ETC에 대해 고정되어 있습니다.

비교하면 ASTC는 비트 전송률에 대해 품질을 교환 할 수 있습니다. 이름에서 알 수 있듯이, 또한 확장이 가능하므로 비트 전송률을 높이면 픽셀 당 8 비트에서 0.86 비트까지 품질을 향상시킬 수 있습니다. 실제로 3D 텍스쳐를 사용하는 경우 0.59로 낮아질 수 있지만 자신보다 앞서는 것은 아닙니다.

이것이 달성되는 방법은 가변 블록 크기를 사용하는 것입니다. 데이터 크기에 따라 가변적이지 않은 모든 블록은 비트 전송률에 관계없이 128 비트입니다. 블럭의 풋 프린트는 4x4 블럭에서 12x12 블럭으로 다양합니다 (믹스의 과일 직사각형을 두어 비트율 선택을 더 많이합니다). 비트율은 128 비트를 블록. 128 비트의 16 픽셀은 픽셀 당 8 비트이고 128 비트의 144 픽셀은 픽셀 당 0.89 비트입니다. ASTC는 3x3x3에서 6x6x6으로 이동하는 3D 블록의 텍스처를 압축 할 수 있다는 점에서 매우 독특합니다. 이는 216 비트 (128 비트) 또는 픽셀 당 0.59 비트입니다.

나는 'how'부분을 아직 설명하지 못했다고 생각한다. 모든 블록에는 끝점 색상 세트가 있습니다. 그래서 당신이 완전히 다른 색조의 파란색으로 구성된 블록을 가지고 있다면, 당신의 종말점은 밝은 색과 어두운 색이 될 것입니다. 블록이 화염과 같이 더 재미있는 것이라면 종점은 노란색과 빨간색과 비슷하거나 작은 블록 인 경우 황색 오렌지색과 붉은 오렌지색입니다. 결국 블록에없는 색상을 포함하는 범위에는 아무런 의미가 없습니다. 그런 다음 개별 샘플은이 두 값 사이의 오프셋이므로 블록에 모든 종류의 다른 그래디언트 패턴이있을 수 있습니다. 픽셀 당 1 비트 미만을 목표로하고 있기 때문에 분명히 모든 픽셀을 정확하게 샘플링 할 수 없기 때문에 간헐적으로 샘플링하고 그 사이를 보간합니다.

그것은 마치 블러 티 색으로 유출되는 흐릿한 이미지로 이어질 수도있는 것처럼 들리 겠지만 그게 절반에 불과합니다. 블록에는 최대 4 개의 다른 색 그라디언트가있을 수 있기 때문에 각각 시작점과 종점이 있습니다. 그라디언트에서 텍셀이 어디에 있는지에 대한 샘플 모음이 하나 있지만 특정 텍셀을 가져 오는 데 사용되는 그라디언트는 두 번째 레이어에서 가져옵니다.이 패턴은 텍셀에서 선택하는 인덱스 패턴을 나타냅니다. 좋은 점은,이 인덱스 세트에는 보간이 없으므로 그라디언트의 부드러운 부분 사이의 대비되는 색상에 선명한 가장자리를 제공한다는 것입니다.

partitions.png 분명히 의문점은 당신이 조금이라도 없다면 텍스쳐에 텍셀 값마다 어떤 종류의 것을 넣을 수 있는가하는 것입니다. 대답은 해시 패턴입니다. 나는 나의 아주 좋아하는 그림을 여기에서 떨어 뜨릴 예정이다.

ASTC는 10 비트 시드에서 이러한 작은 색상 파티션 블록을 생성합니다. 2 파티션, 3 파티션 및 4 파티션 블록이 혼합되어 있음을 알 수 있습니다. 하나의 파티션 블록이 있지만 재미 있지는 않습니다.

다중 파티션 수는 매우 중요합니다. 텍스처의 파티션이 적을수록 더 많은 데이터를 사용하여 끝점과 그 사이의 그래디언트 값을 미세하게 조정할 수 있습니다. 따라서 파티션이 많을수록 세부 묘사가 잘 잡히지 만 그 세부 사항들 사이의 부드러운 부분은 약간 어려울 것입니다.

이 모든 절충안에 대한 설명은 압축이 어떻게 작동하는지에 대한 중요한 힌트입니다. 감압은 그래픽 하드웨어 자체에서 단 한 번의 패스트 패스로 발생하므로 사용자가주의를 기울이지도 않습니다. 그라디언트 오프셋은 샘플 맵에서 가져오고, 해시는 그래디언트 끝점을 찾도록 생성되고 마지막 색상이 그로부터 계산됩니다. 반면에 압축은 블록을 사용하여 몇 개의 파티션을 사용할 것인지, 어떤 해시 패턴을 사용할 것인지, 각 파티션의 끝점 색상은 무엇인지, 파티션이없는 경우는 어색하게해야합니다 색상을 완벽하게 일치 시키십시오. 파란색 픽셀이 빨간색과 노란색 사이의 그라데이션에 정확하게 위치합니까?

이것이 왜 압축이 오래 걸리는 이유입니다. 결국 가장 중요한 것은 렌더링하는 동안 텍스처가 얼마나 빨리 압축 해제되는지입니다. 압축은 실제로 압축 해제 속도를 활용하여 알고리즘이 파티션을 테스트하고 블록의 색상에서 끝점을 선택하며 샘플을 해당 그래디언트와 비교하여 계산 된 값으로 채운 다음 결과를 a로 압축 해제합니다. 픽셀 블록. 그런 다음 오류 메트릭을 사용하여이 시도가 얼마나 잘못되었는지 단일 값을 제공합니다. 항상 많은 잘못을 저지르고 많은 시간을 할애합니다.

블록은 특정 시도 횟수 이후 또는 오류 값이 주어진 임계 값 아래로 떨어지면 '완료'된 것으로 간주됩니다. 나는 그 알고리즘이 싫증이 나거나 좋은 것을 찾거나 괜찮은 것을 찾아 "충분히 가깝다"고 말한 것을 상상하고 싶다.

압축 시간은 그것이 얼마나 가깝고 얼마나 많은 시도가 포기하기 전에 시도 하는지를 알려줌으로써 다양해질 수 있습니다. 일부 이미지는 초기 압축 시도가 상당히 잘 맞았 기 때문에 실제로 압축률을 낮추면 꽤 잘 나올 수 있습니다. 다른 이미지는 처음 몇 번 시도해도 오래 걸릴 수 있습니다. 이러한 요소에 대한 사용자 제어는 필요한 경우 전화를 걸 수 있음을 의미합니다.

128 비트를 되돌려 보면 독자 중 일부는 여전히 나를 믿지 않는다는 것을 알고 있습니다. 해시 패턴에는 10 비트가 사용되고 최악의 경우 4 세트의 색상 끝점이 필요하다는 것을 알고 있습니다. 이것들은 RGBA이므로 8 가지 색상에 대해 각각 4 개의 값과 16 개의 보간 된 표의 그리드를 더한 것입니다. 즉, 각 값에 대해 2.45 비트 만 있습니다. 그러나 당신은 2.45 조금을 가질 수 없습니다, 당신은 단지 2 비트를 가질 수 있습니다, 그래서 여러분은 그것이 3 비트를 얻고 어떤 것이 2를 얻도록 당신이 그것을 이상하게 quantize해야한다는 것을 의미합니다, 그렇지 않으면 22 전체 비트를 낭비하고 있습니다. 낮은 비트 전송률을 사용한다면 비트를 낭비하십시오. 그런 다음 알고리즘은 어떤 22 개의 값이 3 비트인지, 26 개가 2 비트인지를 알아야합니다. 어떤 식 으로든 슬라이스하면 수학은 이상하게 끝납니다. 파티션의 수는 종점의 수를 변경하기 때문에 다른 유형 및 다른 가중치에 대해 서로 다른 알려진 데이터 크기가 필요하며 모두가 끔찍하게 복잡해집니다.

2011 년 ARM General Engineering 컨퍼런스에서 Tom Olson이 텍스처 압축의 새로운 기술에 대해 설명했던 자리에 참석했기 때문에 그렇게 할 필요는 없습니다. 삼중 수와 5 진수로 값을 표현하면 더 밀집 할 수 있습니다. 5 진수로 작업하는 경우 숫자는 0에서 4까지입니다. 첫 번째 5 분의 1 초, 두 번째 5 분의 5 초, 세 번째 5 분의 1은 25 초입니다. 이 세 자리 숫자에는 0에서 124 사이의 숫자 범위가 있으며 124는 7 비트로 나타낼 수 있습니다.

바이너리로 0-4의 값을 유지하려면 3 비트가 필요합니다. 따라서이 3 개의 값은 9 비트를 취합니다. 그러나 9 비트는 0에서 511까지의 값을 가질 수 있습니다. 실제로 9 비트를 이동하는 것이 어렵다는 사실은 말할 것도없이, 실제로 16 비트를 사용해야합니다. 16 비트는 5 개의 3 비트 블록을 저장할 수 있으며 마지막에는 사용되지 않은 비트가 하나 있습니다. 이 공간은 5 분의 1 초 동안 사용하십시오. 마지막 6 비트는 2 비트를 사용합니다. 비슷한 결과가 trits와 함께 나타납니다.

이 점을 흥미롭게 만드는 것은 두 가지 값 범위가 아닌 비 균일 성의 균일 한 표현에 관한 것이 아닙니다. 3 번과 5 번베이스의 선택은 수치적인 이유로 아주 똑똑합니다. 값을 정규화하고 0과 1 사이의 그래디언트로 나타내면 5 분위의 값은 (0, ¼, ½, ¾, 1)을 나타내며 트리는 (0, ½, 1)을 나타냅니다. 따라서 심지어 두 약수의 힘을 사용하여 블렌딩을 더 빠르게 만듭니다.

내가 3 비트 블록을 언급했을 때, 여러분 중 일부는 "그렇습니다. 그러나 그것들은 8 개의 값을가집니다"라고 말할 것입니다. 그들은 어떤 표준화 된 값을 가지고 있었을까요? 그들은 일곱 번째를 개최했을 것입니다. 컴퓨터를 일곱 번째로 작동 시키려고 노력한 적이 있습니까?

나는 그렇게 생각하지 않았다.