windows_driver_npu

이전 Windows Driver 시리즈에 이어서 실제 NPU를 컨트롤하는 windows driver를 만들예정이다. mcu와 하드웨어 가속기의 구조적 차이로 인해 실제 가속기 처럼 동작시키지는 못했다. 또한 usb를 활용했기때문에 PCIe 방식으로 구현해볼 예정이다.

tflite 모델은 내부가 FlatBuffers로 되어있다고 한다. google coral tpu에서 모델을 사용하기 위해서는 model 내부 구조의 bitstream을 뽑아서 맵핑을 시켜줘야 한다. google에서 제공해주는 libedgetpu를 사용하면 자동으로 해

windows driver를 계속해서 개발을 하고 있는데, 유의미한 추론 값이 나오고 나서 블로그를 정리해야지 하고 있었다. 너무나 어렵고 생각보다 프로젝트가 길어지고 있다. 그래서 지금부터는 만나는 문제에 대해서 조금씩 포스팅을 해보려고 한다. 진행 상황 전체적인

개발을 진행하며 문제가 발생했다. param cache와 infer descriptor를 정상적으로 submit 한다고 생각했는데 기존 libedgetpu처럼 정상적으로 추론이 되지 않고 garbage 값이 나오는 현상이 있다. 위 사진은 추론 값이다. 이전에 발생했던

libedgetpu의 face detection은 정상이다. 직접 만든 npu driver로는 모든 anchor score가 균일하게 나오는 버그가 있다. 이번에는 input dump를 통해서 비교해 볼 예정이다. 분석하기 전에 아래와 같은 내용을 알아야 하는 것 같다

추론 output 데이터 중 convert_scores가 계속 잘못된 값으로 나와서 상당히 쉽지 않다. 이번 포스팅에서는 정상으로 추론되는 libedgetpu에서 실제 input buffer를 bin파일로 만들어서 만들어진 파일을 개발 중인 npu driver에서 사용

convert scores가 계속 쓰레기로 나오는 문제, 이번에는 input도 아니고 weight도 아닌 descriptor ring / status block의 cache coherency 를 의심해봤다. libedgetpu (정상 동작)와 우리 driver (비정상

이전 포스팅에서 추론 버그라고 했던 convert_scores의 충격적인 사실을 발견했다. 아무리 Byte-identical로 바이트 단위로 정말 많은 CSR을 비교했다. input data의 CRC32

기존에는 console application에 mvp로 개발을 하였다. dll로 만들어서 여러 언어에서 사용할 수 있도록 개발할 예정이다. dll 개발 경험이 있어서 수월하게 만들 수 있었다. runtime dll의 가장 큰 역할은 npu_driver와의 통신을 래핑

google coral tpu의 온도 값을 읽어오는 기능을 구현했다. 어떤 흐름으로 구현했는지에 대해서 포스팅할 예정이다.npu_driver에 ioctl handler, hardware register offset, init 을 해준다. npu runtime dll에서