드디어 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.

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

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가 표준화가 덜 된 탓도 있다. 어찌되었던 이런 시도는 코드 건강에 좋다.

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

참고로 읽어본 글

• https://dzone.com/articles/7-ways-to-improve-your-code-reading-skill

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

관련 버그

• System dialogs (e.g. 'Save As...') are not modal on Ubuntu
• [Regression]:Browser becomes unresponsive on closing the "Save file" dialog

Patch

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

얼마전 크로미움 프로젝트 커미터(Chromiun Project Committer)가 되었다. 프로젝트에 기여한지 3년이 되었지만, 사실상 다른 업무로 많은 기여를 하지 못했다. 올해 어느 정도 여유가 생겨서 평소에 관심이 있었던 Blink엔진의 Editing 부분에 집중적으로 기여했다. 

어느 오픈소스 프로젝트나 커미터가 되려면 많은 노력이 필요하다. 어떻게 보면 쉽고 어떻게 보면 어렵다. 크로미움 프로젝트의 경우, 주요한 10개의 patch를 기존 커미터들이 평가하는데, 반대 없이 3명 이상의  +1을 받아야 한다.  기여한 patch의 개수는 중요하지 않다.  실제 버그를 수정하고, Feature를 개발하고 성능을 높이고, refactoring도 큰 수준으로 해야 다른 커미터로 부터 커미터 지명을 받을 수 있다. 사실 구글 직원이 아니면 이런 기여를 하기가 쉽지 않다. 누가 멘토를 해주는 것도 아니고, 자기 스스로 문제를 찾고 feature를 개발해야 하는데, 구글의 허락 없이는 feature를 추가하는 것은 불가능하다. 주요 feature들은 이미 Googler들에게 할당되어 있기 때문에 새로운 분야를 찾는 것 역시 어렵다. 그래서 가장 쉬운 것이 버그를 잡는 것이다. Issue Tracker에 등록된 버그를 해결하는 것이 빠른 일이지만, 사실상 Googler들이 해결 안하는 버그들 역시 고치기 어려운 것이 대부분이다. :-( 하지만, 기역할 분야를 결정하고 하나 하나 버그를 잡다보면 코드를 이해하게 되고, 비슷한 버그를 쉽게 수정할 수 있다. 이때, 가능한 많은 사람들이 관심을 가져주는 급한 버그를 해결하면 더 의미가 있다. 아래는 이번에 커미터가 되기 위해 제출한 주요 patch 목록이다.

Blink Editing

1. [Issue 226941] Contenteditable issues related to backspace handling
• https://codereview.chromium.org/2064473002
• https://codereview.chromium.org/2117663002
2. [Issue 318925] Copy and paste sometimes removes spaces between words

• https://codereview.chromium.org/2193033004
• https://codereview.chromium.org/2280513004
• https://codereview.chromium.org/2320533002
• https://codereview.chromium.org/2325553002
• https://codereview.chromium.org/2336043006

3. [Issue 310149] ContentEditable:   is forced on SPACE between text nodes
• https://codereview.chromium.org/2175163004
4. [Issue 335955] Unwanted spans inserted in contentEditable elements
• https://codereview.chromium.org/2072093002
5. [issue 571420] chrome hangs on when creating bullet list in contenteditable
• https://codereview.chromium.org/2250133004

6. [Issue 634482] Formatting tags converted to spans with styles on cut/paste
• https://codereview.chromium.org/2229703004
7. [Issue 625802] Unnecessary quote appears after clicking on indent more option in compose box.
• https://codereview.chromium.org/2175433002
8. [Issue 582225] document.queryCommandState isn't working well with <sub> and <sup>
• https://codereview.chromium.org/1986563002
9. [Issue 584939] document.queryCommandState returns true for bold, italic, underline, and strikethrough after selecting image
• https://codereview.chromium.org/1960553002
10. [Issue 385374] queryCommandState can return true for both list types
• https://codereview.chromium.org/2268843002

Linux and Wayland support

1. [Issue 408481] System dialogs (e.g. 'Save As...') are not modal on Ubuntu
• https://codereview.chromium.org/1624793002/
2. [Issue 473228] Make *::ShowWithWindowState(minimized, maximized, fullscreen) consistent across platforms
• https://codereview.chromium.org/1125383008
• https://codereview.chromium.org/1138383008
• https://codereview.chromium.org/1159703006
• https://codereview.chromium.org/1130033003
3. Issue 578890 upstream wayland backend for ozone
• https://codereview.chromium.org/204250300

한국인 크로미움 커미터는 이미 9명이 있다. 많은 대기업에서 크로미움 기반으로 브라우저를 개발하고 있어서 그 수가 많은 편이다.  이렇게 다양한 사람들이 함께 내가 사용하는 웹브라우저를 개발한다는 것이 오픈소스가 주는 매력이 아닐까 싶다. 지금 이 순간도 수 많은 사람들이 크롬 브라우저에서 문서를 편집할 때 마다, 내가 추가한 코드가 실행된다고 생각하면 개발자로서 이 보다 보람찬 일은 없을 것이다.

오픈소스의 가장 큰 장점은 외부로 부터 참여를 이끌어내는 것이다. 일반적인 참여 방식으로 버그 찾거나 잡는 것이 있지만, 프로젝트를 소개하고 사용법을 알려주는 글도 프로젝트를 운영하는 사람들 입장에서 큰 도움이 된다. 우연찮게 Crosswalk을 소개한 블로그를 찾게 되었다. 단순히 소개만 한 것이 아니라 집적 patch를 올린 과정도 상세하게 소개해서 오픈소스에 프로젝트 기여하고 싶은 개발자에게 도움이 될 것 같아 여기 소개한다.

• WELCOME TO THE “CROSSWALK”
• CROSSWALK에 컨트리뷰션 하기 – (1,2) CROSSWALK 소개
• CROSSWALK에 컨트리뷰션 하기 – (3-1) 특징
• CROSSWALK에 컨트리뷰션 하기 – (3-2) 코딩스타일
• CROSSWALK에 컨트리뷰션 하기 – (3-3) 코드 컨트리뷰션 프로세스
• CROSSWALK에 컨트리뷰션 하기 – (4) 커뮤니티 참여 방법
• CROSSWALK에 컨트리뷰션 하기 – (4) 커뮤니티 참여 방법
• CROSSWALK에 컨트리뷰션 하기 – (5-1) ARCHITECTURE OVERVIEW
• CROSSWALK에 컨트리뷰션 하기 – (5-2) CROSSWALK EXTENSIONS
• CROSSWALK에 컨트리뷰션 하기 – (5-3) WEB API EXTENSIONS 비교
• CROSSWALK에 컨트리뷰션 하기 – (5-3) WEB API EXTENSIONS 비교
• CROSSWALK에 컨트리뷰션 하기 – (6) 소스코드 다운로드 및 빌드
• CROSSWALK에 컨트리뷰션 하기 – (7) 다른 사람 코드 리뷰 방법
• CROSSWALK에 컨트리뷰션 하기 – (8) 첫번째 코드 SUBMIT
• CROSSWALK에 컨트리뷰션 하기 – (9) SUMMIT 한 코드 관리하기
• CROSSWALK에 컨트리뷰션 하기 – (10) 돌아보며…

Source: https://joone-foss.blogspot.com/2013/03/blog-post.html

올해 블로그 업데이트가 뜸하다는 이야기를 들었다. 사실, 블로그를 안하는 것은 아닌데, 여기 보다 GNOME Korea 블로그에 글을 많이 올렸다. 여기 올라갈 것이 그쪽에 다 올라간 것이다.

올해 1월부터 6월까지 GNOME Tech Talks을 운영했다. 반응은 좋았고 지금은 홍영기님이 맡아서 운영해주시고 있다. 매달 세미나 결과를 GNOME Korea 블로그에 올렸고, 영문으로도 작성에서 다른 블로그에 올렸다.

• 1st GNOME Tech Talks
• 2nd GNOME Tech Talks
• 3rd GNOME Tech Talks
• 4th GNOME Tech Talks
• http://blogs.gnome.org/joone/2012/07/27/gnome-tech-talks-in-korea/

왜 이렇게 GNOME Korea에 활동에 열심이였을까? 그건 GNOME이 오픈소스 생태계에 중요한 역할을 하고 있다고 생각하기 때문이다. 아시다시피, Ubuntu, Fedora 등 대부분의 리눅스 배포판이 GNOME Desktop을 기반으로 하고 있으고, 리눅스 기반 모바일 플랫폼인 Maemo, Meego, Tizen 모두 GNOME Platform기반에 동작을 한다. 이외 DTV, eBook Reader와 같은 임베디드 장비에서도 사용되고 있다. 

사실 예전에는 Mobile Firefox에 대한 관심으로 Mozilla 커뮤니티 활동에 열심이였으나, Desktop Summit에 참석하고 GNOME Maintainer들을 만나면서 GNOME이 좀 더 큰 영향력을 갖는 오픈소스 프로젝트라는 생각이 들었다. Mozilla는 주요 개발자들이 Mozilla Corporation소속이라, 특히 개발자 그룹과 어울리는 것이 쉽지 않았다. 하지만, GNOME은 특별히 어느 회사가 이끄는 프로젝트가 아니라, 다양한 회사에서 투자하고 참여하는 프로젝트라 뭔가 더 자유롭고 활기가 넘친다. 특히 남미, 스페인쪽 친구들이 굉장히 활발하게 참여하는 부분이 매우 인상적이다. 물론, Mozilla도 무척 중요한 프로젝트이다. 다행히 Channy님이 다른 분들과 같이 잘 이끌주어서 활발하게 잘 운영되고 있다. 하지만, GNOME Korea는 그렇지 못했다. 바깥 분위기 달리 오프모임도 없었고 특별히 누가 주도적으로 리드한다는 느낌을 못받았다. 물론, 창우님 주도로 번역은 아주 활발하지만, Channy님 같이 외부와의 만남을 주도할 만한 역할이 없는 것이 아쉬웠다.  IRC, mailing list는 살아있었지만, 홈페이지가 죽어있어서 다른 사람들이 GNOME Korea 활동에 대해 알 수 있는 방법이 없었다.  우선, 홈페이지를 대충 만들고 사비를 털어 domain을 연장했다. 블로그도 만들고 오프 모임을 시작하기로 했다. 다행히 구글코리아에서 장소 지원을 받게 되어 비용 걱정 없이 매달 세미나를 운영할 수 있었다. 이 자리 빌어 감사를! 새로 옮긴 직장 때문에 미국에 오게 되어 현재는 영기님이 잘 맡아서 운영해주시고 있고 GNOME Asia Summit도 유치하게 되었다. 이 부분은 사실 나도 머뭇거린 부분인데, 유치한 후 뒷감당이 어떻게 할 수 있을까 하는 걱정때문이였다. 다행히 영기님이 주도적으로 유치에 힘쓴 결과, 베이징팀과 최종 경쟁에서 한국팀으로 결정되었다. 내년 5월말 GNOME Asia Seoul이 무척 기대가 된다.

사실 우리나라에 GNOME 개발자가 무척 많다. 우리가 사용하는 많은 전자 제품 내부에는 GNOME Project에서 개발된 코드들이 사용되고 있기 때문이다.  하지만, 이 분들이 밖으로 나와서 자신의 지식을 나누고 외부 활동도 하면 좋은데, 바쁜 회사일로 인해 그렇지 못해 아쉬웠다. 그래서 GNOME Tech talks을 통해 이 분들이 기존 커뮤니티와 만나고 함께 지식을 나누는 계기가 되기를 바랬고, 실제로 학생이나 취미로 개발하는 분들 뿐만 아니라, 프로 개발자 분들이 강의를 많이 해주셨다.

이 자리를 빌어 다시 한번 감사를! 그리고 그놈 한글 번역팀에도 무한한 감사를, 그 분들이 없으면 한글화된 우분투를 사용할 수 없었을 것이다.

2013년이 다가온다. 내년에 더 많은 우리나라 개발자 GNOME Project에서 활동하는 모습을 봤으면 좋겠고, GNOME Asia Seoul이 성공적으로 개최되기를 기원한다.