(간단한) 외부 입력에 대한 응답으로 간단한(2D 비트맵) 그래픽을 가능한 가장 짧은 대기 시간(약 수십 밀리초)으로 화면에 그려서 그림 결과를 경험적으로 테스트할 수 있습니다. 화면 가)실시간, b) 오버헤드를 최소화합니다. c) 페이지 뒤집기를 완전히 비활성화합니다(찢기는 괜찮습니다).
그런 다음 이를 X11, Wayland, Wayland+XWayland, Wayland+XWayland+xcompmgr 등과 같은 다양한 고정관념(그리고 아마도 병적일 수도 있음) 시나리오에서 화면에 그리는 것과 비교할 수 있습니다.
이를 위해 그림을 그릴 수 있도록 Linux를 어떻게 수정합니까?초과하다기존 X11/Wayland 세션이 있습니까? 즉, 네, DRM(Direct Render Manager)을 만지작거리고 싶습니다.
ㅏ.커널 내부에서,
만.X11에는 DRM 마스터 컨트롤이 있습니다.. :)
나는 하드웨어 오버레이가 X11/Wayland가 내가 그리는 모든 것에 낙서하는 것을 방지하는 가장 쉬운(그리고 대부분의 하드웨어 가속!) 방법이 될 것이라고 생각합니다. (다시 읽기를 피하기 위해 섀도우/연속 기입 프레임 버퍼 캐시를 구현하는 것과 관련된 대안을 상상하고 있습니다... 아니요, 감사합니다!)
나는 정말로 나의 열광을 커널 모듈로 제한하고 싶고 그래픽 드라이버를 만지작거리고 싶지 않습니다. :S (그런데 저는 i915이기는 하지만 Intel 그래픽 카드를 사용했습니다.)
그러니 끝까지 읽어보세요https://dri.freedesktop.org/docs/drm/,내 의견은아마도나는 뭔가를 하나로 모으고 싶습니다. 멍청한 프레임버퍼를 만들고, 그 멍청한 프레임버퍼를 관찰하는 평면을 만들고, 그런 다음어쩌면 두 배일지도일종의 DMA-BUF를 설정하세요... 아니요, 잠깐만요. 프레임 버퍼를 가리키는 평면이 있으면 이미 화면에 있는 것 같아요... 제 생각에는요?
내 주요 질문은 DRM을 빠르고 느슨하게 사용하여 기본적으로 이것이 화면과 대화하는 유일한 것임을 X에 알리고 뒤에서는 추가 평면을 관리하는 방법입니다.
답변해 주셔서 정말 감사합니다!
Wayland에 대한 현재 이해는 기본적으로 합성을 기반으로 하며 설계상 하나 이상의 전체 비디오 프레임을 그래픽 카드에 릴리스하기 전에 버퍼링하지 않고는 실행할 수 없다는 것입니다.
X11에는 이러한 제한이 없지만( COMPOSITE선택적 확장임) 스트림 기반 그리기 프로토콜을 사용하며 창에 직접 그릴 수 있는 방법은 없습니다. 내가 아는 가장 가까운 것은 MIT-SHM확장을 사용하는 것입니다. 이를 통해 공유 메모리를 사용할 수 있지만 여기에는 최소한 두 개의 메모리 복사본(me->커널, 커널->X11)이 포함됩니다.그런 다음X11 튜브를 찔러 XShmPutImageX11에게 뒤집으라고 지시합니다. 즉, 프로세스를 실시간으로 실행하더라도... 음, X를 실시간으로 실행하기에는 너무 겁이 나기 때문에 X가 예약되고 디코딩되어 도착할 때까지 기다려야 합니다. 내 요청이 명령 대기열 센터에 있었고 마침내 뒤집혔습니다.
그래서 나는 손을 뻗어 그래픽 그리기 코드를 커널에 직접 넣을 수 있는지 알아보고 어떻게든 모든 것이 공존할 수 있도록 노력했습니다.
이 모든 추가 오버헤드가 합산될 것으로 예상되며 정확하게 수량화하고 싶습니다.어떻게- 또는 내 정신 모델이 완전히 잘못되었으며 현대 하드웨어의 속도로 인해 이러한 우려가 무의미하다는 구체적인 증거입니다.
그래요극도로모든 병목 현상이 제거되면 어떤 영향이 있을지, 구형 시스템과 최신 하드웨어를 비교하면 어떤 차이가 있는지 알고 싶습니다.
그런데 이 질문은 제가 질문한 다른 질문과 관련이 있습니다.여기 있어요그리고여기 있어요, 불행하게도 이 두 가지 질문에 대한 답변이 아직 남아 있지 않으며 이에 대해 더 이상 논의하지 않았습니다.