RGB 값 관련 질문드립니다.

안녕하세요.색상 값이나, reflection coefficient 는 말씀하신 대로, 0.0 ~ 1.0 사이의 값으로 설정하는게 맞고, 실제로 그렇게 설정하고 있습니다. 문제는 light source 의 경우에는 빛의 색상도 중요하지만, 빛의 강도(intensity) 도 표현하고 있다는 점 입니다. Phong 의 수식을 보면, 특히 point light source 의 경우, 거리(distance)에 따른 attenuation term을 적용하고 있는데, 이 때문에, 거리에 따라서 intensity가 급감할 수 있습니다. 이 때문에, attenuation coefficient 들을 잘 조정하거나, 또는 light intensity를 높여서, 거리가 떨어져 있어도 Phong 수식에서 적당한 밝기가 나오게 하는 방식을 쓰고 있습니다.이 부분은 최종 밝기가 적절히 나오면 되는 셈이라서, 빛의 강도를 적절히 조정해도 큰 문제는 없습니다. 감사합니다.

vert_phong.vert negate 질문

안녕하세요.강의를 진행해 나가면서, 앞부분에서는 z 좌표를 negate 하는 방식으로 좌표계를 전환했습니다.뒤에, projection 부분을 설명하면서, projection matrix를 설정할 때, z 좌표 부분을 matrix 내에서 한번 뒤집도록 했습니다. 그래서, 그 이후는 z negate 부분이 vertex shader 에서 삭제되었습니다. 정확히는 projection matrix 에서 이미 z-negate 를 하는 경우라면, vertex shader 에서 z-negate를 하지 않습니다. 위의 코드가 바로 여기 해당될 겁니다. projection matrix를 계산하는 부분의 코드를 검토해 보면, 거기서 이미 z-negate를 하고 있을 겁니다. 감사합니다. ~

glm-tri.cpp 의 glVertexAttribPointer 질문입니다.

안녕하세요.현재 사용하시는 컴퓨터와 OS 를 알 수 있을까요.그리고, 이 프로그램 이전의 프로그램들에서는 정상 작동했었는지도 체크가 필요합니다.현재 배포되는 예제들은 Win10/Win11 또는 Linux 에서 pre-compiled header 를 배제한 환경을 대상으로 합니다. 아래 AI 인턴에서도 설명이 나옵니다만, glVertexAtttribPointer 의 마지막 인수는 memory address 또는 offset 모두 가능한데, offset으로 쓰기 위해서는 vertex buffer 를 만들었어야 합니다.이 강의 내에서도 vertex buffer object를 만드는 방법을 설명합니다만, 아직은 적용하지 않았기 때문에, memory address 를 써야 맞고, 여기 (void*)0을 넣었는데, 작동했다면, 더 이상한 상황입니다.glGenBuffers() 와 같은 함수가 혹시 어디선가 사용되었나요?배포된 예제에서는 vertex buffer 사용이 없었기 때문에, 작동하지 않아야 정상입니다.stride 도 vertex buffer object 를 사용하는 부분에서 추가 설명되는데, 0 으로 설정하면 자동 계산이 되어서, compact packing 된 상태로 보기 때문에, 현재 설정에서는 0으로 하나, 4 * sizeof(float) 또는 sizeof(glm::vec4)로 하나 동일하게 작동해야 합니다. 감사합니다.

pitch값에 따른 alignement boundary(size) 질문

안녕하세요.해당 부분은 다시 체크해 보니, 말씀하신 논리 대로, 512 바이트로 보는 것이 더 합당해 보입니다.아랫쪽의 AI 답변에도 나와 있듯이, CUDA 에서는 경우에 따라서는 alignment 를 가변적으로 적용하기도 해서, 256 바이트, 512 바이트가 유동적으로 적용되기도 합니다만, 이번 경우는 512로 보는 것이 더 적합해 보입니다.강의를 재녹화할 때, 수정하도록 하겠습니다.감사합니다. ~

vulkan 강의 일정

