최신 PC 비디오 하드웨어는 HW에서 VGA 텍스트 모드를 지원합니까, 아니면 BIOS가 에뮬레이션합니까 (시스템 관리 모드 사용)?


10

물리적 선형 주소 의 VGA 텍스트 (모드 03) 프레임 버퍼에 (0x31) 과 같은 바이트를 저장할 때 16 비트 레거시 BIOS MBR 모드로 부팅 된 최신 PC 하드웨어에서 실제로 어떤 일 발생 합니까? 해당 지역 MTRR 이있는 상점이 UC로 설정된 상점 은 얼마나 느립 니까? ( 하나의 Kaby Lake iGPU 랩톱에서 실험 한 테스트에 따르면 WC의 clflushopt는 VGA 메모리의 UC와 거의 같은 속도이지만, clflushopt가 없으면 WC 메모리에 저장하면 CPU를 떠나지 않고 화면을 전혀 업데이트하지 않고 초고속으로 실행됩니다 .)'1'B8000mov [es:di], eaxmov

모든 매장에서 SMI가 아닌 경우 실제 공간으로 실제로 재부팅하지 않고 성능 실험을 위해 사용자 공간의 WB 메모리 청크에 대해이 비용을 근사 할 수있는 방법이 있습니까? (예 : BSS 페이지를 실제로 어디에도 표시되지 않는 가장 한 프레임 버퍼로 사용)

해당 글꼴 글리프가 다음 새로 고침에서 화면에 나타나지만 실제로 하드웨어 스캔으로 VRAM (또는 iGPU의 경우 DRAM)에서 해당 ASCII 문자를 읽고 즉시 비트 맵 글꼴 글리프에 매핑합니까? 또는 각 저장소에서 또는 vblank 당 한 번 소프트웨어 차단이 발생하여 실제 하드웨어가 비트 맵 프레임 버퍼 만 처리해야합니까?


레거시 BIOS 부팅은 SMM (System Management Mode) 을 사용하여 USB kbd / mouse를 PS / 2 장치로 에뮬레이트하는 것으로 잘 알려져 있습니다. VGA 텍스트 모드 프레임 버퍼에도 사용되는지 궁금합니다. 나는 그것이 가정 되는 VGA I / 모드 설정을위한 O 포트를 사용하지만, 텍스트 프레임 버퍼는 하드웨어에 의해 지원 될 수 있음을 그럴듯합니다. 그러나 대부분의 컴퓨터는 그래픽 모드에서 모든 시간을 보내므로 텍스트 모드에 대한 하드웨어 지원은 공급 업체가 원하는 것처럼 보입니다. (OTOH 이 블로그 는 사제 verilog VGA 컨트롤러가 텍스트 모드를 상당히 간단하게 구현할 수 있다고 제안합니다.)

특히 Intel Skylake에서 iGPU를 사용하는 시스템에 관심이 있지만 Intel 및 AMD의 이전 / 이후 iGPU 및 새롭거나 오래된 개별 GPU에 관심이 있습니다.

(AMD 및 NVidia 이외의 공급 업체를 포함합니다. PCIe가 아닌 PCI 슬롯이있는 일부 Skylake 마더 보드가 있습니다. 최신 GPU 펌웨어 드라이버가 텍스트 모드를 에뮬레이트하는 경우 하드웨어 VGA 텍스트 모드가있는 오래된 PCI 비디오 카드가있을 수 있습니다. 상점을 SMI 대신 PCI 트랜잭션으로 만들 수 있습니다.)

내 자신의 데스크탑은 Asus Z170 Pro Gaming mobo의 i7-6700k이며 DVI-D 출력의 1920x1200 모니터가있는 iGPU 만 추가 카드가 없습니다. @Eldan이 테스트 한 Kaby Lake i5-7300HQ 시스템의 세부 사항은 CPU 모델 만 알 수 없습니다.


내가 발견 피닉스 BIOS의 특허 US20120159520을 2011 년부터 , UEFI를 사용하여 기존의 비디오를 에뮬레이션 . 비디오 하드웨어 공급 업체가 UEFI 기본 16 비트 리얼 모드 옵션 ROM 드라이버를 모두 공급하도록 요구하는 대신 int 10hSMM 후크를 통해 공급 업체가 제공 한 UEFI 비디오 드라이버를 호출하는 리얼 모드 VGA 드라이버 ( 기능 등)를 제안합니다 .

