디스크립터 타입

디스크립터 타입은 그래픽 카드용 프로그램이 받을 데이터의 종류를 칸마다 정해 둡니다. 그림이 오는 칸과 숫자 묶음이 오는 칸은 타입이 다릅니다. 그래픽 카드는 이 타입을 보고 칸을 읽는 방법을 미리 준비합니다.

쉽고 빠른 이해

그래픽 카드용 프로그램은 데이터를 번호 붙은 칸으로 건네받습니다. 디스크립터 타입은 칸 하나에 올 데이터의 종류입니다. 의자를 그린다면 나뭇결 그림이 오는 칸과 광택 값이 오는 칸은 타입이 다릅니다.

종류를 미리 정하지 않으면 그래픽 카드가 칸을 어떻게 읽을지 모릅니다. 그림은 이웃한 색을 섞어 가며 읽습니다. 숫자 묶음은 메모리에서 바로 읽습니다. 읽는 방법이 다르니 그래픽 카드용 프로그램을 기계어로 옮길 때 이미 알고 있어야 합니다.

어떻게 도나:

1. 칸 배치를 정할 때 칸마다 타입을 적습니다
2. 그래픽 카드용 프로그램 코드도 같은 칸을 같은 종류로 선언합니다
3. 그릴 때 그 칸에는 적어 둔 타입의 데이터만 끼웁니다

대가는 칸의 타입을 나중에 못 바꾼다는 것입니다. 바꾸려면 칸 배치를 새로 만듭니다. 그 배치를 쓰던 그리기 설정도 다시 만듭니다.

아주 작은 값 하나는 칸 없이 그리기 명령에 바로 실어 보냅니다. 그때는 디스크립터 타입이 없습니다.

상세

이 절은 셰이더가 자원을 받는 길부터 풀고 타입을 고르는 기준에서 끝납니다.

셰이더가 자원을 받는 길

GPU(Graphics Processing Unit, 그래픽 처리 장치)는 같은 계산을 동시에 아주 많이 돌리는 칩입니다. 화면의 점 수백만 개의 색을 한꺼번에 정하려고 만들었습니다. 이 칩을 얹은 판이 그래픽 카드입니다.

GPU 위에서 도는 작은 프로그램이 셰이더입니다. 의자 표면의 점 하나가 무슨 색이 될지 계산하는 코드가 셰이더입니다. 이 코드는 수많은 점에서 동시에 돕니다.

셰이더는 계산에 쓸 데이터를 바깥에서 받아 읽습니다. 이 데이터를 자원이라고 합니다. 의자라면 나뭇결 그림과 광택 값이 자원입니다.

셰이더가 자원을 찾아가는 길잡이가 디스크립터입니다. 자원 하나가 GPU 메모리 어디에 있고 어떤 꼴인지를 담은 작은 데이터입니다. 셰이더 코드에는 자원의 이름 대신 「몇 번 묶음의 몇 번 칸」이라는 번호만 적힙니다.

이 묶음이 디스크립터 세트입니다. 디스크립터 여러 개를 한 벌로 묶어 둔 것입니다. 세트 안의 칸마다 번호가 붙습니다. 이 번호를 바인딩 번호라고 부릅니다.

칸 하나에는 대개 디스크립터가 하나 들어갑니다. 같은 타입의 디스크립터를 배열로 여러 개 넣을 수도 있습니다. 그림 여러 장을 한 칸에 배열로 받는 식입니다.

칸마다 정하는 종류

디스크립터 타입은 세트의 칸 하나에 올 자원의 종류를 정하는 값입니다. 셰이더가 그 자원을 어떻게 다룰지도 함께 정합니다. 의자의 재질 세트라면 0번 칸은 나뭇결 그림을 읽는 칸입니다. 가까운 점들의 색을 섞어 부드럽게 읽습니다. 2번 칸은 광택 값을 읽기만 하는 칸입니다.

공구 가방 안쪽 스펀지에는 공구 모양대로 홈이 파여 있습니다. 드라이버 홈에는 드라이버가 들어갑니다. 렌치 홈에는 렌치가 들어갑니다. 가방을 연 사람은 홈 모양만 보고 무엇을 꺼낼지 압니다.

