취미 부자의 개발 노트

이 글의 결론 (3문장)3DGS는 radiance field (c, σ) ← F(x, y, z, θ, φ)의 F를 신경망 대신 가우시안 수백만 개라는 명시적 자료구조로 바꾼 것이다. 여기서 (θ, φ)는 보는 방향이지 가우시안의 기울기가 아니다 — 기울기는 quaternion이 따로 들고 있고, (θ, φ)는 SH에서 색을 꺼낼 때만 쓰인다.1D 가우시안은 분산 하나로 폭이 정해지지만 3D는 방향이 있어서 3×3 공분산 Σ = R S Sᵀ Rᵀ가 필요하다. 화면에 그릴 때는 Σ' = J W Σ Wᵀ Jᵀ로 2×2 타원을 만드는데, 이 J가 원근 투영을 가우시안 중심에서 직선으로 편 1차 근사다.투영된 splat은 걸친 타일마다 엔트리로 복제되고, 타일 ID ‖ 깊이 키로 타일마다가 아니라 전체를 한 번에..

https://dl.acm.org/doi/10.1145/3620666.3651385 GSCore: Efficient Radiance Field Rendering via Architectural Support for 3D Gaussian Splatting | Proceedings of the 29th ACM IntAbstract Recently, 3D Gaussian splatting has gained attention for its capability to generate high-fidelity rendering results. At the same time, most applications such as games, animation, and AR/VR use mesh-based representa..

https://arxiv.org/abs/2402.00525 StopThePop: Sorted Gaussian Splatting for View-Consistent Real-time RenderingGaussian Splatting has emerged as a prominent model for constructing 3D representations from images across diverse domains. However, the efficiency of the 3D Gaussian Splatting rendering pipeline relies on several simplifications. Notably, reducing Gaussiaarxiv.org 이 글의 결론 (3문장)카메라를 돌릴 때..

https://huggingface.co/blog/gaussian-splatting Introduction to 3D Gaussian SplattingWe’re on a journey to advance and democratize artificial intelligence through open source and open science.huggingface.co 이 글의 결론 (3문장)3DGS는 신경망이 아니라 미분 가능한 래스터라이저다. SGD로 최적화하지만 레이어가 없고, 학습되는 것은 가우시안 파라미터 그 자체다.병목은 연산량이 아니라 수백만 개를 매 프레임 깊이순으로 정렬하는 것이다. 그래서 프로덕션 렌더링 파이프라인 이식이 막혀 있다.입문 글이 "색은 RGB 3개"라고 쓴 부분을 그대로 받으..

지금까지 AI 하네스를 RTL 업무에 어떻게 붙일 수 있는지 여러 관점에서 정리했다.RTL을 읽히기 전에 무엇을 준비해야 하는지, AI가 RTL을 어떻게 오해할 수 있는지, 검증 포인트를 어떻게 뽑을지, 버그 리포트와 수정안을 어떻게 다룰지, 그리고 작업 로그를 어떻게 남길지까지 이야기했다.마지막으로 정리하고 싶은 말은 이것이다.AI를 잘 쓰려면 프롬프트 하나를 잘 쓰는 것보다, 반복해서 쓸 수 있는 하네스를 남기는 것이 더 중요하다.프롬프트는 그 순간의 질문이다.하네스는 반복 가능한 작업 구조다.RTL 업무에서 AI가 진짜 도움이 되려면, 매번 감으로 묻는 방식에서 벗어나야 한다.무엇을 입력하고, 어떤 형식으로 받고, 무엇을 사람이 검증할지 정해져 있어야 한다.1. 좋은 프롬프트보다 좋은 구조가 오래 ..

AI를 RTL 업무에 붙여보면 꽤 놀랄 때가 있다.코드를 요약하고, 테스트 실패 로그를 정리하고, 리뷰 질문을 만들고, 수정 후보까지 제안한다.예전에는 사람이 한참 붙잡고 있던 정리 작업을 훨씬 빠르게 처리해준다.그러다 보면 자연스럽게 이런 질문이 나온다.“이러면 RTL 엔지니어의 역할이 줄어드는 거 아닌가?”내 생각은 조금 다르다.AI가 좋아질수록 RTL 엔지니어의 역할은 사라지는 것이 아니라, 더 중요한 쪽으로 이동한다.단순히 코드를 많이 읽고 많이 정리하는 능력보다, 무엇이 맞는지 판단하고 검증 기준을 세우는 능력이 더 중요해진다.1. AI는 빠르지만 책임을 지지는 않는다AI는 빠르다.긴 RTL을 요약하고, 반복되는 로그를 묶고, 테스트 후보를 만들고, 문서를 정리하는 속도는 사람이 따라가기 어렵다..