개요
[...] 일반 비디오 옵션 ROM은 비디오 서비스 요청의 일반 비디오 SMM 드라이버에 알립니다. 이러한 통지는 소프트웨어 시스템 관리 인터럽트 (SMI)를 사용하여 수행 될 수있다. 통지에 따라, 일반 비디오 SMM 드라이버는 비디오 서비스에 대한 요청을 제 3 자 UEFI 비디오 드라이버에게 통지한다. 타사 비디오 드라이버는 요청 된 비디오 서비스를 운영 체제에 제공합니다. 이러한 방식으로, 제 3 자 UEFI 그래픽 드라이버는 UEFI 디스플레이 프로토콜을 기본적으로 지원하지 않는 운영 체제까지 다양한 운영 체제를 지원할 수 있습니다.

대부분의 설명은 int 10h이미 IVT를 통해 트래핑하는 호출 및 항목 처리를 다루 므로 SMI를 의도적으로 트리거하는 사용자 지정 코드를 쉽게 실행할 수 있습니다. 관련 부분은 텍스트 모드 프레임 버퍼에 직접 저장하기 위해 설명하는 것으로 소프트웨어 또는 하드웨어 인터럽트를 트리거하지 않는 코드에서도 작동해야합니다. (해당 상점에서 SMI를 트리거하는 HW 이외의 경우 지원되는 경우 사용할 수 있다고 말합니다.)

텍스트 버퍼 지원

특정 실시 예에서, 애플리케이션은 VGA의 텍스트 버퍼를 직접 조작 할 수있다 . 이러한 실시 예에서, 일반 비디오 SMM 드라이버 (130) 는 하드웨어 가 740 KB-768 KB 메모리 영역 (텍스트 버퍼가 위치하는) 에 대한 읽기 / 쓰기 액세스에 대한 SMI 트래핑을 제공하는지에 따라 두 가지 방식 중 하나로이를 지원 한다 .

SMI 트래핑이 이용 가능할 때, 하드웨어는 각각의 읽기 또는 쓰기 액세스마다 SMI를 생성한다. SMI 트랩의 트랩 주소를 사용하여 정확한 텍스트 열과 행을 계산하고 가상 텍스트 화면의 해당 행과 열에 액세스 할 수 있습니다.

대안 적으로, 정규 메모리가이 영역에 대해 활성화되고, 주기적 SMI를 사용하여, 일반 비디오 SMM 드라이버 (130)는 에뮬레이트 된 하드웨어 텍스트 버퍼에서의 변화를 스캔하고 비디오 드라이버에 의해 유지되는 대응하는 가상 텍스트 스크린을 업데이트한다. 두 경우 모두 변경 사항이 감지되면 가상 텍스트 화면에서 문자가 다시 그려집니다.

이것은 BIOS 공급 업체의 특허 중 하나이며 대부분의 하드웨어가 실제로 작동하는 방식이나 다른 공급 업체가 다른 작업을 수행하는지 여부는 알려주지 않습니다. 그래도 해당 범위의 매장을 잡을 수있는 일부 하드웨어가 존재 하는지 확인합니다 . (이것이 특허에서 다루기로 결정한 가상의 가능성이 아니라면)

유스 케이스의 경우 화면 새로 고침에서만 트랩하는 것이 모든 상점에서 트랩하는 것보다 훨씬 빠를 것이므로 어떤 하드웨어 / 펌웨어가 어떤 방식으로 작동하는지 궁금합니다.


이 질문에 대한 동기

7 세대 인텔 코어의 비디오 RAM에서 증가하는 ASCII 10 진수 카운터 최적화 -ASCII 텍스트 카운터의 새 숫자를 동일한 몇 바이트의 비디오 RAM에 반복적으로 저장합니다.

Linux에서 WB 메모리의 32 비트 사용자 공간에서 코드 버전을 테스트하여 movnti각 상점 후 (또는 때로는 타이머 인터럽트). 그러나 리얼 모드 부트 로더 상황이 DRAM에만 저장되는 것이 아니라 SMI를 트리거하는 경우에는 현실적이지 않습니다.