디스크립터 타입이 이 홈 모양입니다. 칸마다 무엇이 들어올지 정해 두면 GPU 는 모양만 보고 읽는 법을 압니다.

타입은 자원이 그림이냐 숫자 묶음이냐만 가르지 않습니다. 같은 숫자 묶음이라도 셰이더가 읽기만 하는 칸과 써 넣어도 되는 칸은 타입이 다릅니다. 같은 그림이라도 섞어 읽는 칸과 점 하나를 골라 써 넣는 칸은 타입이 다릅니다.

타입은 디스크립터 세트 레이아웃에 적힙니다. 세트 레이아웃은 세트의 칸 배치를 미리 정해 둔 틀입니다. 세트는 이 틀에 맞춰 만듭니다.

틀에는 칸마다 넷을 적습니다. 바인딩 번호, 타입, 그 칸에 넣을 디스크립터 개수, 그 칸을 읽는 셰이더 단계입니다.

셰이더 단계는 그리기 흐름에서 어느 셰이더인지를 가리킵니다. 꼭짓점 위치를 옮기는 정점 셰이더와 점의 색을 칠하는 프래그먼트 셰이더가 그 예입니다. 그 칸은 여기 적은 셰이더만 읽을 수 있습니다.

지금까지 나온 것을 한 그림에 모으면 이렇습니다. 셰이더는 번호 둘로 세트의 칸을 찾습니다. 칸의 디스크립터가 자원을 가리킵니다. 칸마다 타입을 적어 둔 것은 세트 레이아웃입니다.

flowchart TD
    SH["셰이더 코드 · set = 1, binding = 0"]
    subgraph L["디스크립터 세트 레이아웃 · 틀"]
        L0["0번 칸 · 타입: 섞어 읽는 그림 칸"]
        L2["2번 칸 · 타입: 읽기만 하는 값 칸"]
    end
    subgraph S["디스크립터 세트 1"]
        D0["0번 칸 디스크립터"]
        D2["2번 칸 디스크립터"]
    end
    R0["자원 · 나뭇결 그림"]
    R2["자원 · 광택 값"]
    L0 -->|틀에 맞춰 만듦| D0
    L2 -->|틀에 맞춰 만듦| D2
    SH -->|1번 세트의 0번 칸| D0
    D0 --> R0
    D2 --> R2

타입을 미리 정해 두는 까닭

타입을 미리 정해야 하는 까닭은 셋입니다. 디스크립터에 담기는 내용, 세트를 담을 메모리, 셰이더를 기계어로 옮기는 일이 모두 타입에 달려 있습니다.

첫째로 타입마다 디스크립터에 담기는 내용이 다릅니다. 숫자 묶음 칸의 디스크립터는 그 묶음의 주소와 길이를 담습니다. 그림 칸의 디스크립터는 그림의 크기와 점 하나를 적는 형식 같은 정보를 담습니다. 그래서 디스크립터 하나의 크기도 타입마다 다를 수 있습니다.

둘째로 세트를 담을 메모리를 타입별로 셉니다. 세트는 디스크립터 풀에서 받아 냅니다. 풀은 세트를 담을 메모리를 미리 크게 잡아 둔 통입니다.

풀을 만들 때 타입마다 몇 개 몫을 잡을지 적습니다. 한 타입의 몫이 바닥나면 다른 타입의 몫이 남아 있어도 세트 할당이 실패할 수 있습니다. 그림 칸 몫은 넉넉한데 숫자 묶음 칸 몫이 바닥난 풀이 그렇습니다.

flowchart TD
    subgraph P["디스크립터 풀"]
        PU["숫자 묶음 칸 몫 · 0개 남음"]
        PC["그림 칸 몫 · 20개 남음"]
    end
    REQ["숫자 묶음 칸이 있는 세트 요청"]
    F["할당이 실패할 수 있음"]
    REQ --> PU
    PU --> F

셋째가 가장 무겁습니다. 드라이버가 셰이더를 GPU 의 기계어로 옮길 때 칸마다 타입을 알아야 합니다.

드라이버는 프로그램의 명령을 칩이 알아듣는 꼴로 바꿔 주는 소프트웨어입니다. 셰이더도 드라이버가 GPU 의 기계어로 컴파일합니다.

