Warp를 동시에 돌린다는 말이 이해가 가지 않습니다.

안녕하세요. 네. 당연히 그렇게 처리 합니다. SM 1개 내의 모든 SP 들은 같은 clock 으로 동시에 실행됩니다. warp 단위로 실행 해야 하다 보니, 같은 warp 를 실행하는 32개의 SP 는 instruction 도 똑같은 것을 수행합니다. 강의에서도 한번 설명했지만, GPU 구조에서는 ALU + control unit 쪽을 줄이는 대신 갯수를 늘리는 쪽으로 설계 방향을 잡았는데, ALU 를 줄이는 데는 한계가 있고, 결국 control unit을 최대한 줄이는 방법이, 32개의 warp를 실행하는 32개의 SP가 control unit 1개의 통제를 받는 방식이고, 이러면, 이들은 동시에 똑같은 instruction을 수행하는 수 밖에 없습니다. 감사합니다.

Thread Block 개수에 제한이 있나요?

안녕하세요. 둘다 thread block 에 대한 설명이었고, 둘다 맞는 설명입니다. kernel design 시에는 thread block 의 갯수가 거의 제한되지 않습니다. (실제로는 제한이 있지만, 매우 큰 숫자라서, 실무에서는 이쪽 제한에 걸리기 전에, memory 용량 제한 등의 다른 제한이 먼저 걸리기 때문에, 제한이 없다고 설명합니다.) 반면, SM 에서는 1개의 SM 이 동시에 실행 가능한 thread block 갯수에 제한을 걸어 두었고, 보통 32개 정도로 제한됩니다. 그래서, SM 들은 kernel 에서 실행하고 있는 매우 많은 thread block 중에서, 딱 32개만 가져와서 실행을 시작하고, 실행 중인 것이 완료되면, 완료되는 대로, 1개씩 더 가져와서, 되도록 항상 32개의 thread block이 동시 실행 상태로 운영되게 합니다. 즉, CUDA 가 관리하는 kernel 의 thread pool 에는 매우 많은 thread block 이 들어갈 수 있고, 실제로 몇 천 개, 몇 만 개의 thread block을 사용하기도 합니다. 이제 CUDA가 kernel을 실행하기 시작하면, 여러 개의 SM 들이 (보통 수십개, 많으면 수백개) 돌면서, 각각은 자기가 동시에 실행시킬 수 있는 최대 갯수 (보통 32개)만큼만 가져와서 실행합니다. 전체 thread 갯수가 아무리 커도, 1개 SM 이 동시에 실행할 수 있는 thread block은 현실적으로 제한될 수 밖에 없습니다. 감사합니다.

#include "./common.c"오류

안녕하세요. 배포된 소스 코드의 각 파일은 내부에 #include "common.c" 를 가지고 있습니다. 즉, 컴파일 할 때, 해당 파일만 컴파일 하면 되고, common.c 가 컴파일 프로젝트에 들어가면 중복이 일어나서, 위와 같은 에러가 발생하게 됩니다. 감사합니다.

22-6 varying color 프로그램 관련 질문

안녕하세요. 출장 관계로, 답변이 늦었습니다. ^^;; 우선, shader 변수들은 변수명으로 서로 link 됩니다. 컴파일러에서, vertex shader 의 out 에 있는 변수 이름과, fragment shader 의 in 에 있는 변수 이름이 일치하면 서로 연결 시키게 됩니다. 역으로, 서로 연결되는 변수 이름이 없다면, warning 이나, error 메시지를 출력해 줍니다. fragment shader 의 out 은 사실 draw buffer 의 설정에 따라서 달라지는데, OpenGL draw buffer 의 최초 설정은 framebuffer 의 RGBA 값으로 출력하게 되어 있어서, out vec4 fragColor 라고 하면, 그 값이 그대로 연결되는 것입니다. draw buffer 의 설정을 변경할 수 있어서, 그런 경우에는 여러 개의 RGBA 값을 출력하거나, depth 값을 출력하게 하는 것도 가능합니다. 다만, 이런 부분은 상당히 고급 기법이 되어서, OpenGL 강의의 8번 이나 9번에서 다룰 계획이었고, 지금은 7번까지 제공되고 있습니다. 추가 강의를 제작하게 되면, 해당 내용이 들어갈 것 같습니다. 감사합니다.

32-6 OpenGL Z 버퍼 - Depth 설정 관련 질문

안녕하세요. 일종의 습관으로 볼 수 있습니다. ^^;;; 예제 프로그램들에서와 같이, 간단한 출력을 하는 경우에는, glEnable 종류를 main loop 이전에 한번 설정하는 방법이 더 나을 수 있습니다. 반면에, 꽤 복잡한 scene 을 출력할 때는, depth 처리가 필요한 것들을 출력했다가, 중간에 depth 처리가 불필요한 것을 출력했다가, 다시 depth 처리가 필요한 것을 출력했다가 하는 경우도 종종 생깁니다. 이런 부분들을 처리하다 보면, 중요한 glEnable 들은 draw 하기 바로 전에 다시 set 하는 방식을 취하기도 합니다. 다행히, glEnable 함수로 무엇을 설정하는 것이, 대부분의 경우는 크게 오버헤드가 없어서, 필요하면 중복해도 써도 별 문제가 없다 보니까, glEnable 함수를 draw 루틴에 넣어두기도 합니다. 굳이 따지면, 비효율적인것은 맞는데, 다른 책이나, 싸이트의 예제들을 보아도, draw 루틴에서, 일종의 습관처럼 써 놓는 경우가 종종 있습니다. 감사합니다.