WB 메모리에서을 movnti사용한 플러시 는을 사용한 lock xor byte [esp], 0플러싱보다 약간 빠릅니다 clflushopt. 그러나 @Eldan은 MTRR을 WC로 프로그래밍 한 후 VGA 메모리에있는 사람들에게는 속도 향상이 없다고보고했다. (그리고 원래의 일반 저장소와 동일한 속도로 기본적으로 VGA 프레임 버퍼는 UC임을 나타냅니다. 일부 구형 BIOS 는 VGA 메모리를 WC로 만들 수있는 옵션이있었습니다 .

실제 문제가 아니므로 실제 해결 방법을 찾지 않습니다 . 수동으로 픽셀 바이트를 VGA 그래픽 모드로 저장하는 것이 훨씬 빠를 지 아는 것은 흥미로울 것입니다.


요약

  1. 모든 실제 현대 시스템이 모든 매장에서 텍스트 모드 프레임 버퍼로 SMI를 트리거합니까?
  2. 그렇지 않다면 WB 메모리의 사용자 공간에서 movnti + 무언가를 사용하여 프레임 버퍼에 WC store + clflush를 근사 할 수 있습니까? 따라서 perf성능 카운터를 쉽게 프로파일 링 할 수 있습니다 .
  3. 다른 BIOS 및 / 또는 하드웨어가 다른 전략을 사용하는 경우 해당 전략은 무엇입니까? ( "VGA 프레임 버퍼를 실제 하드웨어 프레임 버퍼에 동기화하기위한 모든 vblank SMI"와 같은 세부 사항은 원하지 않습니다.)
  4. 하드웨어 VGA 텍스트 모드가있는 PCIe 또는 PCI 비디오 카드가 통합 GPU가 실제로하는 것보다 더 빠릅니까? 실제 PCIe 쓰기 트랜잭션은 매장이 DRAM에 도달하기를 기다리는 것보다 느릴 것으로 생각하지만 PCIe 쓰기는 모든 상점의 SMI보다 저렴합니다. 야구장 / 크기 순서 비교는 흥미로울 것입니다.

이 질문은 모두 관련이 있지만 예상만큼 겹치지 않으면이 질문을 나눌 수 있습니다.


SMI에 대한 성능 카운터가 없습니까?
prl

@ prl : 예, 그렇게 생각합니다. 실제로 perf 카운터를 프로그래밍하는 부트 로더를 작성하고 테스트 실행 후 수집 및 인쇄 한 다음 데스크탑을 재부팅하여 실행하면 내 데스크탑에 대한 답변을 찾을 수 있습니다. perf리눅스가 아직 부팅되지 않았기 때문에 분명히 사용할 수 없습니다 . Linux-CentOS / Intel 시스템에서 SMI (System Management Interrupt) 대기 시간 평가에는 SMI 계산 방법에 대한 세부 정보가 있습니다.
Peter Cordes

1
@prl : 실제로 SMI를 계산하는 것이 더 쉽습니다. 분명히 perf 카운터가 아닌 MSR이 있으므로 MSR_SMI_COUNT=0x34카운터를 먼저 프로그래밍하지 않고도 RDMSR 만 있습니다.
Peter Cordes

SMI를 감지하기 위해 섹션 34.15에 설명 된 기술을 사용하는 것이 다른 아이디어보다 훨씬 쉽습니다.
prl

@ prl : 인텔 vol.3 SDM의 34.15입니다. xem.github.io/minix86/manual/intel-x86-and-64-manual-vol3/… 은 "베어 메탈 (bare metal)"의 오래된 SMM뿐만 아니라 SMM이 VMEXIT를 유발하거나 VMEXIT에 관여하는 경우를 설명하는 것으로 보입니다. (또는 레거시 BIOS 부팅이 SMM 트랩을 통해 제공하는 가짜 베어 메탈 ...) 어쨌든, 다음 번에 데스크톱을 재부팅 할 필요가 없다면 16 비트 부트 로더를 작성하여 시스템에서 테스트 할 수 있습니다. ... 또는 다른 누군가가 예리한 느낌을 받고 그것을 시험해 보길 바랍니다.
Peter Cordes

답변:


7

모든 실제 현대 시스템이 모든 매장에서 텍스트 모드 프레임 버퍼로 SMI를 트리거합니까?

비디오 카드의 경우, 나는 그것을 의심합니다. 비디오 카드 제조업체는 1980 년대 이후로 하드웨어에 내장 된 "문자 + 속성에서 픽셀 데이터 가져 오기"논리를 가졌으며 (VGA 이전이며 CGA 이후 크게 바뀌지 않았습니다), 그 논리를 신경 쓰지 않고 새로운 디자인으로 잘라내어 붙여 넣기 만하면됩니다. .

비디오 카드가 아닌 것 (예 : LAN을 사용하는 원격 시스템 관리 도구)에 대해서는 잘 모르지만 의심하지 않습니다 (주로 CPU가 아닌 특수 관리 CPU를 사용하여 컴퓨터가 작동하더라도 작동 함) 껐다").

그렇지 않다면 WB 메모리의 사용자 공간에서 movnti + 무언가를 사용하여 프레임 버퍼에 WC store + clflush를 근사 할 수 있습니까?

사용자 공간이 아닌 경우 MTTR을 변경하여 (모든 CPU에서-MTRR이 일치해야하고 특별한 순서가 관련되어 있음) RAM 영역을 "미사용"으로 만들 수 있습니다. 또는 페이지 테이블에서 PAT를 사용하십시오 (특히 페이징을 사용하는 경우 MTRR을 망쳐 놓는 것보다 훨씬 쉽지만 여전히 캐시 일관성이 필요하기 때문에 약간 다른 동작). 사용자 공간에 있다면 OS / 커널이 제공하는 것에 의존해야하고 OS에 따라 OS / 커널이 전혀이 방법을 제공하지 않을 수 있습니다.

하나; RAM을 캐시하지 않는 방법을 찾더라도 CPU에 내장 된 메모리 컨트롤러에 연결된 무언가에 직접 쓰므로 CPU가 매우 빠르게 쓸 수 있기 때문에 여전히 비슷하지 않습니다. )는 PCI 링크의 다른 쪽 끝에있는 무언가 (대기 시간이 길고 CPU 쪽의 대역폭이 낮음)와 대화하는 대신. 통합 비디오 (기술적으로 동일한 RAM 칩인 경우)는 VRAM에 대한 쓰기가 매우 다른 경로를 통과합니다 (비디오 카드의 리매핑 / GART / 페이징에 따라 "쓰기 모드"VGA 레지스터의 영향을 받음) 비트 / 평면 마스크 VGA 레지스터 등).