이 컴파일은 파이프라인을 만들 때 일어납니다. 파이프라인은 셰이더와 그리기 설정을 그리기 전에 한데 묶어 고정해 둔 객체입니다.

칸을 읽는 기계어는 타입마다 다릅니다. 그림 칸은 이웃한 점의 색을 섞어 읽는 텍스처 필터링 장치를 거칩니다. 숫자 묶음 칸은 메모리에서 바로 읽습니다. 어느 쪽으로 읽을지가 컴파일할 때 기계어에 들어갑니다.

세 까닭이 모두 타입에 기대기 때문에 칸의 타입은 나중에 못 바꿉니다. 한 칸의 타입을 바꾸려면 세트 레이아웃을 새로 만듭니다. 그 틀로 찍은 세트와 그 틀을 쓰던 파이프라인도 다시 만듭니다.

자주 쓰는 타입

Vulkan 은 프로그램이 GPU 를 다룰 때 부르는 함수 모음의 하나입니다. 이런 함수 모음을 그래픽스 API(Application Programming Interface, 응용 프로그램 인터페이스)라고 부릅니다. 타입의 이름과 가짓수는 그래픽스 API 마다 다릅니다. 이 소절은 Vulkan 의 이름을 씁니다.

Vulkan 의 타입은 모두 VK_DESCRIPTOR_TYPE_ 로 시작합니다. 아래에서는 이 앞머리를 떼고 뒤쪽 이름만 적습니다. 타입은 크게 버퍼를 받는 쪽과 이미지를 받는 쪽으로 나뉩니다.

버퍼를 받는 타입

버퍼는 GPU 메모리에 잡아 둔 바이트 덩어리입니다. 그 안에 숫자 묶음이나 긴 목록을 넣습니다. 같은 버퍼도 칸의 타입에 따라 셰이더가 다루는 방법이 갈립니다.

UNIFORM_BUFFER 칸에 오는 버퍼가 유니폼 버퍼입니다. 셰이더는 이 버퍼를 읽기만 합니다. 한 번 그리는 동안 모든 점이 같은 값을 읽습니다. 카메라 위치나 광택 값처럼 작은 값 묶음을 담습니다.

유니폼 버퍼는 한 칸에 담을 수 있는 크기의 상한이 작게 잡힙니다. 상한은 GPU 마다 다릅니다. 그래서 큰 목록은 유니폼 버퍼에 넣지 않습니다.

STORAGE_BUFFER 칸에 오는 버퍼가 스토리지 버퍼입니다. 셰이더가 이 버퍼를 읽고 쓸 수 있습니다. 크기가 큰 목록도 담습니다. 계산만 맡는 컴퓨트 셰이더가 두 목록을 더해 결과 목록에 써 넣는다면 세 목록 모두 스토리지 버퍼 칸으로 받습니다.

UNIFORM_BUFFER_DYNAMIC 은 유니폼 버퍼 칸의 변형입니다. 물체 천 개의 값을 버퍼 하나에 이어 붙여 두고 세트는 하나만 만듭니다. 그릴 때마다 버퍼 안의 시작 위치만 바꿔 넘깁니다.

이 시작 위치를 다이내믹 오프셋이라고 부릅니다. 다이내믹 오프셋을 쓰면 물체마다 세트를 따로 만들 일이 없어집니다. 스토리지 버퍼에도 같은 변형인 STORAGE_BUFFER_DYNAMIC 이 있습니다.

아래 그림은 세트 하나의 칸이 그릴 때마다 버퍼의 다른 시작 위치를 보는 모습입니다.

flowchart TD
    S["세트 하나 · UNIFORM_BUFFER_DYNAMIC 칸"]
    subgraph B["버퍼 하나"]
        O0["물체 0 값"]
        O1["물체 1 값"]
        O2["물체 2 값"]
        ON["나머지 997개"]
    end
    S -->|물체 0 을 그릴 때 다이내믹 오프셋| O0
    S -->|물체 1 을 그릴 때 다이내믹 오프셋| O1

이미지를 받는 타입

이미지는 가로세로로 점이 늘어선 GPU 메모리입니다. 이 점 하나를 텍셀이라고 부릅니다. 이미지를 받는 칸도 셰이더가 읽기만 하는지, 쓰기도 하는지에 따라 타입이 갈립니다.