안녕하세요.계속해서 vulkan 에 대한 준비를 하고 있습니다만, 여러가지 사정 (해외 출장 등) 으로 늦어져서 죄송합니다.일부 촬영도 했습니다만, 계속해서 준비를 서두르도록 하겠습니다.감사합니다.

common.cpp의 procArg 함수에 대해 질문이 있습니다.

안녕하세요.명백한 오타 이네요 ㅠㅠ연산자를 || 로 수정해야 합니다.소스 코드에서도 수정해서 다시 배포하도록 하겠습니다.감사합니다. ~

외적 공식 문의

안녕하세요.공식을 확인해 봤는데, 문제가 없습니다. 수학책을 찾아보시거나, 아래 나무위키 링크를 참고하셔도 좋을 겁니다.https://namu.wiki/w/%EC%99%B8%EC%A0%81 아랫첨자로 쓰인 x,y,z 의 위치 (나무위키 링크에서는 아랫첨자 1,2,3) 를 잘 보면,+로 할때는 일관되게 증가해 가는 순이고,반대로, -로 할 때는 y 에 대해서는 순서가 뒤집어 집니다. (즉, determinant 가 - 로 계산됩니다.) determinant 를 어떻게 잡느냐의 문제일 뿐이고, 계산 결과는 동일합니다.감사합니다.

[30-4] hist-shared.cu 에서 질문있습니다.

안녕하세요.thread block 1개를 기준으로 보면, 말씀하신 내용이 맞습니다.다만, 현재 예제에서는 thread block 을 여러 개 사용하고, 이것들이 동시에 실행되고 있습니다.즉, thread block 여러 개에서, theadIdx.x 는 0 ~ 31인 thread 들이, 각 thread block 에서 동시에 메모리 영역에 write 하려고 하므로, 결국 atomicAdd 가 아니면 답이 틀리게 됩니다.감사합니다.

hello shader 프로그램 실행이 안됩니다.

안녕하세요.괜찮으시면, 사용하신 컴퓨터 환경을 알려주실 수 있을지요.말씀하신 상황이 발생했다면, 그래픽 카드 제조사에 리포트를 해야 할 것 같습니다.그래픽 카드의 모델과, 디바이스 드라이버 버전, OpenGL 드라이버 버전 정도를 알려주시면, 해당 제조사에 버그 리포트 하고, 문제점을 파악해 보겠습니다.감사합니다. P.S: 혹시 glFlush() 나, glFinish() 함수가 빠져있다면, glDraw() 함수 이후에 마지막 부분에 glFinish()를 추가해서 해결하는 경우도 있습니다만, 지금 말씀 하신 증상으로는 그 문제도 아닌 것 같긴 합니다..

[Matrix Addition Problem] 1D를 사용하지 않는 이유가 뭔가요?

안녕하세요.2D 행렬를 다룰 때는 되도록 2D layout 으로 접근하게 됩니다.CPU + RAM 위주로 설명하는 예제들에서는 2D 행렬도 어차피 1D로 주욱 나열되고, 한 row 와 다음 row 사이에 빈 공간이 없다고 보는 경우가 많을 겁니다. 실제로 memory alloc 을 하거나, 2D 행렬의 memory alloc 상황을 봐도, 1D 로 할당 할 때나 별 차이가 없습니다.CUDA 를 비롯해서, GPU 기반으로 가거나, 병렬 처리를 고려하면, 이제 2D memory 할당 시에, 1개의 row 가 되도록 128 / 256/ 512 / 1024 Byte boundary에 맞추거나 하는 식으로 할당하는 것이 일반적입니다. thread block 별로 memory 를 access 할 때, 서로 겹치지 않게 하는 것이 전체 performance 에서 훨씬 유리하기 때문에 이런 상황이 생깁니다. 현재는 addition 이라서, 1D layout 이 유리해 보이지만, 뒤에 multiplication 등의 더 복잡한 연산으로 가면, 2D layout 으로 구현하는 것이 훨씬 빨라집니다. 여러가지 이유로, 2D 행렬 이나, 2D image 를 다룰 거나 할 때는, cuda block 도 2D layout 으로 구성하는 것이 일반적입니다.감사합니다.