현재 검증 구성은 M=32 구면 장면과 1280×720@60Hz HDMI입니다. 구면 셀 분할도, 원본 앱 해상도, 창 각도 크기와 HDMI 해상도는 서로 다른 값입니다.
화질과 갱신 범위
20×211×32² = 4,321,280개의 삼각 셀을 사용합니다. M=16보다 셀 수는 네 배지만 매 갱신마다 전체를 다시 투영하지 않습니다. AA는 계단 현상을 줄이며 RGB332의 색상 단계나 원본 글꼴의 픽셀 수를 늘리지는 않습니다. 둥근 창은 캐시된 coverage mask를 사용합니다.
최신 통합 빌드 리소스 · 2026-10-18
| 자원 | 사용 / 전체 | 사용률 |
|---|---|---|
| LUT | 36,374 / 53,200 | 68.37% |
| FF | 43,905 / 106,400 | 41.26% |
| BRAM36 | 50 / 140 | 35.71% |
| DSP | 155 / 220 | 70.45% |
| Slice | 12,576 / 13,300 | 94.56% |
Output Core, 투영코어 2개, 센서·버스·VDMA 등을 포함한 전체 설계 수치입니다. 회전·반전 추가 전보다 LUT 602개, FF 678개가 늘었고 BRAM/DSP는 같습니다. 100MHz에서 최종 setup slack +0.032ns, hold slack +0.010ns로 통과했습니다. 초기 setup -0.007ns 결과는 배포하지 않았으며 물리 최적화·재배선 후 같은 기준으로 재검증했습니다. Slice 배치 여유와 타이밍 여유는 작은 편이므로 LUT 잔량만으로 확장 가능성을 판단하지 않습니다.
기능 검증과 실제 측정의 구분
| 검증 시점 | 조건 | 확인 결과 |
|---|---|---|
| 10월 18일 · 최신 변환 빌드 | HDMI 캡처 16조합 + IMU/API 16조합 | 모두 통과, 추가 창 투영 0, lock loss 0, 추가 underflow 0 |
| 10월 18일 · 최신 변환 빌드 | 증분 보드 검사 14개 | 전체 72타일 대신 부분 수정 5타일, 무변화는 투영·commit 0, 캐시/출력 비교 불일치 0 |
| 10월 17일 · 직전 scanout 빌드 | 픽셀 생성 4.0035초 정지 | 새 생성 프레임 0, HDMI 240프레임, 캡처 화면 유지 |
| 10월 17일 · 직전 scanout 빌드 | 자세 13개 | HDMI 59.81~59.97Hz, 추가 underflow·lock loss 0 |
scanout 시작 전 빈 파이프라인의 underflow 1회와 동작 중 추가 이벤트를 구분합니다. HDMI가 이전 화면을 반복할 수 있으므로 HDMI 60Hz가 새 앱 내용 60FPS를 의미하지 않습니다.
이전 부분 갱신 시간 실측 · 10월 17일
128×96 원본, 24°×24° 시험 창에서 8×8 수정은 5개 투영 타일·3개 출력 타일·832 words 전송이었습니다. 합성 약 21ms, 합성+전달 약 40~54ms였습니다. 최초 표시는 72타일 투영에 합성 330.34ms·합성+전달 410.33ms, 창 이동은 해당 창 72타일 투영에 합성 325.69ms·합성+전달 451.81ms였습니다. 다른 창의 캐시는 재사용하며 부분 갱신 시간으로 이동 비용을 설명하지 않습니다.
별도 BoAYo 시험은 640×440 표면의 8×8 수정에서 RGB 192 bytes, 3개 투영 타일·1개 출력 타일, 합성 약 22ms, 합성+전달 약 41ms였습니다. 앱 present부터 출력 승인 관측까지 약 129ms는 폴링/IPC가 포함된 값으로 input-to-photon 측정이 아닙니다. 모두 당시 단일 사례이며 최신 빌드의 평균·최악 지연 보장이 아닙니다.
최신 리소스·해시 · 최신 검증 · 직전 scanout 검사 · 증분 시간 측정 조건 · BoAYo 사례