칩 개발 일정은 늘 여유롭지 않다.RTL을 작성하고, 테스트를 만들고, 실패를 보고, 수정하고, 다시 regression을 돌린다.중간중간 설계 리뷰도 해야 하고, 문서도 정리해야 하고, 다른 팀과 인터페이스 조건도 맞춰야 한다.이 흐름 안에서 AI를 쓰면 이런 기대가 생긴다.“AI를 붙이면 일정이 확 줄지 않을까?”어느 정도는 맞다.하지만 정확히 말하면 AI가 모든 일정을 줄여주는 것은 아니다.AI가 잘 줄여주는 시간은 따로 있다.바로 반복해서 읽고, 정리하고, 비교하고, 확인하는 시간이다.1. AI는 일정을 마법처럼 줄여주지 않는다AI를 도입할 때 가장 위험한 기대는 “이제 AI가 대신 해주겠지”라는 생각이다.RTL을 대신 다 짜주고, 검증 포인트를 알아서 뽑고, 버그 원인을 찾아서 고치고, 리뷰 자..

AI를 RTL 업무에 붙이면 생각보다 많은 일을 빠르게 할 수 있다.RTL 코드를 요약하게 할 수 있고, 테스트 실패 로그를 정리하게 할 수 있고, 리뷰 질문을 만들게 할 수 있다.때로는 수정 후보를 제안하게 할 수도 있다.그런데 여기서 놓치기 쉬운 문제가 하나 있다.AI와 어떤 대화를 했는지, 어떤 입력을 줬는지, 어떤 답을 받았는지, 그중 무엇을 채택했고 무엇을 버렸는지가 남아 있지 않으면 나중에 다시 파야 한다는 점이다.처음에는 빠르게 일한 것처럼 보인다.하지만 며칠 뒤 같은 이슈를 다시 보면 이런 생각이 든다.“이 판단을 왜 했지?”“AI가 말한 걸 믿은 건가, 내가 확인한 건가?”“이 테스트는 실제로 돌린 건가, 돌려야 한다고만 한 건가?”그래서 RTL 업무에서 AI를 쓸수록 작업 로그 하네스가..

이전 글에서는 RTL 버그를 AI에게 바로 맡기기보다, 먼저 AI가 읽을 수 있는 구조로 정리해야 한다고 이야기했다.그다음에 자연스럽게 따라오는 질문이 있다.“그럼 AI가 수정안까지 만들어주면, 그걸 그대로 반영해도 될까?”결론부터 말하면, 그대로 믿으면 위험하다.하지만 잘 다루면 꽤 쓸모 있다.AI가 만든 RTL 수정안은 정답이라기보다 검토할 후보에 가깝다.하네스의 역할은 그 후보를 바로 코드에 넣는 것이 아니라, 검증 가능한 변경 단위로 바꾸는 것이다.1. AI 수정안은 정답이 아니라 후보에 가깝다AI가 RTL 코드를 보고 수정안을 제안하면 꽤 그럴듯해 보일 때가 많다.조건문을 하나 추가하거나, enable 조건을 보강하거나, reset 값을 정리하거나, 특정 상태 전이 조건을 바꾸는 식이다.diff..

RTL 업무에서 AI를 쓰다 보면 한 번쯤 이런 생각을 하게 된다.“이 버그 로그를 AI에게 주면 원인을 바로 찾아주지 않을까?”가능할 때도 있다.하지만 실무에서는 이 기대를 그대로 가져가면 꽤 위험하다.RTL 버그는 에러 메시지 하나로 설명되지 않는 경우가 많다.어떤 테스트 조건이었는지, reset 이후 어느 구간이었는지, 기대한 동작과 실제 파형이 어디서 갈라졌는지까지 함께 봐야 한다.즉, AI에게 버그를 맡기기 전에 먼저 해야 할 일이 있다.버그를 AI가 읽을 수 있는 구조로 바꾸는 것이다. 1. RTL 버그는 찾는 것보다 전달하는 게 어렵다버그를 발견한 사람은 이미 많은 맥락을 알고 있다.어떤 테스트를 돌렸는지, 어느 로그가 중요해 보였는지, 어느 cycle 근처가 이상했는지, 정상 동작이라면 무..