하드웨어 VGA 텍스트 모드가있는 PCIe 또는 PCI 비디오 카드가 통합 GPU가 실제로하는 것보다 더 빠릅니까?

CPU에서 VRAM으로 쓰는 경우; 일반적으로 통합 비디오는 이산 카드보다 훨씬 빠릅니다 (최소한 VGA의 "쓰기 논리"가 포함되지 않은 CPU에서 선형 프레임 버퍼로 일반 쓰기의 경우).

매우 거친 야구장 추정 RAM에 대한 단일 쓰기는 약 150주기이고 PCI에 대한 단일 쓰기는 1000주기에 가깝습니다. SMI의 경우 SMI가 CPU에 도달하기 전에 수백 사이클의 대기 시간이 예상되고 CPU 파이프 라인 플러시 비용이 발생하고 CPU 상태를 저장하기 위해 약 500 사이클이 반환됩니다 (반환 경로에서 동일한 로딩 상태). 펌웨어 코드는 SMI의 원인 (다른 수백 사이클?)을 찾아야 VRAM에 쓰이고 다른 것이 아니라는 것을 알 수 있습니다. 그런 다음 저장된 CPU 상태를 검사하고 (쓰기 작업을 수행하는 동안 어떤 데이터가 쓰여 졌는지 알 수 없으므로 바이트 / 워드 / 워드 쓰기 등) 명령을 찾아서 디코딩해야합니다. 이전 CPU 상태 (CPU 모드, 코드 크기,XADD등). 다음으로 (에뮬레이트 된) VGA 레지스터의 상태 (쓰기 모드, 쓰기 마스크, 평면 활성화, 레거시 영역, 글꼴 높이 등 64 KiB 뱅크에 매핑되는 모든 컨트롤)를 분석해야합니다. 원래; 텍스트 기록 프레임 버퍼에 대한 SMI 에뮬레이션; 펌웨어 코드가 복잡성에 묻혀있는 사소하지만 중요한 세부 사항을 간과하기 때문에 수만 번의주기가 걸릴 것으로 예상됩니다.