SAMPLER 칸에는 이미지가 아니라 샘플러가 옵니다. 샘플러는 이미지를 읽는 규칙입니다. 멀리서 볼 때 이웃한 텍셀의 색을 섞을지, 좌표가 이미지 끝을 넘으면 어떻게 할지를 적습니다.

SAMPLED_IMAGE 칸에는 샘플러와 짝지어 읽을 이미지가 옵니다. 이 칸을 샘플드 이미지라고 부릅니다. 셰이더는 샘플드 이미지를 읽기만 합니다. 읽을 때 샘플러의 규칙대로 색을 섞습니다.

의자의 나뭇결 그림처럼 물체 표면에 입히는 이미지를 텍스처라고 합니다. 텍스처는 대개 샘플드 이미지 칸으로 받습니다.

COMBINED_IMAGE_SAMPLER 는 샘플드 이미지와 샘플러를 칸 하나에 같이 넣는 타입입니다. 이 칸을 결합 이미지 샘플러라고 부릅니다. 따로 두면 샘플러 하나를 여러 이미지가 나눠 쓸 수 있습니다. 합치면 칸 하나로 끝나서 적을 것이 줄어듭니다.

텍스처 두 장을 같은 규칙으로 읽는 경우입니다. 따로 두면 샘플러 칸 하나를 두 이미지가 함께 씁니다. 합치면 텍스처마다 샘플러를 품은 칸이 하나씩 생깁니다.

flowchart TD
    subgraph A["따로 두기 · 칸 셋"]
        I1["샘플드 이미지 칸 · 나뭇결"]
        I2["샘플드 이미지 칸 · 대리석"]
        SA["샘플러 칸 하나"]
        I1 -->|짝지어 읽음| SA
        I2 -->|짝지어 읽음| SA
    end
    subgraph C["합치기 · 텍스처마다 칸 하나"]
        C1["결합 이미지 샘플러 칸 · 나뭇결과 샘플러"]
        C2["결합 이미지 샘플러 칸 · 대리석과 샘플러"]
    end
    SA ~~~ C1

STORAGE_IMAGE 칸에 오는 이미지가 스토리지 이미지입니다. 셰이더가 텍셀 좌표로 하나를 골라 읽고 씁니다. 색을 섞어 읽지는 못합니다. 컴퓨트 셰이더가 화면을 흐리게 만든 결과를 이미지에 써 넣을 때 이 타입을 씁니다.

한 화면을 여러 차례에 나눠 그릴 때가 있습니다. 먼저 물체의 색만 이미지에 그려 두고, 다음 차례에 그 이미지를 읽어 조명을 계산하는 식입니다. 이 한 차례를 서브패스라고 부릅니다.

INPUT_ATTACHMENT 칸에는 바로 앞 서브패스가 그린 이미지가 옵니다. 이 칸을 입력 어태치먼트라고 부릅니다. 셰이더는 지금 칠하는 점과 같은 위치의 텍셀만 읽을 수 있습니다.

지금까지 본 타입을 모으면 이렇습니다. 세 번째 열을 보면 비슷한 타입끼리 어디서 갈리는지 보입니다.

이 밖에 텍셀 버퍼를 받는 타입이 둘 있습니다. 텍셀 버퍼는 버퍼에 담긴 긴 목록을 이미지의 텍셀처럼 한 칸씩 형식에 맞춰 읽게 하는 것입니다. 읽기만 하는 UNIFORM_TEXEL_BUFFER 와 읽고 쓰는 STORAGE_TEXEL_BUFFER 입니다.

셰이더 코드의 선언과 짝 맞추기

셰이더 코드도 칸마다 종류를 선언합니다. 세트 레이아웃에 적은 타입과 셰이더 코드의 선언이 같은 말을 해야 그림이 제대로 나옵니다. 이 소절은 GLSL(OpenGL Shading Language, OpenGL 셰이딩 언어)로 적은 선언을 타입과 짝지어 봅니다.

GLSL 에서는 선언의 모양이 곧 칸의 종류입니다. 아래 표의 선언 앞에는 layout(set = 1, binding = 0) 처럼 세트 번호와 바인딩 번호가 붙습니다. 표에서는 그 앞머리를 뗐습니다.

