정말 좋은 글이었음, 그런데 내용이 너무 짧았음, 이제 막 흥미로워지기 시작했는데 끝난 느낌임, 다음 편이 기대됨
다음 주에도 흥미진진한 에피소드가 이어질 예정임, GPU에서 대기 중이던 명령이 큐에서 빠져나와 실행되는 모습을 보게 될 것임, 이번 글에서 다루는 추상화 수준은 사용자/커널 경계에서 데이터를 넘기는 부분임, 주로 큐와 버퍼 관리만 다루다 보니 연산 자체는 많지 않음, 진짜 중요한 내용은 큐에 넣어진 명령들이 실행될 때 일어나게 됨, GPU에서 또 다른 명령 완료 신호가 반대로 전달되는데, 그것도 궁금함, 이런 비동기 처리 대부분은 드라이버가 아니라 사용자 코드 쪽에서 처리됨, 드라이버는 완료 신호만 넘겨주는 구조임
나는 rk3588 기기 중 하나를 데스크톱으로 사용하면서 panfrost를 쓰고 있는데, 가끔 Firefox에서 화면이 검게 나오거나 투명한 영역이 생기는 버그가 있음, 이상한 현상임
RK3588은 실제로 panfrost가 아니라 해당 글의 주제인 panthor 드라이버를 사용함
uring_cmd를 ioctls 대신 활용하는 방안이 고려됐는지 궁금함, 이 프로젝트가 완전히 새로 만드는 것이니까 적용 가능성도 있어 보였음, 그 이점이 거의 없다고 본 이유가 궁금함
GPU는 이미 자체 비동기 명령 큐를 가지고 있기 때문에, IOCTL은 원래 비교적 저렴하게 그 명령 큐에 쓰는 역할임, 그래서 CPU 단에도 비동기 큐를 하나 더 만들어서 그 쓰기를 스케줄하는 건 쓸모가 제한적인 선택임, 혹시 GPU 명령 큐 자체를 uring으로 만들어 userspace에 매핑하자는 제안이라면, io_uring API 사양을 제대로 지원하려면 펌웨어를 꽤 대대적으로 바꿔야 하고, 하드웨어 특성상 아예 불가능할 수도 있음
기고문에서 설명하는 드라이버는 userspace Mesa 라이브러리가 요구하는 API를 그대로 따르고 있음
정말 흥미롭게 읽었음, 혹시 후속 파트가 있거나 논리적으로 이어질 만한 내용이 있을까 궁금했음
오늘 처음 공개된 글이라 이후에 업데이트가 더 나올 걸로 기대됨
"Rust GPU driver"라는 제목이 클릭을 더 유도하는 건 알겠지만, 사실상 이건 Arm Mali CSF 기반 GPU 드라이버 아님? 툴 개발을 위한 메타툴에 시선이 가는 게 개인적으로 별로임, 실제 목적이 Rust로 뭔가를 만드는 걸로 들림, 기사에서는 "arm mali 기반의 gpu 드라이버 커널"이라 명시했으면서도 굳이 arm mali 드라이버라고 부르지 않음, 드라이버를 만든다는 건 운영체제 API와 하드웨어 제조사 API를 연결하는 일에 불과함, 그 위에 추가로 추상화 계층을 구축하는 프레임워크를 만드는 건 아니라고 생각함, 조금 직설적으로 표현한 점 양해 바람
이번 사례가 리눅스에서 처음 시도되는 Rust 기반 GPU 드라이버 중 하나라는 점에서 러스트가 중요한 키워드임
나는 거칠게 말한 걸 미안해하지 않음, 당신 말투를 보니 현대 GPU 드라이버가 어떤 건지 전혀 모르는 것 같음, 15년 전까지만 해도 써 본 적 있지만 그동안 더 복잡해졌다는 것만큼은 알고 있음, 리눅스 커널 소스코드만 봐도 GPU 드라이버가 코드 라인 수로 가장 많은 비중을 차지하는 영역임, 거의 모든 드라이버가 여러 그래픽카드를 지원하기까지 함, 매번 완전히 독립적인 드라이버를 각각의 GPU 카드마다 별도로 만드는 게 비합리적인 거라는 사실 아는지 의문임, GPU 드라이버 작업은 두 API를 단순히 '선만 연결'하는 일이 아님, 실제론 생각보다 많이 다름, 혹시 반박할 수 있다면 본인이 작성한 GPU 드라이버를 보여주면 됨, 진짜로 선을 몇 개만 연결해서 끝났는지 확인해보고 싶음
Rust가 중요한 이유는 이것이 최초(또는 최초 중 하나)로 러스트 인프라를 GPU 드라이버에 사용한 사례이기 때문임
Hacker News 의견