드디어 WebGPU를 Chromium에서 구현하나 보다. (관련글)


다음은 bink-dev에 올라온 글의 일부이다. 애플이 WebKIt에 Metal을 이용해서 만든 WebGPU와 얼마나 비슷한지 궁금하다. 같은 이름인 것으로 보아 애플의 제안이 많이 받아들여진 것 같다. 


Spec:

Work-in-progress IDL: https://github.com/gpuweb/gpuweb/blob/master/design/sketch.webidl

The “GPU for the Web” community group is approaching resolution on most-high level issues, but hasn’t looked at the detail or user-experience of the API yet.


Summary

The WebGPU API is the successor to the WebGL and WebGL 2 graphics APIs for the Web. It will provide modern features such as “GPU compute” as well as lower overhead access to GPU hardware and better, more predictable performance. WebGPU is being developed by the “GPU for the Web” W3C community group.


Motivation

Applications on the Web are becoming ever more interactive, which increases the demand for programmable 3D graphics, image processing, and GPU access in general. WebGL and WebGL 2 fulfill some of this demand, but do not match the features or performance of modern native graphics APIs.


WebGPU will close the gap in terms of performance, and introduce “GPU compute” functionality to the Web. This will help porting native applications to WASM that require native features, and will unlock the performance of GPU-accelerated scientific computing on the Web (including machine learning).


In addition WebGPU will give developers more predictable performance by being in the style of “explicit GPU APIs” and by being designed to map efficiently on all modern native graphics APIs.


TAG 3d, GPU, webkit
처음 개발자로서 일할때는 모든 프로젝트가 정말 바닥부터 코딩을 했다. 한마디로 main으로 코딩을 시작했다. 이런 코딩은 아주 재밌다. 내가 모든 것을 지배하니까..
그런 즐거움도 잠시 대기업이 들어간 이후 부터 지금까지 남들이 짜 놓은 방대한 코드에 뭔가 기능을 구현해야했다. 이때 부터 본격적인 코드 읽기가 시작되었다. 방대한 코드를 이해하는 것은 쉽지 않다. 그냥 코드만 읽어서는 절대 이해할 수 없는 것이 코드 읽기다. 오죽하면 이런 책도 있다.  그래서 지금까지 경험한 것을 잠깐 공유하려고 한다.

1.gdb로 step into를 통해 프로그램 동작을 이해한다.
call graph를 복사해 놓고 sequence diagram을 그려 놓으면 좋다. 이것을 바탕으로 class diagram을 그려놓고 프로그램 전체 구조를 이해한다. 그리고 layered architeture diagram을 그려 놓는 것도 좋다.

2. 버그를 잡는다.
오픈소스인 경우 버그를 잡아본다. 그러면서 코드를 이해한다. 버그를 잡은 경우에는 어떻게 잡았는지 잘 문서화 해 놓는다. 이렇게 여러군데 버그를 잡다보면 부분 부분 이해가 늘어나고 어느새 전체 구조를 이해하게된다.

3. 기존 문서나 비디오 등을 꼭 본다.
기존 개발자가 만들어 놓은 기술 문서, 기술 토크 비디오를 찾아서 질리도록 본다. 사실 코드가 자주 바뀌지만, 대부분 문서를 아주 자세한 경우가 드물기 때문에 좀 오래된 문서들도 도움이 된다.

4. 프로젝트내에 있는 작은 데모, 테스트케이스 코드를 본다.
이들 프로그램은 꼭 필요한 코드만 담겨져 있어서 이해가 쉽다.

5. Design Pattern에 익숙해진다.
많은 프로젝트가 익숙한 Design Pattern을 사용한다. 디자인 패턴에 익숙할 수록 코드 이해가 빠르다.

6.  Concurrent programming, IPC에 익숙해진다.
Chromium이 Multiple Process Model을 도입한 이후, 프로그램 동작을 이해하기가 까다로워졌다.

7. API에 익숙해진다.
당연한 이야기지만, 윈도면 윈도 API, 유닉스면 POSIX API에 익숙해져야 한다..

8. Domain knowledge에 익숙해진다.
웹브라우저를 개발한다면, 웹기술에 익숙해져야 하듯이, 게임을 만든다면, 게임 자체를 이해해야 한다.

9. Refactoring을 해본다.
한동안 Blink Editing component을 기여한적이 있었다. Chromium 코드 가운데 복잡하기로 악명 높은 코드다. 여러 사람이 개발을 했고 Editing API가 표준화가 덜 된 탓도 있다. 어찌되었던 이런 시도는 코드 건강에 좋다.

지금 끝도 없는 방대한 코드를 보려다가, 그냥 두서 없이 정리해보았다. 자 이렇게 남의 코드를 볼 노력으로 그냥 나만의 프로그램을 만들자. ㅎㅎ

참고로 읽어본 글

'coding' 카테고리의 다른 글

남들이 짠 코드 읽기...  (0) 2018.05.06

크롬 브라우저 55 부터 file-picker가 modal로 뜹니다. 그전까지는 modal이 아니라 오동작하는 경우가 많았습니다. 대표적인 경우가 gmail에서 file attach하다가 다른 페이지로 이동할 수 있었지요. 실수로 이런 경우가 많았나봅니다. 처음 버그 수정 부터 계속 patch를 다듬고 reviewer를 위해 기술문서도 작성하는 등, 실제 patch가 반영되는데까지 1년이 넘게 걸렸습니다. 몇 번 land되었다가 2번 revert되고 이후 regression만 3번 정도 있어서 이 부분도 수정해야했습니다. 이번주에도 regression하나 수정했습니다. 직접적인 버그는 아니였지만.. gmail팀의 지원 사격이 없었으면 아직도 이 patch는 림보에 빠져서 영원이 못나올 뻔 했습니다. 어찌되었던 기쁘군요.


관련 버그


Patch

  • https://codereview.chromium.org/1624793002
  • https://codereview.chromium.org/2398723002/
  • https://codereview.chromium.org/2418733004/
  • https://codereview.chromium.org/2554133003/







티스토리 툴바