표에서 uniform 이 여러 줄에 붙은 것이 눈에 띕니다. GLSL 에서 uniform 은 셰이더 바깥에서 받는 것에 두루 붙는 말입니다. 유니폼 버퍼인지는 뒤에 중괄호 블록이 오는지로 가립니다.

texture2D 와 sampler2D 는 이름이 비슷해서 헷갈립니다. 앞의 것은 이미지만 받습니다. 뒤의 것은 이미지와 샘플러를 한 쌍으로 받습니다.

두 쪽이 어긋날 수 있습니다. 셰이더는 0번 칸을 텍스처로 읽습니다. 그런데 세트 레이아웃은 그 칸을 버퍼로 적었다고 합시다. Vulkan 은 이런 어긋남이 있을 때 결과를 보장하지 않습니다. 화면이 깨지거나 프로그램이 멈출 수 있습니다.

그래서 개발하는 동안에는 검증 레이어를 켜 둡니다. 검증 레이어는 Vulkan 호출을 가로채 규칙을 어겼는지 따져 알려 주는 도구입니다. 셰이더와 세트 레이아웃의 타입 어긋남은 파이프라인을 만들 때 잡힙니다.

같은 칸 배치를 두 번 적는 수고를 덜려는 방법도 있습니다. 컴파일된 셰이더를 읽어 칸마다 번호와 타입을 뽑아낸 뒤 세트 레이아웃을 만들어 줍니다. 이 방법을 셰이더 리플렉션이라고 부릅니다.

그래픽스 API 마다 부르는 이름

다른 그래픽스 API 에도 칸의 종류가 있습니다. 가르는 기준이 조금씩 다릅니다. 이 소절은 Direct3D 12 와 WebGPU 를 Vulkan 과 나란히 놓습니다.

Direct3D 12 는 칸의 종류를 네 가지로 가릅니다. 셋은 뷰이고 넷째가 샘플러입니다. 뷰는 셰이더가 자원을 어떤 방식으로 볼지 정해 둔 작은 데이터입니다. 세 뷰의 이름은 상수 버퍼 뷰, 셰이더 리소스 뷰, 순서 없는 접근 뷰입니다.

세 뷰는 자원이 버퍼냐 텍스처냐보다 셰이더가 읽기만 하느냐 쓰기도 하느냐로 먼저 갈립니다. SRV 와 UAV 는 버퍼도 텍스처도 받습니다.

WebGPU 는 웹 브라우저에서 GPU 를 다루는 API 입니다. 칸 배치를 적는 바인드 그룹 레이아웃에 칸마다 buffer, sampler, texture, storageTexture 가운데 하나를 적습니다. buffer 칸은 다시 uniform, storage, read-only-storage 가운데 하나로 나뉩니다.

표의 둘째 줄과 셋째 줄이 차이를 보입니다. Vulkan 은 읽기만 하는 큰 목록과 읽고 쓰는 목록을 같은 타입으로 받습니다. 읽기만 한다는 것은 셰이더 코드에 따로 적습니다. 다른 둘은 이 차이를 칸의 종류로 가릅니다.

Metal 은 애플 기기에서 GPU 를 다루는 API 입니다. Metal 은 칸의 종류를 셰이더 함수의 인자 선언에 적습니다. 버퍼, 텍스처, 샘플러 세 갈래로 나뉩니다.

타입을 고르는 기준

타입을 고르기 전에 칸을 둘지부터 정합니다. 칸을 안 두는 경우와 칸 하나를 여러 물체가 나눠 쓰는 경우가 먼저 걸러집니다.

아주 작은 값 하나는 칸을 두지 않습니다. 물체마다 다른 색 값 하나가 그렇습니다. 그런 값은 그리기 명령에 바로 싣는 푸시 상수로 보냅니다. 푸시 상수는 디스크립터를 거치지 않아서 디스크립터 타입이 없습니다.

물체 수백 개가 같은 모양의 값을 하나씩 가지면 다이내믹 타입을 먼저 봅니다. 값을 버퍼 하나에 이어 붙이고 세트 하나로 그립니다.