기타 사항

2011 년부터 Phoenix BIOS의 특허 US20120159520, uefi를 사용하여 레거시 비디오 에뮬레이션을 발견했습니다.

나는 이것이 작동 할 수 있다고 의심하기 때문에 이것이 구현되었는지 의심합니다. 레거시 인터페이스로 할 수있는 일이 너무 많습니다 (예 : 수직 새로 고침, "mode X"와 같은 비표준 비디오 모드 설정, "디스플레이 시작"이있는 바이올린, 부드러운 스크롤 및 / 또는 페이지 뒤집기 구현) , UEFI에서 지원하지 않고 VFI에서 지원되지 않는 비디오 타이밍 등을 변경하려면 VBE에서 "CRTC 정보"를 사용하십시오. UEFI 용 타사 비디오 드라이버

대신 비디오 카드 제조업체는 약 10 년 동안 UEFI 드라이버를 제공하지 않았으며 UEFI 펌웨어는 레거시 인터페이스를 사용하여 UEFI 서비스를 에뮬레이션했습니다 (종종 보안 부팅이 중단 된 상태에서 보안 부팅 중단). 어쨌든 거의 모든 것이 UEFI가 될 때까지.

모드 설정을 위해 VGA I / O 포트에 (SMM)을 사용한다고 가정합니다.

나는 그렇지 않다고 가정합니다. SMM이 사용될 것으로 의심되는 비디오와 모호하게 관련된 유일한 것은 초기 부팅 (OS 이전) 동안 랩톱 (특히 오래된 랩톱, 특히 "열림 / 닫기 이벤트")에서 화면의 백라이트 밝기를 제어하는 ​​것입니다. 대신합니다).

.. 텍스트 모드에 대한 HW 지원을 제외하면 벤더가 원하는 것으로 보입니다.

나는 여전히 하드웨어에서 30 년 이상 축적 된 레거시 엉망 (A20, VGA, PS / 2, PIT, PIC 등)을 (아직 너무 긴 "하이브리드 BIOS + UEFI"전환 단계 이후) 제거했다고 믿는다. 하드웨어 제조업체 (인텔)가 UEFI 채택을 추진하고있는 주요 이유 중 하나입니다.


레거시 VGA 범위는 L3 캐시 슬라이스에 의해 구성 레지스터의 VGA 스티어링 비트를 기반으로 한 프로세서 그래픽, DMI 또는 PCIe 링크로 직접 디코딩됩니다. VGA가없는 경우 프로세서 그래픽이이 범위에서 어떻게 작동하는지 잘 모르겠습니다. 아마도 단지 버퍼 그것과는 HDMI 프레임 버퍼로 변환하고 HDMI FDI 파이프로 전송하지만 단서 없어
루이스 켈시

고마워, 나는 여전히 하드웨어 지원 가능성을 간과했지만 시스템 에이전트에서 단순한 메모리 컨트롤러보다 느린 경로를 겪을 가능성을 간과했습니다. 메모리 컨트롤러 쓰기 합병을 물리 치면 코어-> 언 코어-> 메모리 컨트롤러 링 버스 처리량뿐만 아니라 실제 DRAM 처리량 에 병목 현상이 발생하여 VGA 쓰기가 런타임을 완전히 지배하고 플러시 트리거 clflushopt와의 차이점을 숨길 수 lock xor byte [esp], 0있습니다.
Peter Cordes