flowchart TD
    Q0{"아주 작은 값 하나인가"}
    Q1{"물체 수백 개가 같은 모양의 값을 하나씩 갖나"}
    PC["푸시 상수 · 칸 없음"]
    DY["다이내믹 타입"]
    NX["아래 두 물음으로"]
    Q0 -->|그렇다| PC
    Q0 -->|아니다| Q1
    Q1 -->|그렇다| DY
    Q1 -->|아니다| NX

나머지 칸의 타입은 두 물음으로 거의 정해집니다. 첫째는 칸에 오는 것이 버퍼인지 이미지인지입니다. 둘째는 셰이더가 그것을 쓰기도 하는지입니다.

flowchart TD
    Q1{"칸에 오는 것이 버퍼인가"}
    Q2{"셰이더가 쓰거나 크기가 큰가"}
    Q3{"셰이더가 텍셀을 써 넣나"}
    UB["유니폼 버퍼"]
    SB["스토리지 버퍼"]
    SI["스토리지 이미지"]
    SM["샘플드 이미지와 샘플러 · 또는 결합 이미지 샘플러"]
    Q1 -->|버퍼| Q2
    Q1 -->|이미지| Q3
    Q2 -->|아니다| UB
    Q2 -->|그렇다| SB
    Q3 -->|그렇다| SI
    Q3 -->|아니다| SM

이미지를 읽기만 하는 칸은 둘로 나눠도 되고 결합 이미지 샘플러 한 칸으로 합쳐도 됩니다.

같은 이름을 쓰는 USB 디스크립터

USB 디스크립터(Universal Serial Bus descriptor, 범용 직렬 버스 디스크립터)는 USB 장치가 자기 정체를 밝히려고 내놓는 짧은 데이터입니다. 이 데이터의 앞에서 두 번째 바이트에 디스크립터 타입이라는 값이 있습니다. 이 디스크립터가 장치 전체를 설명하는지, 설정 하나를 설명하는지를 가립니다.

이름만 같습니다. 그래픽스의 디스크립터 타입과는 관계가 없습니다. 글에 USB 장치가 나오면 이쪽 뜻입니다.

관련 항목

디스크립터 타입이 가르는 칸의 종류

유니폼 버퍼 · 스토리지 버퍼 · 샘플러 · 샘플드 이미지 · 결합 이미지 샘플러 · 스토리지 이미지 · 입력 어태치먼트 · 텍셀 버퍼 · 다이내믹 유니폼 버퍼 · 가속 구조 · 인라인 유니폼 블록

디스크립터 타입을 칸마다 적어 두는 구조

디스크립터 · 디스크립터 세트 · 디스크립터 세트 레이아웃 · 바인딩 번호 · 디스크립터 풀 · 파이프라인 레이아웃 · 다이내믹 오프셋

디스크립터 타입의 칸이 가리키는 자원

자원 · 버퍼 · 이미지 · 텍스처 · 이미지 뷰 · 버퍼 뷰 · 텍스처 필터링

입력 어태치먼트 칸이 기대는 그리기 순서

서브패스 · 렌더 패스

디스크립터 타입과 짝을 맞추는 셰이더

셰이더 · 정점 셰이더 · 프래그먼트 셰이더 · 컴퓨트 셰이더 · GLSL · SPIR-V · 셰이더 리플렉션

디스크립터 타입을 읽어 처리하는 소프트웨어

디바이스 드라이버 · 컴파일 · 검증 레이어 · 파이프라인 · 게임 엔진

디스크립터 타입을 다른 그래픽스 API 에서 대신하는 분류

상수 버퍼 뷰 · 셰이더 리소스 뷰 · 순서 없는 접근 뷰 · 바인드 그룹 레이아웃 · 루트 시그니처 · 디스크립터 테이블

디스크립터 타입의 칸 없이 자원을 건네는 방식

푸시 상수 · 푸시 디스크립터 · 바인드리스 · 디스크립터 인덱싱 · 디스크립터 버퍼

디스크립터 타입을 두는 그래픽스 API

Vulkan · WebGPU · Direct3D · Metal · 그래픽스 API

디스크립터 타입과 이름이 겹치는 개념

USB 디스크립터 · 파일 디스크립터 · 세그먼트 디스크립터 · 메서드 디스크립터

디스크립터 타입이 속하는 상위 분류

그래픽스 · 렌더링 · GPU · API