상점 데이터를 가져 오기 위해 모든 모드에서 x86을 에뮬레이트해야한다는 요점은 상당히 뛰어나므로 상당히 신뢰할 수 없으며 성능이 허용되지 않거나 VGA 텍스트 모드 대신 VGA 텍스트 모드를 사용하는 텍스트 콘솔에서 스크롤 할 때 눈에 띄게 나타납니다. 오늘날 리눅스는 기본적으로 프레임 버퍼 콘솔을 사용합니다. OS가 멀티 코어 시스템의 모든 코어를 불러 온 후에도 VGA 텍스트 모드가 계속 작동해야한다는 것을 잊었습니다.
Peter Cordes

4

다양한 최신 인텔 CPU 및 PCH (Platform Controller Hub) 데이터 시트를 읽어 보면 필요한 하드웨어가 구현 된 것으로 보이지 않습니다. VGA 프레임 버퍼 (실제 주소 0xA0000-0xBFFFF)의 프로세서 액세스에 대한 응답으로 SMI (System Management Interrupt)를 생성 할 방법이없는 것 같습니다.

CPU의 메모리 컨트롤러는 VGA 프레임 버퍼에 대한 액세스를 통합 그래픽 컨트롤러, CPU에 직접 연결된 PCI Express 포트 또는 CPU를 PCH에 연결하는 DMI 인터페이스로 라우팅합니다. VGA 프레임 버퍼를 개별적으로 라우팅 할 수 있지만 이것은 별도의 MDA (Monochrome Display Adapter) 장치를 지원하기위한 것입니다. 통합 그래픽 컨트롤러는 문서화가 잘되어 있지 않으므로 VGA 프레임 버퍼 액세스에서 SMI를 생성하도록 구성 할 수는 있지만 가능성이 낮습니다. 어쨌든 개별 그래픽에서는 작동하지 않습니다.

인텔 PCH는 VGA 프레임 버퍼 액세스에 대한 응답으로 SMI 생성을 지원하지 않는 것 같습니다. 키보드 컨트롤러, IDE 컨트롤러 및 기타 레거시 장치에 대한 I / O 액세스에 대한 응답으로 SMI 생성을 지원하므로 이미 가장 자연스러운 위치입니다. 이를 수행하는 문서화되지 않은 기능이있을 수 있지만 PCH 데이터 시트에 제공된 가능한 SMI 소스 목록에는 포함되어 있지 않습니다.

이론적으로, 마더 보드 제조업체는 PCI Express 포트를 통해 가짜 VGA 장치를 PCH에 연결 한 다음 PCH GPIO 핀을 사용하여 SMI를 생성 할 수 있습니다. 그러나 이것이 실제로 작동하는지 확실하지 않습니다. CPU가 SMI를 얻을 때까지는 다른 명령을 실행하는 것으로 넘어갈 수 있었고 프레임 버퍼 액세스 시점의 CPU 상태를 검사 할 수 없었습니다.

(SoundBlaster Live에서 SoundBlaster 16 에뮬레이션과 비슷한 문제가 발생했습니다. 레거시 SoundBlaster 포트에 액세스 할 때 PCI SERR #을 생성하여 CPU에서 NMI를 생성합니다. 불행히도 에뮬레이션은 많은 Pentium 4 마더 보드에서 중단됩니다. NMI는 다음 또는 후속 교육에 도착할 것입니다.)


확인해 주셔서 감사합니다. 이것은 vblank 동기화 / VGA 텍스트 프레임 버퍼를 실제 픽셀 프레임 버퍼 (특허가 제안한 다른 메커니즘)로 렌더링 / 렌더링 할 때마다 한 번 SMI 핸들러를 배제하지는 않지만 상점 당 SMI를 배제합니다. out명령 종류의 동기와 주로 직렬화이지만, UC 저장소가 여전히 저장 버퍼를 통과하고 매장 커밋하기 전에 은퇴 할 것이다, 나는 생각한다. 는 IF out포트 액세스 P4에 문제가 있었다, 일반 상점은 재앙이 될 것입니다.
Peter Cordes

시스템이 SMI 핸들러를 사용하여 텍스트 프레임 버퍼를 스캔 한 경우 이는 cli정상적인 인터럽트가 비활성화 된 경우에도 WB 캐시 가능하고 여전히 화면을 업데이트 할 수 있음을 의미합니다 . 그래서 그것은 우리가 다른 가능성을 배제하거나 대부분 확인하기 위해 사용할 수있는 것입니다.
Peter Cordes
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.