KR20080084993A - 다중 사용자 디스플레이 프록시 서버 - Google Patents

Abstract

다중-사용자 호스트 컴퓨터 시스템은 다양한 원격 단말기를 지원하기 위한 가속화 및 프록시 서버 기능을 제공하기 위해 단말기 서비스 블레이드와 결합된 프로세서 블레이드를 포함한다. 각각의 원격 단말기에 대해, 단말기 서비스 블레이드 및 프록시 서버 기능은 비디오 및 그래픽 성능을 향상시킬 수 있다. 이것은 다중-사용자 호스트 컴퓨터 시스템이 다수의 사용자를 보다 효율적으로 지원할 수 있게 해준다. 단말기 서비스 블레이드는 각각의 원격 단말기에 대한 가상 디스플레이를 관리하고 서브 프레임 데이터의 선택적 갱신을 제공하는 그래픽 프로세서를 포함할 수 있다. 적절한 경우, 서브 프레임 데이터는 인코딩되어 네트워크를 통해 원격 단말기로 전송된다. 단말기 서비스 프로세서는 또한 의도된 원격 단말기 및 그 각자의 네트워크 접속에 대한 비디오 데이터 스트림을 오프로드하고 최적화한다. 프로세스 블레이드는 원격 KVM 관리를 지원하는 향상된 특징을 이용하는 베이스보드 관리 제어기를 포함할 수 있다.

프록시 서버, 프로세서 블레이드, 오프로드, 단말기 서비스, 원격 단말기

Description

다중 사용자 디스플레이 프록시 서버{MULTI-USER DISPLAY PROXY SERVER}

본 발명은 일반적으로 다중 사용자 호스트 컴퓨터 시스템(multi-user host computer system)에 관한 것으로서, 보다 상세하게는 원격 클라이언트에 대한 단말기 서비스(terminal service)를 지원하기 위해 프록시 서버를 이용하는 것에 관한 것이다.

효율적인 다중 사용자 컴퓨터 시스템을 개발하는 것은 현재의 시스템 설계자 및 제조업자의 중요한 목표이다.

종래의 컴퓨터 시스템은 한 사용자에게 직접 출력을 디스플레이하기 위해 로컬 디스플레이 장치를 이용할 수 있다. 로컬 디스플레이 장치는 디스플레이 장치를 컴퓨터 시스템의 출력에 전기적으로 연결시키는 여러가지 물리적 접속에 의해 부과되는 제한으로 인해 통상적으로 컴퓨터 시스템에 가까이 위치되어 있다. 일부 컴퓨터 시스템은 물리적 접속으로 인한 유사한 근접성 제한을 갖는 제2 디스플레이 장치를 지원할 수 있다.

원격 사용자는 호스트 시스템에 대한 적절한 관찰 장소(viewing location) 및 네트워크 접속을 선택하는 부가적인 유연성을 필요로 한다. 예를 들어, 회사 환경에서, 기업은 모든 호스트 컴퓨터를 물리적 보안 및 냉난방(air conditioning) 및 비상 전원 시스템(power back-up system) 등의 환경적 관리 둘다를 갖는 안전한 중앙 "컴퓨터실"에 보관하고자 할 수 있다. 그렇지만, 사용자가 그의 사무실에서 또한 "컴퓨터실" 밖에 위치한 책상에서 호스트 컴퓨터 시스템을 이용할 필요가 있다.

오늘날 통상적인 사무실 환경은 물리적으로 사용자 장소에 위치해 있는 퍼스널 컴퓨터 및 점점 더 많은 씬 클라이언트(thin client)를 포함하고 있다. 이들 퍼스널 컴퓨터 및 씬 클라이언트는 저장, 파일 처리(file serving), 파일 공유, 네트워크 관리 및 여러가지 관리 서비스를 위해 중앙 집중식 시스템을 갖는 네트워크에서 동작한다. 초기에, 시스템들은 컴퓨터 시스템과 연관된 모든 디스크 저장을 중앙집중식으로 한 반면, 사용자들은 그의 로컬 데스크톱에서 애플리케이션을 실행하였다. 보다 최근에, 보안의 이점, 감소된 운영 비용, 및 일반적으로 중앙 집중식 제어를 원한다는 것을 인식하면서, 퍼스널 컴퓨터 및 씬 클라이언트는 서버 상에서 애플리케이션을 실행하는 SBC(Server Based Computing) 솔루션에서 원격 단말기(Remote Terminal, RT)로서 동작할 수 있다.

SBC 환경에서의 RT에 대한 종래의 방법은 호스트 시스템이 마이크로소프트의 RDP(Remote Display Protocol) 등의 소정 형태의 서버-클라이언트 통신 교환을 사용하는 것이다. RDP는 서버 상에서 그 자신의 비디오 드라이버를 사용하며 RDP 프로토콜을 사용하여 렌더링 정보를 네트워크 패킷으로 구성하고 이들을 네트워크를 통해 클라이언트로 전송한다. 클라이언트는 렌더링 데이터를 수신하고 패킷을 대응하는 Microsoft Win32 GDI(Graphics Device Interface) API 호출로 해석한다. 클라이언트 키보드 및 마우스 명령을 서버로 리디렉션(redirect)하는 것은 물론 로컬 오디오 및 로컬 클라이언트 드라이브를 관리하는 것에 대한 지원도 포함되어 있다.

호스트 시스템과 클라이언트 간의 통신을 향상시키기 위해, 기타 시스템들은 RT에 대한 성능을 향상시키기 위해 호스트 시스템의 메인 CPU를 사용하고 있다. 이것은 원격 클라이언트로서 씬 클라이언트 및 종래의 PC 둘다에 대해 행해지고 있다. 이러한 방법은 한번에 한명의 사용자만을 지원하는 호스트 시스템에 효과적이다. 그렇지만, 다중-사용자 시스템의 경우, 임의의 한 사용자에 대한 성능을 향상시키기 위해 호스트에서 메인 CPU를 사용하는 방법은 상당한 한계를 갖는다. 한 사용자에 대한 최적화를 위해 사용되는 메인 메모리 및 CPU 사이클 등의 계산 자원이 부가의 사용자에 대한 작업 부하를 지원하는 능력을 감소시킬 수 있다.

단일의 호스트 컴퓨터로부터 다수의 사용자를 효율적으로 지원하는 것은 비용을 감소시킬 수 있다. 통상적인 사무실 환경에서, 모든 사람이 그의 컴퓨터를 동시에 사용하는 일이 드물며, 마찬가지로 임의의 한 사용자가 그의 컴퓨터의 컴퓨팅 자원을 전부 사용하는 일도 드물다. 따라서, 예를 들어, 100개 사무실을 갖는 회사는 한번에 60명의 사용자를 지원하는 시스템만 있으면 된다. 그렇다 하더라도, 이러한 시스템은 100명의 사용자 전부를 지원하여 그 사용자들이 각각 그 자신의 호스트 컴퓨터를 갖는 것처럼 보이게 하는 데 충분한 컴퓨팅 처리 용량(computing throughput)을 제공하도록 설계될 수 있다. 분산 사무실 환경에서, 중앙 집중식 다중-사용자 시스템은 각각의 시간대에 대한 서로 다른 근무 시간 동 안에 세계의 서로 다른 부분의 여러 장소에 있는 RT를 지원하기 위해 다양한 대역폭 링크를 통해 연결될 수 있다.

사용자의 애플리케이션이 서버 상에서 실행되고 사용자의 단말기에서 RT 서비스만이 지원되는 SBC(Server Based Computing)가 다수의 사용자를 위해 컴퓨팅 자원을 보다 효과적으로 할당하는 또하나의 방법이다. SBC는 호스트 시스템이 다중-사용자 운영 환경에서 메모리 및 CPU 사이클 등의 공유 자원을 동적으로 할당할 수 있게 해준다. SBC 시스템은 다수의 기준에 기초하여 서로 다른 사용자에게 서로 다른 레벨의 성능 및 자원에의 액세스를 제공하기 위해 다중-사용자 운영 체제, 가상 머신(VM), 부하 분산(load balancing) 및 기타 수단의 기법들을 이용할 수 있다. SBC 자원을 할당하기 위해 여러 우선순위 방식들이 사용될 수 있다. SBC는 더 높은 데이터 보안을 달성할 수 있고, 조직에 대한 지원을 중앙 집중화할 수 있으며, 재난 복구 및 사업 계속성을 향상시킬 수 있고, 또한 조직에 걸친 데이터 저장 요건을 감소시킬 수 있다. 웹 서버는 브라우저 기반 클라이언트를 비롯한 다양한 클라이언트에 다중-사용자 플랫폼을 제공할 수 있는 한 유형의 SBC이다.

블레이드 기반 서버(blade based server)는 확장가능한 다중-사용자 호스트 시스템에 대한 효과적인 아키텍처를 구현한다. 블레이드 계산 기능, I/O 기능의 분할(partitioning), 백플레인 아키텍처(backplane architecture) 및 스위칭 모두가 블레이드 기반 서버의 설계에서 중요하다. 각각의 블레이드는 전체 컴퓨터의 기능들을 구성할 수 있거나 블레이드 서버는 블레이드들에 걸쳐 상당한 기능들을 공유할 수 있다. 다수의 프로세서 코어를 포함함으로써 CPU가 그의 성능을 계속 증대시킴에 따라, 단일의 사용자를 단일의 블레이드로 제한하는 것은 경제적 의미를 감소시킨다. 블레이드 서버 시스템에서의 각각의 블레이드는 원격적으로 모니터링될 필요가 있을 수 있다. 블레이드 시스템의 다중-기능 특성으로, 블레이드 랙(rack of blades)이 여러가지 작업 부하에 가장 잘 매칭하도록 구성될 필요가 있을 수 있다.

도 1은 스위치(120, 122) 및 각각의 스위치를 통과하는 경로와 함께 1부터 8까지 표시된 블레이드(102, 104, 106, 108, 110, 112, 114 및 116)를 포함하는 대표적인 종래 기술의 다중-블레이드 시스템-레벨 아키텍처(100)를 나타낸 것이다. 이들 스위치는 또한 그들 간의 경로는 물론 블레이드 랙을 다른 블레이드 랙으로 또는 소정의 다른 서브시스템으로 더 확장할 수 있는 링크(124)도 포함할 수 있다. 도 1의 블레이드는 그 수가 변할 수 있으며, 각각의 블레이드는 프로세서 블레이드, I/O 블레이드, 스위칭 블레이드 또는 이들 셋의 소정의 조합일 수 있다. I/O 블레이드는 블레이드 4(108) 및 경로(180)와 블레이드 8(116) 및 경로(190)로 나타낸 바와 같이 그 자신의 외부 인터페이스를 포함할 수 있다. 외부 인터페이스의 예는 광섬유 채널 및 iSCSI 등의 비네트워크 인터페이스(non-network interface) 또는 이더넷 및 10G 이더넷 등의 네트워크 인터페이스(network interface)를 포함할 수 있다.

스위치 1(120) 및 스위치 2(122)의 예시적인 스위치 매트릭스는 각각의 스위치로부터 각각의 블레이드로의 접속(140, 142)을 나타낸다. 각각의 스위치에 대한 물리적 또는 논리적 전송의 유형이 동일하거나 서로 다를 수 있다. 경로(144)는 스위치(120, 122)를 접속 또는 브리징(bridge)할 수 있다. 스위치 및 접속의 조합을 스위치 패브릭(switch fabric)(150)이라고 하며, 이 스위치 패브릭은 각각의 블레이드 상에 분포되어 있을 수 있거나, 백플레인의 일부일 수 있거나, 스위칭 블레이드(switching blade) 상에 구현될 수 있거나, 또는 이들 세가지의 조합을 포함할 수 있다. 스위칭 패브릭에 대한 경로는 단방향, 양방향 또는 이들의 조합일 수 있다. 각각의 블레이드는 다수의 스위치에 연결될 수 있으며 블레이드 기능(blade function)의 일부로서 서로 다른 스위치에 대한 브리징 기능(bridging function)을 포함할 수 있다. 보다 개선된 시스템은 완전 메쉬 토폴로지 패브릭(full mesh topology fabric)을 포함할 수 있으며, 중복성(redundancy)을 가질 수 있다.

스위치 패브릭(150)에 사용되는 접속의 몇몇 예들은 PCI(Peripheral Component Interconnect) Express, 1OG XAUI(Attachment Unit Interface), Infiniband, RapidIO, StarFabric, ASI(Advanced Switching Interconnect), 기가비트 이더넷(Gigabit Ethernet), 파이버 채널(Fiber Channel)은 물론 전기 및 광학 상호접속 중 하나 이상의 채널을 포함한다. 몇몇 경우에, 각각의 블레이드의 기능칩은 패브픽 인터페이스(fabric interface)(130)를 직접 포함할 수 있다. 다른 경우에, 블레이드는 인터페이싱을 수행하는 패브릭 인터페이스 칩 또는 브리지 칩(bridge chip)을 포함할 수 있다. 각각의 블레이드 내의 패브릭 및 브리지 칩은 시스템 스위치들 중 하나 이상에 연결될 수 있으며 스위치들 간의 부가의 브리지 기능을 통합할 수 있다.

그렇지만, 블레이드 기반 다중-사용자 호스트 컴퓨터가 조직이 가질 수 있는 다양한 서버 소프트웨어 및 웹 기반 애플리케이션 및 다양한 RT 장치에 대한 풍부한 애플리케이션 성능을 효과적으로 관리, 제어 및 전달하기 위해서는 복잡도가 증가되어야만 할 수도 있다. 블레이드 기반 다중-사용자 호스트 서버가 우수한 컴퓨팅 및 디스플레이 성능으로 수많은 원격 사용자들을 더 효율적으로 지원할 수 있게 해주는 해결 방안이 필요하다.

본 발명은 일반적으로 애플리케이션을 관리하고 서버 기반 컴퓨팅을 수행하는, 대화형 그래픽 및 비디오를 지원하는 하나 이상의 원격 단말기(Remote Terminal, RT)를 포함하는, 블레이드 기반 다중 사용자 컴퓨터 시스템의 효율적인 아키텍처를 제공한다. 각각의 RT는 그 자신의 키보드, 마우스 및 디스플레이를 가지며 가능하게는 기타 주변 장치를 갖는다. RT는 개개의 사용자에게 서버 상에서 이용가능한 애플리케이션은 물론 풍부한 그래픽 사용자 인터페이스에의 액세스를 제공한다. 다중-사용자 컴퓨터 시스템은 다중-사용자 운영 체제를 실행할 수 있거나, 단일 사용자 운영 체제의 가상화된 인스턴스화(virtualized instantiation)를 실행할 수 있거나, 다중 사용자용 웹 서버 엔진을 실행할 수 있거나, 프록시 서버를 실행할 수 있거나, 이들의 소정의 조합을 실행할 수 있다.

제1 양호한 실시예에서, 프로세서 블레이드는 RT로부터의 원격 관리 및 제어를 가능하게 해주는 BMC(Baseboard Management Controller)를 포함한다. 센서 및 상태 정보를 제공하는 것에 부가하여, 시스템 관리자가 블레이드에 로컬적으로 연결되어 있는 것처럼 프로세서 블레이드에 원격적으로 액세스할 수 있도록 BMC는 키보드, 비디오 및 마우스(Keyboard, Video and Mouse, KVM) 기능을 포함한다. 런타임 문제의 진단이 가장 효율적으로 수행될 수 있도록 BMC 및 KVM 기능은 CPU 및 보드의 기본 동작에 추가적인 런타임 변경을 하지 않고 "대역외" 동작들을 지원한다. 원격 KVM의 디스플레이 관련 특징들은 선택적 갱신 및, 필요한 경우, 다양한 형태의 디스플레이 데이터 압축을 이용하는 그래픽 프로세서 및 디스플레이 데이터 인코더에 의해 지원된다. 디스플레이 데이터 인코더 기능은 TSA(424) 내에 또는 결합된 GPU-TSA의 전용 데이터 인코더(752)로서 통합될 수 있다.

제2 양호한 실시예에서, TSB(Terminal Services Blade)는 각각의 RT에 대해 가상 디스플레이 환경을 생성함으로써 다수의 RT를 지원하기 위해 소프트웨어, 그래픽 프로세서 및 데이터 인코딩의 조합을 이용한다. RT와 통신하는 가장 통상적인 방법은 캡슐화된 그래픽 명령을 전송하는 것 또는 인코딩된 서브-프레임 데이터를 전송하는 것을 포함한다. RT를 관리하는 소프트웨어는 메인 호스트 프로세서 블레이드에서, TSB의 CPU에서, TSA(Terminal Services Accelerator)에서, RT에서 또는 이들의 조합에서 실행될 수 있다. 각각의 RT에 대한 선택적인 갱신은 소프트웨어적으로 또는 MU-GPU(Multi-User Graphics Processor Unit) 또는 결합된 TSA-GPU 내의 하드웨어의 도움을 받아 조정될 수 있다. 그래픽 프로세서는 제안된 VESA DPVL(Digital Packet Video Link) 표준 또는 서브 프레임의 헤더, 상태 비트 및 서명의 소정의 조합을 사용하는 개선된 방법을 따를 수 있다. 다른 개선에서, 출력 데이터를 위해 PCI 익스프레스 또는 다른 버스가 DVI 대신에 사용되고, 부가의 데이터 인코딩이 그래픽 프로세서 내에서 또는 그래픽 프로세서에 부착된 인코더로 수행되며, 이 소프트웨어는 다중-사용자 지원을 위해 하나 이상의 그래픽 프로세서를 이용한다.

TSB는 클라이언트 종료(client termination)를 비롯한 다양한 레벨의 프록시 서비스(proxy serving)를 수행할 수 있으며, 프로세서 블레이드에서 실행 중인 RDP 호스트가 TSB에서 실행 중인 프로세스를 유일하게 알고 있는 클라이언트인 것으로 생각하도록 다수의 RDP 클라이언트를 완전하게 에뮬레이트하는 것까지 할 수 있다. 이 방법에서, TSB는 호스트 프로세서가 모르고 있는 RT에 대해 완전히 독립적인 인터페이스를 생성할 수 있다. TSB와 RT 간의 이러한 유형의 인터페이스는 분할 프록시(split proxy)의 형태일 수 있다. 분할 프록시로서, TSB 및 RT는 사설 채널(private channel)을 통해 통신하며, 이들은 RDP 또는 웹 브라우저 프로토콜 등의 보다 표준적인 프로토콜을 사용하여 통신할 수 있는 것보다 이 채널을 통해 더 효율적으로 통신을 할 수 있다.

부가적인 효율성을 위해, 프로세서 블레이드는 비디오 재생 등의 기능들을 차단하기 위해 TSA와 결합될 수 있는 추적 소프트웨어를 실행할 수 있다. 호스트 CPU가 비디오 디코딩을 로컬적으로 수행하고 RT로 전송하기 위한 비트맵을 공급하게 하지 않고, TSA는 CPU에 의한 디코딩 이전에 비디오 데이터 스트림을 차단할 수 있고 본래의 비디오 스트림 또는 트랜스코딩된(transcoded) 또는 트랜스레이팅된(transrated) 버전 등의 수정된 버전을 목표 RT로 전달할 수 있다. RT로의 전달은 RDP 프로토콜 내에서 여전히 관리되면서 표준 RDP 채널 이외의 다른 사설 채널을 이용할 수 있다.

각각의 실시예에서, 그래픽 연산 및 선택적인 갱신 프로세스 이후에, 데이터가 인코딩된 다음에 네트워크 준비 갱신 패킷(network ready update packet)으로 캡슐화된다. 더 간단한 네트워크 제어기와 관련하여 동작하는 네트워크 I/O 블레이드, 네트워크 프로세서 또는 CPU는 유선 및/또는 무선 네트워크(들)를 통해 그래픽 패킷을 RT로 전송한다. 일부 KVM 구성에서, BMC는 프로세서 블레이드 CPU가 패킷 갱신 동작(update packet operation)에 의해 방해되지 않도록 네트워크 처리를 수행한다. 다른 구성에서, CPU는 보호 파티션(protectively partition)을 하기 위해 "가상 기술(Virtual Technology)"을 이용하고, 사용자 태스크(user task)를 포함한 운영 체제 기능은 물론 BMC의 대역외 관리 태스크 둘다를 수행한다. BMC는 시스템 내의 다른 네트워크 제어기 또는 네트워크 물리 계층(PHY)과 통신을 할 수 있다. 각각의 RT 시스템은 디스플레이하기 위한 그래픽 패킷을 디코딩하고 프레임 갱신을 관리하며 디스플레이 화면에 필요한 처리를 수행한다. 네트워크 전송에서 손실된 패킷을 마스킹하는 것 등의 다른 특징들이 원격 디스플레이 시스템(들)에 의해 관리된다. 새로운 프레임 갱신이 없을 때, 원격 디스플레이 제어기는 이전 프레임으로부터의 데이터로 디스플레이 화면을 리프레시한다.

다양한 네트워크 시스템이 여러가지 유선 및 무선 네트워크 접속으로부터의 네트워크 정보를 TSB에 피드백할 수 있다. TSB 이 네트워크 정보를 사용하여 RT 갱신(RT update)을 생성하는 여러가지 처리 단계들에 영향을 미치고, 이 네트워크 피드백에 기초하여, 서로 다른 RT에 대한 프레임 레이트 및 데이터 인코딩을 변경할 수 있다. 그에 부가하여, 노이즈가 많은 전송 채널을 갖는 네트워크를 포함하는 시스템의 경우, 인코딩 단계가 전송 채널의 특성에 대한 전송 데이터를 준비하기 위해 전방향 에러 정정 보호(forward error correction protection)와 결합될 수 있다. 이들 단계의 결합은 각각의 RT에 대해 낮은 지연을 갖는 최적의 프레임 레이트를 유지한다. TSA 및 TSA-GPU가 별도의 서브시스템으로 구현되거나 네트워크 프로세서, 보안 프로세서, XML 가속기, iSCSI 프로세서 또는 이들의 임의의 조합 등의 다른 오프로드(offload) 및 가속 처리와 결합될 수 있다.

따라서, 적어도 상기 이유들로, 본 발명은 시스템 상호 운용 및 기능을 용이하게 해주기 위해 다양한 이기종 컴포넌트를 이용하는 유연한 블레이드 기반 다중-사용자 컴퓨터 시스템을 효과적으로 구현한다. 본 발명은 따라서 향상된 블레이드 기반 다중-사용자 서버를 효율적으로 구현한다.

도 1은 다수의 블레이드 및 하나의 스위칭 패브릭을 포함하는 종래 기술의 블레이드 기반 다중-사용자 컴퓨터 시스템의 블록도이다.

도 2는 본 발명의 제1 실시예에 따른 다중-CPU 컴플렉스(multi-CPU complex)와 원격 키보드, 비디오 및 마우스(KVM)를 지원하는 BMC(Baseboard Management Control)를 구비한 다중-CPU 프로세서 블레이드의 블록도이다.

도 3은 네트워크를 통해 도 1의 블레이드 기반 다중-사용자 컴퓨터 시스템과 연결되어 있는 RT를 나타낸 도면이다.

도 4는 본 발명의 제2 실시예에 따른 TSB(Terminal Services Blade)의 블록도이다.

도 5는 8개의 디스플레이 영역으로 구성된 메모리를 나타낸 도면으로서, 그 중 하나는 디스플레이 창(display window)을 포함하고, 그 중 2개는 하나의 큰 RT 디스플레이를 지원하는 데 사용된다.

도 6A는 도 5의 디스플레이 맵(536)을 보다 상세히 나타낸 도면이다.

도 6B는 타일들로 세분된 도 6A의 직사각형을 나타낸 도면.

도 7은 도 4의 예시적인 SOC(System-On-Chip) TSA-GPU[통합된 GPU(Graphics Processor Unit)를 갖는 TSA(Terminal Services Accelerator)](700)의 상세를 나타낸 블록도이다.

도 8은 그래픽 서브시스템 및 기타 대역외 처리를 포함하는 KVM을 갖는 BMC(Baseboard Management Controller)의 블록도이다.

도 9는 본 발명의 일 실시예에 따른 단말기 서비스(terminal service) 및 디스플레이 프록시 서버 동작을 수행하는 방법에서의 단계들의 흐름도이다.

도 10은 본 발명의 일 실시예에 따른, 원격 단말기에 대한 네트워크 수신 및 디스플레이 절차를 수행하는 방법의 단계들의 흐름도이다.

본 발명은 원격 단말기를 지원하는 블레이드 기반 다중-사용자 컴퓨터 시스템에서의 개선에 관한 것이다. 설명된 실시예들이 블레이드 기반 다중-사용자 컴퓨터 시스템에 관한 것이지만, 동일한 원리 및 특징이 다른 유형의 단일 및 다중-사용자 시스템과 다른 유형의 원격 단말기에 똑같이 적용될 수 있다.

블레이드 기반 다중-사용자 컴퓨터 시스템(100)["호스트(100)"이라고도 함] 은, 도 3을 참조하여 이하에 기술되는 바와 같이, 원격 단말기(Remote Terminal)에서 다수의 사용자를 지원하도록 설계되어 있다. 각각의 RT는 그 자신의 로컬 컴퓨터를 갖는 것처럼 호스트(100)를 시분할(time-share)할 수 있고 로컬 컴퓨터에서 달성될 수 있는 동일한 유형의 사용자 경험을 갖는 모든 유형의 그래픽, 텍스트 및 비디오 컨텐츠를 완벽하게 지원할 수 있다. 경로(180, 190)는 네트워크 접속을 사용할 때 도 3의 네트워크 경로(390)에 접속될 수 있는 도 4의 경로(490) 및 도 2의 경로(290)에 대응한다. RT 접속에 부가하여, 호스트(100)는 링크(124)를 통해 WAN, 스토리지 서브시스템(storage subsystem), 기타 호스트, 또는 다양한 기타 데이터 센터 접속(data center connection)[GigE, 1OG 이더넷(Ethernet), iSCSI, 파이버 채널(Fiber Channel)(FC), FCIP(Fiber Channel IP) 또는 다른 전기 또는 광학 접속의 형태를 취할 수 있음]에 접속될 수 있다. 호스트(100)가 다양한 다중-사용자 운영 체제(OS)를 지원할 수 있거나 단일 사용자 OS를 가상화하는 소프트웨어가 프로세서 블레이드들 중 하나 이상에 설치될 수 있다. Citrix 또는 Windows Server 등의 운영 체제는 다중-사용자 OS로서 설계되어 있다. Windows XP는, 동시 다중 사용자용으로 특별히 설계되어 있지는 않지만, VMWARE 또는 XenSource 등의 하위 레벨 가상화 소프트웨어 또는 다중-사용자 OS처럼 보일 정도로 빠르게 사용자 스위칭을 수행하는 다른 수단의 도움으로 이러한 구성에서 사용될 수 있다. 다른 관리 제어는 RT 및 프로그램이 정적으로 또는 동적으로 프로세서 간에 이동될 수 있게 해줄 수 있다. 각각의 프로세서에 대한 OS에 의해 부하 분산(load balancing)이 수행될 수 있거나 이 시스템이 다수의 프로세서에 걸쳐 부하 분산을 수행할 수 있다. 호스트(100)는 또한 일종의 웹 서버를 실행할 수 있고 웹 기반 인터페이스를 통해 다중 사용자를 지원할 수 있다. 호스트(100)는 여러가지 RT에 대해 프록시 서버로서 기능할 수 있고 애플리케이션 서버 또는 웹 서버와 통신을 할 수 있다.

도 2는 블레이드 기반 다중-사용자 서버 시스템(100)의 블레이드들(102-116) 중 하나로서 기능할 수 있는 프로세서 블레이드(200)의 일 실시예의 블록도이다. 각각의 블레이드(200)는 그 자체로 호스트 컴퓨터일 수 있거나 더 좋은 성능의 호스트 컴퓨터를 생성하기 위해 다수의 블레이드가 랙에 탑재되어 있을 수 있다. 호스트가 갖는 프로세서 블레이드, I/O 처리 및 CPU가 많을수록, 더 많은 사용자가 동시에 지원될 수 있다. 프로세서 블레이드(200)의 기본적인 컴포넌트는 양호하게는 다중-CPU 컴플렉스(multi-CPU Complex)(202), 버스 브리지-제어기(bus bridge-controller)(204), PCI 익스프레스 등의 메인 시스템 버스(206), 로컬 I/O(208), 메인 RAM(234), 스위치, 백플레인 및 기타 블레이드에 접속되는 패브릭 인터페이스(Fabric Interface, FI)(130), 및 선택적으로 BMC(Baseboard Management Control) 서브시스템(800)을 포함하지만, 이에 한정되지 않는다.

스위치 패브릭(150)의 전송 및 물리 계층 인터페이스의 유형에 따라, 패브릭 인터페이스(FI)(130)는 상당한 처리를 포함할 수 있다. 예를 들어, 패브릭 인터페이스(130)는 로컬적으로 발생된 패킷 및 ASI 패브릭 인터페이스 둘다에 필요한 패킷 레벨 필터링 및 처리 모두를 수행하는 10G 이더넷 프로세서(도시 생략)를 포함할 수 있다. 이러한 패브릭 인터페이스 프로세서는 외부 RAM(230)을 필요로 할 수 있거나 충분한 내부 저장 장치를 가질 수 있다. 네트워크 물리 계층 인터페이스(PHY)는 FI 프로세서와 통합될 수 있거나 외부 PHY 컴포넌트를 이용할 수 있다. 로컬 I/O(208) 및 로컬 I/O 접속(290)은 이 동일한 FI 프로세서에 의해 제어될 수 있다. 그에 부가하여, 브리지 제어기(204)를 통해 시스템 버스(206)와 인터페이스하지 않고, 패브릭 인터페이스(130)는 시스템 버스(206)에 직접 연결될 수 있다.

예시적인 한 시스템에서, 스위치 1(120) 및 연관된 경로(140)는 PCI 익스프레스 패킷의 터널링(tunneling)을 가능하게 해주는 ASI 버스 프로토콜을 이용한다. 스위치 2(122) 및 연관된 경로(142)는 XAUI 스타일 버스(XAUI style bus)일 수 있고, 저장 및 네트워킹에 더 최적화되어 있을 수 있으며, 10G 이더넷 프로토콜을 이용할 수 있다. 이 시스템은 서로 다른 프로세서 블레이드들 간의 통신을 위해서는 ASI 버스를 주로 이용하고 네트워킹 및 스토리지 블레이드와의 통신을 위해서는 XAUI 버스를 주로 이용할 수 있다. 각각의 블레이드는 하나의 인터페이스를 포함하거나, 양쪽 인터페이스 모두를 포함할 수 있으며, 양쪽 인터페이스 모두를 포함하는 경우, 2개의 버스 간의 트래픽 전송을 브리징하는 기능도 포함할 수 있다.

도 2의 다중-CPU 컴플렉스(202)는 하나 이상의 프로세서 칩을 포함할 수 있으며, 각각의 칩은 각각이 다중 동시 쓰레드(multiple simultaneous thread)를 실행할 수 있는 하나 이상의 CPU 코어(도시 생략)를 갖는다. 각각의 레벨에서, 각각의 CPU 코어는 전용 캐시 메모리를 포함할 수 있고, 소정 레벨에서 다수의 CPU 코어가 캐시 메모리를 공유할 수 있다. 다중-CPU 컴플렉스(202)는 독립적으로 RAM(234)을 제어하고 그에 액세스할 수 있거나, RAM(234) 액세스를 수행하기 위해 브리지 제어기(204)를 이용할 수 있다. 일부 다른 구성에서, 다중-CPU 컴플렉스(202)는 메인 시스템 버스(206)와 직접 인터페이스할 수 있다(도시 생략).

로컬 I/O(208)는 여러가지 I/O 인터페이스와 외부 인터페이스(290)에 대한 제어 및 경로(210)를 통한 프로세서 블레이드(200) 내에 위치한 자원들에 대한 제어 둘다를 포함할 수 있다. 저장 및 네트워킹 등의 주요 I/O 기능들이 각각의 프로세서 블레이드(200)에 포함되어 있을 수 있거나 스위칭 패브릭(150)을 통해 다른 전용 I/O 블레이드가 지원될 수 있다. 스위치 패브릭의 물리적 및 논리적 접속을 위한 선택에 따라, 인터페이스(140, 142)는 브리지 제어기(204) 내에 직접 통합될 수 있거나 패브릭 인터페이스(130) 칩을 필요로 할 수 있다.

각각의 프로세서 블레이드(200)가 사실상 "컴퓨터 시스템"일 수 있기 때문에, 시스템을 관찰하고 관리할 방법을 갖는 것이 아주 바람직하다. 호스트(100)가 특별한 컴퓨터실에 있을 수 있기 때문에, 시스템이 원격 단말기(RT)(300)로부터 관찰되고 관리될 수 있게 해주는 것이 종종 바람직하다. RT는 특별히 설계된 씬 클라이언트일 수 있거나, 관리 기능을 위해 보다 통상적으로는 관리 소프트웨어를 실행하는 컴퓨터이다. 다른 대안으로서, RT는 관리 기능을 수행하는 브라우저 기반 소프트웨어를 포함할 수 있다. 프로세서 블레이드(200)는 브라우저 기반 관리를 위한 사용자 인터페이스를 제공하는 웹 서버를 포함할 수 있다.

프로세서 블레이드(200)가 관리되어 원격 사용자로부터의 작업 부하를 받고 있지 않은 경우, 다중-CPU 컴플렉스(202)의 메인 CPU가 종종 RT와의 통신을 위해 사용된다. 그렇지만, 다양한 환경 조건을 모니터링하고 프로세서 블레이드(200)가 원격 사용자로부터의 작업 부하를 실행하고 있는 동안 프로세서 블레이드(200)를 관리하기 위해, 도 8에 도시된 BMC(Baseboard Management Control) 서브시스템(800)을 포함하는 것이 바람직하다.

BMC(800) 내의 개별 CPU에 대한 대안 또는 부속물로서, 202 내의 메인 CPU가 운영 체제 및 사용자 기능으로부터 관리 기능을 분리시키기 위해 가상화 기술을 사용할 수 있다. 다중-코어 CPU(202)에서 특정의 코어가 이러한 관리 기능에 전용되어 있을 수 있는 반면, 적절히 설계된 CPU는 태스크 또는 쓰레드가 어느 코어에서 실행되고 있는지에 상관없이 서로 분리될 수 있게 해주기 위해 Intel Vanderpool VT 기술 등의 하드웨어를 포함할 수 있다. 그 자체로서, 단일 CPU 코어는 대역외 관리 기능을 지원하는 보호 가상 관리 기계 모드(protected virtual management machine mode)를 실행할 수 있음과 동시에 다양한 운영 체제 및 사용자 태스크를 지원하기 위해 운영 체제 가상 머신 모드(operating system virtual machine mode)를 실행할 수 있다.

CPU 코어의 서로 다른 가상 머신은 각각 BMC(800)의 서로 다른 양태와 관련하여 동작할 수 있다. 양호한 실시예에서, KVM(212)을 갖는 BMC는 가상 머신 모드에서 실행 중인 표준의 운영 체제에 대한 디스플레이 처리를 수행하는 TSA-GPU(700)의 MU-GPU(412) 등의 로컬 그래픽 프로세서를 포함한다. 원격 KVM 동작을 위해, 원격 관리자는 프로세서 블레이드(200)의 대역외 관리를 관찰 또는 수행하고자 할 수 있다. 호스트 CPU(202)의 보호 가상 관리 기계 모드는 대역외 원격 관리를 수행하는 것을 돕기 위해 사용될 수 있다. 원격 KVM 관리는 대역외 네트워크 인터페이스로부터 동일한 로컬 그래픽 프로세서 디스플레이에 액세스하는 것을 포함할 수 있다. 그래픽 프로세서 디스플레이에의 이러한 액세스는 도 7에 상세히 나타낸 TSA-GPU(700)의 더욱 향상된 특징들을 이용할 수 있다. 다른 실시예에서, KVM(212)을 갖는 BMC 내의 개별 CPU(808)는 호스트 CPU 상의 보호 가상 관리 기계 모드를 사용하지 않고 대역외 원격 관리(out of band remote administration)를 관리하는 데 사용된다.

도 3은 본 발명의 일 실시예에 따른 원격 단말기(Remote Terminal)(300)[양호하게는 디스플레이 화면(310), 로컬 RAM(312), 및 RTSC(Remote Terminal System Controller)(314)(이에 한정되지 않음)를 포함함]의 블록도이다. RTSC(314)는 마우스(318), 키보드(320), 및 오디오를 재생하는 스피커 등의 기타 잡다한 장치들(322)에 대한 대응하는 접속 또는 각종의 장치를 지원할 수 있는 USB(Universal Serial Bus) 접속을 갖는 키보드, 마우스 및 I/O 제어 서브시스템(316)을 포함한다. 생체 인식 또는 보안 카드를 비롯한 보안 수단을 통해 사용자 인증을 지원하는 기타 일체형 또는 주변 장치 접속도 역시 포함되어 있을 수 있다. 이들 접속은 PS/2 스타일 키보드 또는 마우스 접속과 같이 전용의 단일 목적을 위한 있거나 USB와 같이 보다 범용적인 것일 수 있다. 다른 실시예에서, I/O는 게임 컨트롤러, 로컬 무선 접속, IR 접속을 포함하거나 접속을 전혀 포함하지 않을 수 있다. 원격 단말기 시스템(300)은 또한 DVD 드라이브 등의 다른 주변 장치도 포함할 수 있다.

본 발명의 몇몇 실시예들은 원격 단말기 시스템(300)에 어떤 외부 입력도 필요로 하지 않는다. 이러한 시스템의 일례는 소매 상점 또는 전자 게시 판(electronic billboard)이며, 이 경우 여러가지 디스플레이가 서로 다른 장소에 있을 수 있으며 각종의 유익하고 재미있는 정보를 보여줄 수 있다. 각각의 디스플레이는 독립적으로 동작될 수 있고 각종의 인자에 기초하여 갱신될 수 있다. 유사한 보안 시스템은 또한 은행에 있는 정보 키오스크(information kiosk) 또는 ATM(Automated Teller Machine) 등의 터치 스크린 입력을 받는 소정의 디스플레이를 포함할 수 있다. 카지노의 게임기 등의 기타 보안 시스템도 역시 이러한 유형의 RT에 기초할 수 있다.

도 1의 호스트(100)는 각각의 블레이드로부터의 네트워킹 인터페이스(예를 들어, 180, 190)를 포함할 수 있거나 공유 네트워크 제어기가 포함될 수 있다. 어느 경우든지, 호스트(100)로부터 RT(300)의 입력(390)으로의 네트워크 접속이 설정된다. 네트워크 제어기(336)는 유선 또는 무선일 수 있는 네트워크 경로(390)를 통해 보안 프로토콜을 지원하고, 이 네트워크를 통해 전달되는 데이터가 키 교환(key exchange)을 통해 암호화될 수 있다. 통상의 네트워크 예는 몇몇 유형의 이더넷, 양호하게는 기가비트 이더넷을 실행하는 CAT 5 배선(wiring) 등의 이더넷이며, 이 경우 I/O 제어 경로는 표준의 TCP/IP(Transport Control Protocol/Internet Protocol) 또는 몇몇 형태의 경량 핸드쉐이킹(lightweight handshaking) 등의 이더넷 지원 프로토콜을 UDP 전송과 함께 사용할 수 있다. RTCP(Real-Time Control Protocol)와 함께 RTSP(Real-time Streaming Protocol) 및 RTP(Real-Time Transfer Protocol) 등의 업계의 노력의 산물이 패킷 전송을 향상시키는 데 사용될 수 있고 재전송 프로토콜(re-transmit protocol)을 추가함으로써 추가적으로 향상될 수 있다. 계층 3 DSCP(DiffServ Code Point), DLNA(Digital Living Network Alliance)의 일부인 WMM 프로토콜, Microsoft Qwave, uPnP, QoS 및 802.1P 등의 QoS(Quality of Service) 성과를 사용하는 것을 바탕으로 한 다른 더 새로운 노력의 산물도 역시 기존의 네트워크 표준을 사용하는 향상된 방법이다.

I/O 장치를 지원하는 패킷에 부가하여, 네트워크는 디스플레이를 위해 필요한 캡슐화되고 인코딩된 디스플레이 명령 및 데이터를 전달한다. CPU(324)는 렌더링되어 디스플레이 화면(310) 상에 로컬적으로 디스플레이될 수 있는 모든 유형의 시각 데이터 표현을 지원하기 위해 네트워크 제어기(336), 2D 드로잉 엔진(drawing engine)(332), 3D 드로잉 엔진(334), 데이터 디코더(326), 비디오 디코더(328) 및 디스플레이 제어기(330)와 조정을 한다. RT가 디스플레이 처리 블록들의 임의의 특정의 조합을 포함할 필요가 없다. 부가의 씬 RT(thin RT)는 최소한으로 디스플레이 처리를 하는 CPU를 갖는 디스플레이 제어기(330)만을 포함할 수 있지만, 적어도 한 유형의 디코더 또는 드로잉 엔진이 있을 가능성이 더 많다.

여러가지 처리 요소가 전체 프레임을 나타내는 패킷 또는 디스플레이 데이터의 여러가지 서브 프레임을 나타내는 패킷을 디코딩할 수 있다. 양호한 일 실시예에서, 패킷은 디스플레이의 고정된 위치에 대응하는 여러가지 인코딩된 디스플레이 데이터 슬라이스를 포함한다. CPU(324)는 패킷을 수신할 수 있고, 패킷에 대한 헤더 정보를 판독함으로써 패킷이 보내질 디스플레이의 적절한 위치를 결정할 수 있다. 데이터 디코더(326) 등의 적절한 자원이 데이터 슬라이스를 디코딩하는 데 사용되고, 디코딩된 데이터가 디스플레이 메모리 내의 적절한 위치로 전송된다. 데 이터 디코더(326)는 디코딩된 데이터를 직접 디스플레이 메모리 위치 내에 생성하도록 설정될 수 있거나 데이터가 다른 영역으로 디코딩되고 2D 드로잉 엔진(332), CPU(324) 또는 다른 수단에 의해 의도된 위치로 전송될 수 있다.

RT(300)는 먼저 호스트(100)에 의해 네트워크(190/390)를 통해 제공되는 부가의 정보로 로컬 플래쉬 메모리(도시 생략)로부터 부팅함으로써 초기화될 수 있다. RT의 초기화 시퀀스 동안에, 디스플레이 모니터 기능들을 식별하기 위해 RTSC(314)와 디스플레이 화면(310) 간의 접속이 DDC(Display Data Channel) 인터페이스, EDID(Extended Display Identification Data) 및 기타 확장 등의 표준을 이용하여 역방향 또는 양방향 모드로 사용될 수 있다. 디스플레이 화면(310)에의 접속에서 키보드, 마우스 및 I/O 제어기(316)를 통한 USB 접속도 역시 사용될 수 있다. 이용가능한 해상도 및 제어 등의 정보가 이어서 CPU(324)에 의해 처리된다. 시스템(300)은 호스트(100)와 통신을 할 수 있는 경우 uPnP 등의 프로토콜 또는 다른 발견 메카니즘을 구현할 수 있다. 그 초기화 통신 동안에, CPU(324)는 각각의 RT가 호스트측에서 인스턴스화될 수 있도록 디스플레이 모니터 정보를 비롯한 RT 정보를 호스트(100)에 제공할 수 있다.

초기 디스플레이 화면은 플래쉬 메모리로부터 또는 호스트(100)로부터 온 것일 수 있다. 디스플레이 데이터의 제1 전체 프레임 이후에, 호스트 컴퓨터(200)는 네트워크(390)를 통해 디스플레이 갱신 네트워크 스트림의 일부로서 부분 프레임 정보만을 전송하면 된다. 디스플레이의 픽셀의 어느 것도 이전의 프레임으로부터 변하지 않은 경우, 디스플레이 제어기(330)는 로컬 RAM 저장 장치(312)로부터의 이 전의 프레임 내용으로 디스플레이 화면(310)을 리프레시(refresh)할 수 있다. RTSC(314)의 출력은 HDCP 등의 프로토콜을 사용하여 암호화될 수 있다. 디스플레이 화면(310)이 DVI 등의 케이블로 접속되는 경우, HDCP가 DRM을 갖는 컨텐츠를 재생하기 위한 요건일 수 있다. RTSC(314)는 그에 부가하여 다양한 암호화 키가 칩 외부로 결코 노출되지 않는 아주 안전한 처리 환경을 제공하도록 설계될 수 있다. 훨씬 더 안전한 구현에서, 복호화된 컨텐츠 데이터가 결코 칩의 외부에서 보통문으로 되어 있지 않다. 이러한 안전한 시스템을 달성하기 위해, RTSC(314)는 호스트(100) 및 디스플레이 화면(310)과 수행되는 키 교환과 무관한 로컬 암호 방법을 이용할 수 있다.

디스플레이 갱신은 네트워크 스트림을 통해 전송되고, 캡슐화된 2D 드로잉 명령, 3D 드로잉 명령, 인코딩된 디스플레이 데이터 또는 인코딩된 비디오 데이터로 이루어져 있을 수 있다. 네트워크 제어기(326)는 네트워크 디스플레이 스트림을 수신하고, CPU(324)는 캡슐화 헤더로부터 기능 유닛들(332, 334, 3326, 328) 중 어느 것이 그 패킷에 필요한지를 결정한다. 이 기능 유닛들은 이미지 데이터를 드로잉 또는 디코딩하고 RAM(312)의 해당 영역을 새로운 이미지로 갱신하기 위해 필요한 처리 단계들을 수행한다. 그 다음 리프레시 사이클 동안에, 디스플레이 제어기(330)는 디스플레이 화면(310)에 이 갱신된 프레임을 사용한다.

디스플레이 제어기(330)는 현재의 이미지 프레임의 표현을 RAM(312)으로부터 디스플레이(310)로 전송한다. 통상적으로, 이 이미지는 디스플레이 준비가 된 형식으로 RAM(312)에 저장되어 있지만, RAM 비용이 문제인 경우, 이미지 또는 이미지 의 일부분이 인코딩된 형식으로 저장될 수 있다. 외부 RAM(312)은 원격 단말기 시스템 제어기(314) 내의 대용량 버퍼로 대체될 수 있다. 디스플레이 제어기(330)는 또한 화면(310)에 디스플레이할 출력 이미지를 합성하기 위해 RAM(312)에 저장된 2개 이상의 디스플레이 표면을 결합할 수 있다. 이 합성과 함께 다른 블렌딩 동작들이 수행될 수 있다.

CPU(324)는 RT에 대한 전체적인 디스플레이 동작을 가장 잘 설정 및 관리하기 위해 TSB(400)(도 4 참조, 이하에 기술함)와 통신을 한다. 초기 설정은 RTSC(314)에서 지원되는 기능들의 유형, 디스플레이 화면(310)의 사양, 데이터의 버퍼링 및 캐싱에 이용가능한 RAM(312)의 양, 2D 드로잉 엔진(332)에 의해 지원되는 명령 세트, 3D 드로잉 엔진(334)에 의해 지원되는 명령 세트, 데이터 디코더(326)에 의해 지원되는 형식, 비디오 디코더(328)에 의해 지원되는 형식, 및 디스플레이 제어기(330)의 기능을 열거하는 것을 포함할 수 있다. 런타임 시의 다른 관리 최적화는 디스플레이 비트맵을 재전송될 필요가 없도록 관리하고 RAM(312)에 저장하는 것을 포함한다.

RT(300)의 구성은 보다 종래의 CPU-기반 플랫폼에서 실행 중인 기본적인 데이터 디코딩 아키텍처 또는 소프트웨어를 포함할 수 있으며 인터넷 브라우저 아키텍처에 기초할 수 있다. 인터넷 브라우저 아키텍처의 일부로서, 이 기능 유닛들은 이 기능 유닛들을 직접 호출하는 특별한 브라우저에 의해, 이 기능 유닛들을 사용하는 "플러그 인" 또는 드라이버를 포함하는 브라우저에 의해 사용될 수 있거나, 더 표준적인 브라우저는 어느 요청이 로컬적으로 이행될 수 있고 어느 것이 호스트 시스템 상의 웹 애플리케이션과의 통신을 필요로 하는지를 결정하는 매개물로서 동작하는 로컬 에이전트(local agent)를 사용할 수 있다. "AJAX"(Asynchronous Java Script language and XML" 및 "AFLAX"(Asynchronous Flash and extensible Markup Language) 등의 다른 파생물이 이러한 에이전트 기반 기법이고, 클라이언트에 있는 사용자 인터페이스를 향상시키기 위해 웹 서버와 비동기적으로 데이터를 교환하는 데 XHTML, 자바스크립트(JavaScript)를 통해 조작되는 문서 객체 모델(Document Object Model) 및 "XMLHttpRequest"의 조합을 사용할 수 있다. AJAX는 클라이언트측에서의 데이터 디코딩이 RT(300)의 기능 블록들을 사용하는 경우 선택적인 요청을 수행하는 데 사용될 수 있다.

인터넷 브라우저 기반 RT(300)로부터의 에이전트-기반 선택적 요청은 전체 시스템을 더욱 최적화시키기 위해 호스트 프로세서 블레이드(200) 및 단말기 서비스 블레이드(400)에 의해 지원될 수 있다. 부가적인 통신 프로토콜 처리가 AJAX 에이전트에 의해 수행될 수 있다. 다른 예시적인 AJAX 동작들로는 DNS 탐색 및 보안 키의 관리가 있을 수 있다. RT 상의 AJAX 기반 에이전트는 애플리케이션 서버 또는 웹 서버에 대한 프록시로서 호스트 프로세서 블레이드(200) 또는 TSB(400)를 이용할 수 있다. AJAX 기반 에이전트는 특별한 통신 메카니즘을 포함할 수 있고 프록시의 나머지 부분을 제공하는 호스트 프로세서 블레이드(200) 또는 TSB(400)를 갖는 분할 프록시로서 동작할 수 있다.

도 4는 블레이드 기반 다중-사용자 컴퓨터 시스템(100)에 대한 TSB(Terminal Services Blade)(400)의 제2 양호한 실시예를 나타낸 것이지만, TSB(400)는 다른 대안으로서 네트워킹을 통해 호스트 프로세서에 연결되어 있는 별도의 컴퓨터 또는 가전 제품으로서 구현될 수 있다. 가전 제품으로서, TSB(400)는 서버의 디스플레이 출력에의 DVI 또는 기타 케이블과 같은 다른 비네트워크 접속(non-network connection)을 포함할 수 있으며 로컬 디스플레이 장치에 대한 지원을 유지하기 위해 로컬 DVI 출력을 포함할 수 있다. TSB(400)로부터의 이러한 DVI 출력은 서버로부터의 패스-쓰루 모드(pass-through mode)일 수 있거나 DVI 케이블 상의 데이터가 간단한 패스-쓰루 동작에 적합하지 않은 경우 디코딩 단계를 거칠 수 있다. TSB(400)는 다수의 RT에 대한 프록시 서버로서 기능하기 위해 호스트 프로세서와 독립적으로 동작할 수 있다.

TSB(400)는 CPU 서브시스템(402), 메모리(434), 브리지 제어기(404), RAM(432)을 갖는 로컬 I/O(428), 및 TSA-GPU[단말기 서비스 가속기(Terminal Services Accelerator) 및 다중-사용자 그래픽 프로세서 유닛 서브시스템(Multi-User Graphics Processor Unit subsystem)](700)을 구성하는 컴포넌트들을 포함한다. 브리지 제어기(404)는 스위치 패브릭과 직접 인터페이스할 수 있거나 스위치 패브릭(140, 142)에 접속하기 위한 패브릭 인터페이스(130)를 포함할 수 있다. TSA-GPU(700) 내의 주요 기능 유닛들은 연관된 RAM(418, 430)을 가지며 디스플레이 인터페이스(220)를 통한 접속(222)을 포함할 수 있는 다중-사용자 GPU(MU-GPU)(412) 및 TSA(Terminal Services Accelerator)(424)이다. 일부 구성에서, TSA-GPU는 공유 RAM을 가지며, 도 7을 참조하여 이하에 기술되는 바와 같이 더 통합될 수 있다.

단일의 TSB가 다수의 프로세서 블레이드(200)(각각의 블레이드가 하나 이상의 CPU를 가지며 각각의 CPU는 하나 이상의 프로세서 코어를 가짐)에 대한 그래픽 연산을 수행할 수 있으며, 다수의 가상 머신이 CPU와 프로세서 코어의 믹스(mix)에서 실행되고 있다. 일부 다중-사용자 또는 다중-프로세서 운영 체제에서, TSB(400)에 대한 요청이 조정된 방식으로 관리 또는 수행될 수 있다. 예를 들어, Microsoft RDP(Remote Desktop Protocol) 또는 Citrix ICA 기반 시스템의 경우에, 디스플레이 명령은 이미 가상화되어 있으며 프로세서 블레이드(200)가 그래픽 서브시스템에 직접 액세스하려고 시도하지 않는다. 기타 다중-사용자 또는 다중-프로세서 운영 체제는 그래픽 서브시스템에의 액세스를 직렬화하는 조정된 수단을 포함할 수 있으며, 운영 체제와 결합된 TSB(400)는 단일의 TSA(700)가 하나 이상의 다중-사용자 운영 체제에 대한 다수의 디스플레이를 지원할 수 있도록 조정된 액세스가 적절히 매핑될 수 있게 해줄 수 있다.

그렇지만, 가상 머신 모드에서, 서로 다른 가상 머신이 서로를 모르고 있을 수 있으며, 각각의 가상 머신은 전용의 그래픽 서브시스템에 대한 완전한 액세스 권한을 갖는 것으로 가정할 수 있다. 이러한 경우에, TSB(400)는 다수의 가상 머신으로부터의 비동기 명령 및 요청을 질서있는 방식으로 만족시키기 위해 또한 RT에 대한 결과 디스플레이를 적절히 지원하기 위해 가상 추상화 계층(virtual abstraction layer)을 생성할 필요가 있다. TSB(400)는 프로세서 블레이드(200)의 서로 다른 가상 머신 상에서 실행될 수 있는 서로 다른 운영 체제에 대한 그래픽 드라이버를 작성할 수 있다. TSB(400)는 이어서 서로 다른 운영 체제로부터의 드 라이버 호출을 조정된 다중-디스플레이 TSA(700) 동작들로 조정한다. 다른 대안으로서, 각각의 운영 체제는 표준의 그래픽 드라이버를 이용하고, TSB(400)는 사실상 드라이버 호출을 가로채기할 필요가 있다. 가로채기된 드라이버 호출은 이어서 TSA(700)를 일관된 다중-디스플레이 모드로 동작시키고 각각의 가상 머신에 대한 디스플레이를 적절히 관리하도록 관리된다.

일부 시스템에서, TSB(400)의 기능들 중 하나는 각각의 RT가 향상된 디스플레이 경험을 갖도록 프로세서 블레이드(200)를 각각의 RT에 대한 관리의 일부로부터 오프로드하고 오프로드된 처리의 일부를 가속시키는 것이다. 오프로드 및 가속 지원의 유형들은 그래픽 동작들을 원격 그래픽 명령에 캡슐화하는 것, 어느 그래픽 명령이 가장 적합한지를 결정하기 위해 어느 기능 및 비트맵이 각각의 RT에 캐싱되어 있는지를 판정하는 것을 돕는 것, RT로 전송될 필요가 있는 비트맵을 인코딩 및 캡슐화하는 것, 및 멀티미디어 비트스트림을 가장 잘 관리하는 것을 포함한다. 다른 대안으로서, 브라우저 및 에이전트 기반 RT는 전송 이전에 TSB(400)에 의해 인코딩될 수 있는 그래픽 데이터의 갱신을 제공하도록 호스트(100)에 더 구체적인 요청을 개시할 수 있다. 양호한 일 실시예에서, 호스트 시스템(100)은 웹 서버이고, 이 경우 프로세서 블레이드(200)는 웹 서버 기능의 데이터 베이스 및 "백 엔드" 동작을 수행하고 TSB(400)는 웹 서버 기능의 디스플레이 요소를 관리하는 미디어 코프로세서로서 동작한다.

XML(extensible Markup Language) 트래픽, SOAP(Simple Object Access Protocol), HTTP 트래픽, JVM(Java Virtual Machine) 및 인터넷 기반 통신과 연관 된 기타 트래픽의 조사(inspection) 및 캡슐화(encapsulation) 등의 부가의 기능들도 역시 지원될 수 있다. 프로세서 블레이드(200)는 TSB(400)와 함께, 임의의 원하는 스팸 방지(anti-spam), 안티-바이러스(anti-virus), 컨텐츠 필터링, 액세스 제한 시행(access restriction enforcement) 또는 기타 패킷 필터링 기반 알고리즘을 수행하는 동안, RT가 전체 인터넷에의 원격 액세스를 효과적으로 수행할 수 있게 해줄 수 있다. 이러한 부가적인 기능들은 호스트를 웹 컨텐츠 액세스를 위한 프록시로 사용하여 RT 인터넷 브라우징을 지원하는 데 특히 유용할 수 있다. 시스템에 어떤 중복성이 있을지라도, 이 방법은 호스트 시스템과 WAN 사이에서 이용되는 보다 일반적인 네트워크 보안 가전 제품보다 더 구체적인 사용자 제어를 제공할 수 있다. TSB(400)는 DNS 탐색 등의 다른 오프로드 기능들을 제공할 수 있다. DNS 탐색을 제공하는 것은 설정 및 관리될 필요가 있는 TCP/IP 접속의 수에 대한 감소를 가능하게 해줄 수 있다. TSB(400)는 또한 SSL 등의 보안에 대한 오프로드를 제공할 수 있다. 그에 부가하여, TSB(400)는 보안 클라이언트에 대한 인증서-기반 암호 알고리즘 지원(certificate-based crypto algorithm support)을 제공할 수 있다.

TSB(400) 상의 특별한 프록시 서버는 RT 디스플레이 장치 및 RT 내의 실행 기능에 따라 인터넷 기반 컨텐츠를 재형식화(reformat)하거나 재코딩(recode)하는 것을 포함할 수 있는 인터넷 기반 트래픽을 위한 다른 개선들을 사용할 수 있다. 예를 들어, RT 장치가 제한된 화면 해상도를 갖는 셀룰러 전화 또는 PDA(Personal Digital Assistant)인 경우, TSB(400)는 더 빠르고 더 적절한 디스플레이를 위해 고해상도 컨텐츠를 저해상도 이미지로 하향 필터링(filter down)할 수 있다. TSB(400)는 핵심 정보가 셀 전화로 전송될 수 있도록 배너 광고 및 기타 외부 정보를 제거하는 것과 같은 기능들을 수행하기 위해 다른 더 지능적인 컨텐츠 필터링 및 웹 페이지 해석 알고리즘을 실행할 수 있다. TSB(400)는 전체 웹 브라우저를 실행할 수 있고, RT는 성능이 떨어지는 웹 브라우저, 즉 마이크로-브라우저(micro-browser)를 실행한다. TSB(400)의 프록시 기능은 진보된 웹 형식을 RT의 브라우저에 의해 이해될 수 있는 웹 형식으로 변환할 수 있다.

Active-X 컨트롤, 매크로미디어 플래쉬 또는 기타 런타임 프로그램을 이용하는 것 등의 다른 유형의 웹 컨텐츠는 전화 또는 PDA 등의 장치와 호환되지 않을 수 있다. TSB(400)는 중간 프록시 서버로서 동작하여 디스플레이 데이터 포스트-Active-X 컨트롤(post-Active-X control)을 대기 중인 PDA로 전송할 수 있다. 애플리케이션 계층 정규식(Regular Expression)(RegEx) 컨텐츠 처리도 역시 수행될 수 있다. 재형식화 및 재코딩(re-coding)은 또한 클라이언트에 대한 보안을 향상시키기 위해 수행될 수 있다. XML 및 SOAP가 하이재킹(hijacking) 및 다른 형태의 바이러스 유포에 노출될 수 있는 반면, TSB(400)는 RT 클라이언트가 이러한 위험에 노출되지 않도록 XML 및 SOAP를 안전한 디스플레이 형식으로 재코딩할 수 있다.

다른 실시예에서, 호스트(100) 또는 보다 구체적으로는 TSB(400)는 RT가 그렇지 않았으면 판독할 수 없었을 파일을 보도록 하기 위해 보다 일반적인 다중-형식 네트워크 파일 프록시 서버로서 사용된다. 예를 들어, RT는 다양한 디스플레이 형식에 대한 뷰어를 포함할 수 있지만, Adobe PDF 파일 또는 Microsoft Word 문서 를 열고 보는 기능을 포함하지 않을 수 있다. RT 상의 뷰어는 다양한 HTML 및 기타 웹 지향 형식을 지원하는 브라우저일 수 있다. 호스트(100)는 Adobe PDF 파일 또는 Microsoft Word 문서 둘다를 열고 보는 것을 할 수 있을 수도 있다. 호스트(100)는 이어서 PDF 파일 또는 Word 문서로부터의 그래픽 출력을 RT에서 보기 위한 호환가능한 디스플레이 형식으로 변환하기 위해 TSB(400)의 기능들을 사용할 수 있다. RT는 많은 유형의 데이터 파일로의 네트워크 링크를 가질 수 있으며, 다중-형식 프록시 뷰어를 이용함으로써, 그렇지 않았으면 RT 자체에서 보기 위해 디코딩될 수 없었을 많은 유형의 파일들을 볼 수 있다. 이러한 유형의 다중-형식 프록시 보기는 네트워크 파일 공유 기능과 또는 메일 서버와 결합될 수 있다. 예를 들어, 다중-형식 프록시 뷰어가 파일 첨부물을 셀 전화 RT가 볼 수 있는 형식으로 변환하는 경우, 각종의 첨부물을 갖는 이메일을 수신할 수 있을 수도 있다. 볼 수 있는 첨부물이 메일 메시지에 포함되어 있을 수 있거나 볼 수 있는 버전의 첨부물에 대한 링크가 메일 메시지에 포함되어 있을 수 있다.

멀티미디어 비트스트림은 이미 압축된 형식으로 되어 있고 도 2의 프로세서 블레이드(200) 또는 도 4의 TSB(400)에서 수신되고 있는 비디오 스트림을 포함할 수 있다. 일부 구성에서, 멀티미디어 비트스트림은 이미 의도된 RT(300)와 호환가능한 형식으로 되어 있다. 이러한 경우에, 프로세서 블레이드(200) 상에서 실행 중인 소프트웨어 추적 계층은 이 비트스트림을 TSB(400)로 보내고, TSB(400)는 이 비트스트림을 RT로 전송하기 위해 적절한 패킷 형식으로 캡슐화한다. 캡슐화는 비디오 디스플레이 창의 원점(origin) 등의 헤더 정보를 추가하는 것, 또는 전송 스 트림을 다른 패킷 크기를 갖는 프로그램 스트림으로 변환하는 것과 같은 패킷 구성을 수정하는 것을 포함할 수 있다.

몇몇 다른 경우에, 멀티미디어 비트스트림은 목표 RT에 의해 즉각 처리되는 형식으로 되어 있지 않거나 네트워크 접속에 적절한 형식으로 되어 있지 않다. 이러한 경우에, TSB(400)는 트랜스코딩 프록시 서버(transcoding proxy server)로서 동작하고 멀티미디어 비트스트림을 디코딩(decoding) 및 재인코딩(re-encoding), 트랜스코딩(transcoding) 또는 트랜스레이팅(transrating)하는 더 복잡한 단계들을 수행한다. 예를 들어, 들어오는 멀티미디어 비트스트림이 인코딩된 HDTV MPEG-2 스트림일 수 있다. RT에서의 창 크기가 작은 320 x 240 창으로 설정되어 있는 경우, 네트워크 대역폭을 보존하고 TSB(400)가 비디오를 원하는 디스플레이 창 크기를 나타내는 하위 비트레이트로 트랜스코딩 및 트랜스레이팅하게 하는 것이 타당할 수 있다. 이와 마찬가지로, 들어오는 비디오가 RT가 디코딩할 수 없는 형식으로 되어 있는 경우, TSB(400)는 비디오를 호환가능한 형식으로 트랜스코딩할 수 있다. 이 형식이 호환가능인 경우에도, DRM(Digital Rights Management) 또는 암호화 방식 등의 다른 비호환이 존재할 수 있다. TSB(400)는 또한 한 DRM 또는 암호화 방식에서 목표 RT에 적합한 방식으로 변환할 수 있다.

예를 들어, 컨텐츠 소유자는 Apple의 iTunes에 의해 사용되는 것과 같은 독점 키 교환(proprietary key exchange)에 기초한 DRM 방식을 사용할 수 있다. TSB(400)는 프로세서 블레이드(200) 또는 로컬 CPU(402)에서 실행 중인 iTunes 비디오 플레이어의 출력을 조사하고 복호화된 컨텐츠를 캡처할 수 있다. 디코딩된 출력은, 이 출력이 DVI 비디오 버스로부터 온 것인 경우, 여전히 HDCP로 암호화되어 있을 수 있다. HDCP의 경우에, TSB(400)는 HDCP 보호 컨텐츠를 디코딩하기 위해 적절한 키를 가지고 있을 필요가 있으며, 복호화를 수행하기 위해 디스플레이 장치로서 기능할 수 있다. 컨텐츠 소유자의 통제권을 보존하기 위해, TSB(400)는 이어서 컨텐츠를 원격 클라이언트 재생 장치에 의해 이해되는 프로토콜로 재암호화하게 된다. 이것은 DTCP(Digital Transmission Content Protection) 또는 마이크로소프트의 현재의 형식 등의 상업적으로 이용가능한 프로토콜에 기초할 수 있거나, 독점 프로토콜을 사용할 수 있다. 일단 재암호화되었으면, 새로 보호된 데이터 스트림이 네트워크를 통해 적절한 복호화 및 디스플레이 기능을 갖는 수신 장치로 전송될 수 있다.

몇몇 현재 버전의 Microsoft의 RDP(Remote Desktop Protocol)는 압축된 비디오 비트스트림에 대한 덜 효율적인 처리를 제공한다. RDP의 경우, 호스트 시스템 내의 드라이버들은 비트스트림을 검출하고 이를 DIB(Device Independent Bitmap)로 디코딩한다. 이 DIB는 이어서 RDP 전송 명령으로 변환되고, DIB 형식 데이터는 신뢰성없이 네트워크를 통해 RT로 전송된다. 대부분의 경우에, DIB 데이터의 2개의 프레임만이 디스플레이를 위해 RT로 간다. 따라서, 호스트 CPU가 디코딩을 수행하는 데는 물론 디코딩된 데이터를 덜 효율적인 형식으로 네트워크를 통해 전송하는 데 비효율성이 있다. 다른 RDP 기반 그래픽 동작도 DIB를 사용한다.

웹 사이트로부터의 그래픽 비트맵 등의 종래의 그래픽 비트맵도 호스트(100)로부터 RT(300)로 전송될 필요가 있다. TSB(400)는 DIB 등의 종래의 그래픽 비트 맵에 대해 여러가지 레벨의 인코딩을 수행할 수 있다. 그래픽 비트맵의 인코딩은 시각적으로 구별할 수 없는 원래의 그래픽 품질의 표현을 제공하기 위해 무손실 인코딩이거나 손실 인코딩일 수 있다. TSB(400)에 대한 간단화된 소프트웨어 인터페이스는 RDP API를 통해 호스트 CPU와 인터페이스하는 것만을 포함할 수 있는 반면, 보다 적극적인 구현은 TSB(400)가 기반을 이루는 DirectX 드라이버 프레임워크에 액세스할 수 있게 해준다. 인코딩된 DIB 전송 및 특별한 압축된 비디오 영역 전송은 표준의 RDP 구현의 일부가 아니다. 따라서, 이들 전송은 기존의 RDP 전송 형식에 피기백될 수 있거나, 몇몇 유형의 사설 RDP 확장(private RDP extension)으로서 동작할 수 있거나, RDP 프레임워크의 외부에서 동작할 수 있다.

일부 버전의 호스트 운영 체제 및 RDP는 RDP 프로토콜에 대한 부가의 보안 요건을 만족시킬 필요가 있다. RDP 클라이언트는 암호화된 패킷을 이용하기 위해 호스트와 키를 교환해야만 할 수도 있다. TSB(400)가 RDP 클라이언트 패킷을 가로채기하기 때문에, TSB(400)는 키 교환을 위한 적절한 가속화 및 오프로드와, 호스트 프로세서와 통신하기 위한 복호화를 포함할 수 있다. 그에 부가하여, 시스템의 보안을 유지하기 위해, TSB(400) 및 네트워크 인터페이스는 RT와의 모든 통신이 적절히 암호화되도록 한다.

다른 실시예에서, TSB(400)는 웹 서버의 일부이거나 다수의 웹 서버의 통합점(aggregation point)인 웹 서버 오프로드 엔진으로서 동작할 수 있고, 브라우저 및 에이전트 기반 RT를 지원할 수 있다. JAVA, 데이터 인코딩, 데이터 트랜스코딩 및 기타 기능들을 위해 웹 서버 가속화가 수행될 수 있다. 다른 양호한 실시예에 서, RT는 AJAX 등의 다수의 프로토콜에 대한 지원을 포함하는 더 지능적인 에이전트 기반 브라우저를 실행할 수 있다. AJAX 또는 유사한 방법을 사용하는 브라우저는 사용자 동작 동안에 브라우저 내에서 정보를 유지 및 관리할 수 있고 새로운 정보가 필요할 때 웹 서버와 접촉하기만 하면 된다. 서버가 전체 프레임을 전달하는 대신에, AJAX가 더 구체적인 정보 요청이 수행될 수 있게 해주고, 웹 서버는 단지 그 새로운 정보를 제공하기만 하고, 이 새로운 정보가 이어서 새로운 프레임을 로컬적으로 발생하기 위해 이전에 저장된 정보와 함께 사용된다. 이러한 존속성(persistence)은 정보를 프리페치(prefetch)함으로써, 더 적고 보다 효율적인 요청을 요구함으로써, 또한 보안을 관리함으로써 사용자 인터페이스를 개선시키는 데 사용될 수 있다. AJAX에 의해 발생된 요청은 TSB(400)에 의해 관리될 수 있으며, 이 경우 보안이 유지될 수 있고 데이터가 TSB(400)에 의해 효율적으로 인코딩될 수 있으며, 데이터가 AJAX 및 RT(300)의 기능 블록들을 사용하여 클라이언트측에서 디코딩될 수 있다.

잘 설계된 AJAX 웹 애플리케이션은 객체를 캐싱하고 전체 프레임을 전송할 필요를 줄이기 위해 클라이언트 또는 프록시의 기능을 이용하며, 이 경우 TSB(400)가 임의의 프레임 데이터의 첫번째 요청을 인코딩하는 데 여전히 사용될 수 있다. 선택적 갱신을 하도록 설계되지 않은 웹 애플리케이션의 경우, TSB(400)는 이러한 웹 애플리케이션과 AJAX 기반 브라우저 간의 프록시로서 사용될 수 있다. 호스트(100)는 웹 서버가 아닐 수 있으며, ISP(Internet Service Provider) 또는 POP(Point of Presence)에 위치한 서버일 수 있다. 프록시로서, 호스트(100) 또는 TSB(400)는 클라이언트의 요청(client driven request)에 기초하여 선택적 갱신을 수행하기 위해 RT(300)와 조정을 할 수 있다. 웹 애플리케이션이 전체 프레임 갱신을 요구하는 경우에도, TSB(400) 프록시는 새 프레임과 이전 프레임을 처리하고 비교하여 클라이언트에 인코딩된 갱신 정보를 제공할 수 있다. 이것은 선택적 갱신을 하도록 특별히 설계되지 않은 웹 애플리케이션에 대해서도 대역폭의 감소 및 RT(300)에 대한 개선된 사용자 인터페이스를 가능하게 해줄 수 있다.

TSB(400)는 몇가지 관련없는 동작에 대한 일반적인 오프로드 태스크도 역시 해결하는 프로그램가능한 솔루션으로 구현될 수 있다. 서버는 네트워크, 저장 장치, 보안 및 기타 태스크를 오프로드하는 것으로부터 이득을 볼 수 있다. 오프로드 프로세서는 다양한 오프로드 태스크를 정적으로 또는 동적으로 분산시키고 임의의 주어진 작업 부하에 대한 전체적인 시스템 처리용량을 증대시키도록 설계될 수 있다. 예를 들어, 서버는 주간에 씬 클라이언트에 대한 서버 기반 계산을 수행하고 야간에 대규모 데이터베이스 연산을 수행하고 있을 수 있다. 주간에, 오프로드 엔진은 TSA에 대해 기술된 동작들을 실행한다. 야간에, 오프로드 엔진은 디스크 저장 장치 시스템으로부터 대규모 데이터베이스에 액세스하기 위해 iSCSI 가속화를 실행한다. 이 유연성이 다양한 작업 부하를 추적하는 온보드(on-board) 또는 시스템 전반적인 관리 절차에 의해 관리될 수 있다. 오프로드 태스크들 간에 전환하기 위한 입도(granularity)는 극히 작을 수 있다. 오프로드 엔진은 단일 세션 내에 동일한 세션에 대한 네트워크, 단말기 서비스, 저장, 보안 및 기타 오프로드 태스크를 수행할 수 있게 아주 빠른 컨텍스트 전환을 수행하도록 설계될 수 있다.

서로 다른 오프로드 태스크에 대한 동적 처리를 지원하기 위해, TSB(400)는 프로그램가능하고 구성가능하며 또한 작업 부하가 변하는 즉시 신속하게 태스크 전환 및 재구성될 수 있는 처리 블록을 사용한다. 다양한 메모리 블록이 각각의 처리 블록에 포함되어 있으며, 대용량 메모리(434)도 역시 포함될 수 있다. CPU(402)는 그 자신의 캐시 메모리를 포함하는 일반적으로 프로그램가능한 프로세서이며 오프로드에 대한 하우스키핑(housekeeping) 및 관리를 수행할 수 있음은 물론 상위 레벨 프로토콜 및 인터페이스 처리의 일부도 수행할 수 있다. 브리지 제어기(404)는 네트워크 프로세서들을 통합하고 TSB(400)의 스위치 패브릭 인터페이스(switch fabric interface)(130) 기능들을 관리할 수 있으며, 다수의 동시 통신 파이프(multiple pipes of simultaneous communication)를 관리할 수 있다. CAM(Content Address Memory) 등의 특별한 내부 메모리는 물론 종래의 메모리도 역시 브리지 제어기(404) 내에 포함될 수 있다.

브리지 제어기(404) 및 TSA-GPU(700)의 처리 장치는 전용의 하드웨어 블록과 통상적으로 연관된 처리용량으로 다른 처리를 수행하게 즉각 재구성되도록 설계되어 있는 CDP(Configurable Data Processor)로 구현될 수 있다. 전용의 하드웨어 대신에 CDP를 이용함으로써, 서로 다른 오프로드 태스크들이 동일한 하드웨어로 수행될 수 있다. 재구성가능 데이터 경로, 동적 명령어 세트, VLIW(Very Long Instruction Word), SIMD(Single Instruction Multiple Data), MIMD(Multiple Instruction Multiple Data), DSP(Digital Signal Processing) 및 기타 형태의 재구성가능 컴퓨팅 등의 CDP를 설계하는 종래 기술의 방법들이 초고성능 계산을 수행 하기 위해 결합될 수 있다. CDP는 또한 암호 및 키 관련 기능들을 위한 부가의 전용 하드웨어 블록을 갖는 또는 갖지 않는 보안 프로세서로서 기능할 수 있다.

단말기 서비스 가속화 및 프록시 서버 동작을 위해, CDP는 타일 및 직사각형에 대한 데이터 인코딩, 비디오 또는 데이터에 대한 다양한 형태의 트랜스코딩 또는 트랜스레이팅, 타일 서명(tile signature)의 발생 및 비교, 및 TSA-GPU(700)와 관련하여 이하에 기술되는 기타 태스크들을 수행하도록 구성될 수 있다. 저장 가속화를 위해, CDP는 iSCSI, FC(Fiber Channel), FCIP(Fiber Channel Internet Protocol) 및 인터넷 프로토콜 관련 태스크들의 서로 다른 양태들을 위해 구성될 수 있다. 접속(490)은 FC 또는 다른 저장 프로토콜에 접속하도록 구성될 수 있다. 인터넷 컨텐츠 가속화를 위해, CDP는 XML 트래픽, SOAP, HTTP 트래픽, JVM, 및 인터넷 기반 통신과 연관된 기타 트래픽을 처리하도록 구성될 수 있다. 다른 웹 서버 가속화는 DNS 탐색을 오프로드하는 것 및 TCP/IP 접속을 처리하는 것은 물론, 종래의 웹 클라이언트 및 AJAX-스타일 에이전트 기반 브라우저 둘다에 대한 데이터 인코딩 및 트랜스코딩을 수행하는 것도 포함할 수 있다.

TSA-GPU(700)는 TSB(400)의 그래픽 관련 오프로드 및 가속화 기능들을 수행한다. 패킷을 통해 선택적 디스플레이 갱신에 대한 지원을 포함하고 양호한 실시예를 통해 제안된 VESA DPVL(Digital Packet Video Link) 표준의 일부 또는 그 전부를 따를 수 있는 MU-GPU(Multi-User Graphics Processor Unit)(412)는 향상된 기능을 포함한다. TSA(424)는 시스템 버스(406)를 통해 MU-GPU(412)로부터의 패킷 디스플레이 갱신을 지원하거나 양호하게는 직렬 디지털 비디오 출력(SDVO1, SDVO2) 또는 서로 다른 버스폭, 시그널링 프로토콜 및 주파수를 갖는 일반화된 포트일 수 있는 입력 경로(414, 416)를 지원한다. 예로는 DVO(Digital Video Output), DVI(Digital Visual Interface), HDMI(High Definition Multimedia Interface), 디스플레이 포트(Display Port) 또는 기타 LVDS(Low Voltage Differential Signaling), TMDS(Transition Minimized Differential Signaling), PCI 익스프레스 또는 다른 방식이 있다. 디스플레이 출력 경로는 높은 리프레시 레이트(refresh rate)로 다수의 비디오 프레임을 출력하기에 충분한 속도로 동작될 수 있으며, 여기서 프레임은 2개 이상의 목표 RT에 대응하는 선택적인 갱신 직사각형일 수 있다. TSA(424)는 메인 시스템 버스(406)를 통해 전용 링크(426)를 거쳐 로컬 I/O 또는 네트워크 제어기에 접속될 수 있거나 SOC(System on Chip) 구현을 통해 보다 밀접하게 통합될 수 있다. 제2 시스템 버스(408)도 역시 부가의 대역폭을 위해 또한 브리지 제어기(404) 및 다수의 스위치 패브릭에 대한 그의 인터페이싱을 보다 직접적으로 지원하기 위해 포함될 수 있다.

종래의 그래픽 처리를 수행하는 것에 부가하여, MU-GPU(412)는 디스플레이의 어느 부분이 변하였는지를 나타내는 디스플레이 기반 선택적 갱신을 생성한다. 선택적 갱신은 비디오 출력 경로(414 또는 416)를 통해 또는 메인 시스템 버스(406)를 통해 출력되는 직사각형 또는 타일의 형태를 취할 수 있다. 직사각형 갱신은 창의 원점, 크기 및 형식을 나타내기 위해 패킷 헤더를 포함한다. 원점은 어느 RT가 목적지인지를 나타내는 데 사용될 수 있다. 타일도 역시 사용될 수 있으며, 헤더가 타일을 기술하기 위해 더 적은 정보를 필요로 할 수 있도록, 타일이 하나 이 상의 고정된 크기로 표준화될 수 있다. 직사각형 또는 타일이 RT에서 스케일링되는지 및 어떻게 스케일링되는지 등의 기타 정보도 역시 헤더에 포함될 수 있다. 다른 형태의 선택적 갱신은 BitBlt, 영역 채움(Area Fill) 및 패턴 채움(Pattern Fill)에 대한 지원을 포함하며, 이 경우 큰 데이터 블록을 전송하는 대신에, RT에서 수행될 동작에 대한 명령 파라미터와 함께 최소량의 데이터가 전송된다. 기타 헤더들은 비디오 스트림(Video Stream), Genlock, 스케일링된 비디오 스트림(scaled video stream), 감마 테이블(Gamma Table) 및 프레임 버퍼 제어(Frame Buffer Control)의 형태로 갱신을 지원한다. 기타 개량된 복잡한 명령도 역시 RT에 대한 선택적 갱신의 형태에 들어갈 수 있다. 제안된 DPVL 규격은 선택적 갱신에 대한 한가지 가능한 구현을 그의 헤더와 함께 상세히 기술하고 있다.

한가지 MU-GPU(412)는 RAM(418)을 다양한 디스플레이 표면들(각각이 다수의 RT에 대한 디스플레이 데이터를 포함함)로 구성함으로써 모든 RT(300)에 대해 이 시스템에 의해 효과적으로 가상화될 수 있다. MU-GPU(412)의 2D, 3D 및 비디오 그래픽 프로세서(도시 생략)는 양호하게는 높은 그래픽 및 비디오 성능을 달성하기 위해 이용된다. 그래픽 처리 유닛은 2D 그래픽, 3D 그래픽, 비디오 인코딩, 비디오 디코딩, 스케일링, 비디오 처리 및 기타 진보된 픽셀 처리를 포함할 수 있다. MU-GPU(412)의 디스플레이 제어기는 또한 비디오 및 그래픽 데이터의 블렌딩(blending) 및 키잉(keying) 등의 기능들은 물론 전체 화면 리프레시 동작을 수행할 수 있다. 1차 및 2차 디스플레이 표면에 사용되는 RAM(418)에 부가하여, 다양한 3D 및 비디오 동작을 지원하기에 충분한 오프-스크린 메모리(off-screen memory)가 있다. 선택적 갱신을 관리하는 DPVL 방법에 대한 대안으로서, RAM(418) 내에 선택적 갱신 버퍼 메모리(S-버퍼)(404)가 있을 수 있다. 일 실시예에서, S-버퍼(404)는 각각의 가상 디스플레이에 대한 각각의 타일에 대응하는 상태 비트, 서명, 또는 상태 비트와 서명 둘다를 저장한다. 다른 실시예에서, S-버퍼(404)는 헤더, 상태 비트 및 서명 정보를 갖는 또는 갖지 않는 타일 자체를 저장하며, 여기서 타일은 선택적 갱신을 위해 출력되도록 구성되어 있다.

그래픽 엔진 및 디스플레이 제어기는 통상적으로 각각의 RT 디스플레이에 대한 1차 표면에 대응하는 전체 디스플레이 이미지를 합성한다. RAM(418)은 사실상 모든 RT에 대한 디스플레이 프레임의 어레이를 포함한다. 예를 들어, 디스플레이 메모리가 16K x 16K 픽셀의 가상 디스플레이로서 구성될 수 있기 때문에, 이러한 예시적인 응용에서, 1K x 1K의 256개 RT 디스플레이는 16K x 16K 어레이에 매핑될 수 있다. 이와 유사하게, 각각의 RT가 256 x 128 디스플레이를 갖는 셀룰러 전화인 경우, 8192개의 가상 디스플레이가 16K x 16K 디스플레이 영역에 매핑될 수 있다. 부가의 오프 스크린(off screen) 및 스크래치 메모리(scratch memory)도 역시 포함될 가능성이 있다. 이 응용이 다수의 독립적인 RT를 필요로 하기 때문에, MU-GPU(412)는 다른 디스플레이 영역을 보호하고 한 사용자가 다른 사용자의 프레임 버퍼에 액세스하지 못하도록 하기 위해 다른 보안 특징들을 추가할 수 있다. 이 시스템은 양호하게는 보안 및 신뢰성 문제 둘다를 위해 디스플레이 메모리의 보호 부분에의 불법 액세스를 방지하는 하드웨어 로크(hardware lock)를 포함한다.

도 5는 도 4의 메모리(418)의 예시적인 구성을 나타낸 것으로서, 여기서 가 상 디스플레이 공간은 수평 3200 픽셀 및 수직 4800 픽셀로 설정되어 있다. 메모리(418)는 520, 522, 524, 526, 528, 530, 532 및 534로 표시된 8개의 1600 x 1200 디스플레이 영역으로 분할된다. 통상적인 고품질 디스플레이 모드는 픽셀당 24 비트의 비트 깊이(bit depth)로 구성되지만, 종종 이 구성은 보다 쉬운 정렬을 위해 또한 디스플레이가 그래픽 및 비디오 프로세서에 의해 액세스될 때 다른 목적을 위한 부가의 8 비트의 사용 가능성을 위해 RAM(418)에서 구성되는 바와 같이 픽셀당 32 비트를 이용할 수 있다. 타일링된 메모리(tiled memory)의 예시는 MU-GPU(412)에서 본 것으로서 사실상 개념적인 것이다. 실제의 RAM 어드레싱(addressing)은 메모리 페이지 크기 및 다른 고려사항에도 관련되어 있다.

도 5는 디스플레이 영역(528)에 디스플레이 갱신 직사각형(550)을 더 나타내고 있다. 1600 x 1200 디스플레이의 점선(540)은 구역(precinct)이라고 하는 256 x 256 픽셀의 훨씬 더 조악한 블록 경계에 대응한다. 디스플레이 창(550)으로부터 명백한 바와 같이, 디스플레이 창 경계의 정렬이 반드시 구역 경계와 일치할 필요가 없다. 이것이 통상적인 상황인데, 그 이유는 사용자가 디스플레이 화면 상에서 창의 크기 및 위치를 임의로 지정하기 때문이다. 전체 프레임이 갱신될 필요가 없는 원격 화면 갱신을 지원하기 위해, 디스플레이 창(550)에 의해 영향을 받는 각각의 구역이 갱신될 필요가 있다. 게다가, 디스플레이 창(550) 및 주변의 디스플레이 픽셀 내의 데이터 유형은 완전히 다른 유형일 수 있고 상관되어 있지 않을 수 있다. 그 자체로서, 구역 기반 인코딩 알고리즘은, 손실 알고리즘인 경우, 구역의 에지 또는 디스플레이 창(550)의 경계와 연관된 시각적 아티팩트(visual artifact) 가 없도록 할 필요가 있다. 실제의 인코딩 프로세스는, 8 x 8 또는 16 x 16 등의, 구역보다 더 작은 블록에 대해 행해질 수 있다. 따라서, 양호한 실시예는 결정론적 인코딩 알고리즘을 사용하며, 이 경우 주변의 픽셀에 상관없이 일련의 픽셀에 대해 동일한 결과가 얻어지고, 창의 임의적인 정렬에 의해 아티팩트가 생성되지 않는다.

인코딩 방식에 대한 블록 경계도 역시 타일과 관련한 고려사항이다. 예를 들어, 인코딩 방식은 8 픽셀의 배수로 블록 경계를 필요로 할 수 있다. 소스 타일이 8 픽셀의 배수가 아닌 경우, 주변의 데이터로 패딩될 필요가 있다. 다른 경우에, 종종 특정의 사용자-배치 직사각형 또는 타일이 아니라 화면에 맞춰 블록 경계를 배향하는 것이 선호된다. 사용자가 80 x 80 픽셀인 창을 조작하는 경우, 이론적으로는 이 창이 수평 및 수직 방향 각각에서 최소 10개의 8 x 8 픽셀(총 100개의 블록)을 사용하도록 배치될 수 있지만, 각각의 방향에서 11개의 블록(121개 블록)에 걸쳐 있을 가능성이 더 많다. 직사각형 갱신 및 임의의 진행 중인 직사각형 인코딩은 따라서 88 x 88 픽셀(121개 블록)을 인코딩하며, 이 경우 주변 픽셀의 일부는 패딩을 위해 필요하다.

서로 다른 크기의 디스플레이를 갖는 RT도 역시 지원될 수 있다. 일례에서, MU-GPU(412)는 임의의 수의 임의의 크기 디스플레이를 지원할 수 있다. 다른 예에서, 서브-창(sub- window)으로서 소화면 디스플레이를 지원하거나 2개 이상의 디스플레이 영역에 걸쳐 있는 오버레이 창(overlay window)으로서 대화면 디스플레이를 지원하는 것이 더 간단할 수 있다. 직사각형(536)으로 나타낸 바와 같이, 1920 x 1080 창은 532 및 534 영역 둘다를 사용할 필요가 있다. 이것이 영역을 낭비하지만, 각각의 디스플레이에 대한 커스텀 사이즈(custom size)를 생성하는 것보다 구현하기가 더 간단할 수 있다. MU-GPU(412)의 선택적 직사각형 갱신 메카니즘으로 인해, 화면의 관련 영역만이 전송된다. DVPL이 선택적 갱신을 관리하기 위해 CRTC 제어 레지스터를 동적으로 제어하는 반면, 프로세서 개입을 덜 필요로 하고 향상된 시스템 효율을 필요로 하는 S-버퍼 등의 다른 더 유연한 메카니즘이 구현될 수 있다.

더 유연한 시스템은 또한 직사각형을 타일 등의 더 규칙적인 크기의 개체로 분해할 수 있다. 임의적인 직사각형 크기를 갖는 헤더 정보 대 덜 유연한 타일 크기를 사용하지만 더 많은 화면 데이터를 사용하는 아마도 더 간단한 헤더의 효율성에서 트레이드-오프가 있다. 양호한 일 실시예에서, 타일들은 블록 크기의 임의의 배수로 동적으로 설정될 수 있으며, 여기서 블록 크기는 데이터 인코딩 알고리즘의 가장 작은 개체이다. 블록들은 소스 이미지 또는 화면의 고정된 블록 위치에 맞춰 배향될 수 있다. 타일의 크기는 헤더 정보에 포함된다.

530 등의 메모리의 영역은 선택적 갱신을 관리하기 위한 S-버퍼(404)로 지정될 수 있다. 일 실시예에서, S-버퍼는 디스플레이 프레임(520, 522, 524, 526)의 타일에 대응하는 상태 비트를 포함하며, 여기서 상태 비트는 타일이 선택적 갱신을 필요로 하는지를 나타낸다. S-버퍼(440)는 또한 각각의 타일에 대한 서명을 저장할 수 있으며, 이 서명은 그 다음에 선택적 갱신의 필요성을 판정하는 데 사용된다. 다른 실시예에서, 선택적 갱신을 필요로 하는 프레임(520, 522, 524, 526)으 로부터의 타일들이 메모리 영역(530)으로 복사되고 선택적 갱신 출력을 위해 큐잉된다. 큐잉된 타일들은 여러가지 헤더, 상태 및 서명 정보를 포함할 수 있다.

도 6A는 1080P라고 하는 1920 x 1080의 HDTV(High Definition Television) 해상도를 갖는 도 5의 디스플레이 맵(536)을 더 상세히 나타낸 것이다. 도 6A에서, 고정된 크기 직사각형(614)은 화면 위치 경계에 배향되어 있다. 각각의 직사각형은 폭이 160 픽셀이고 높이가 120 픽셀이다. 행마다 12개의 직사각형(12 x 160 = 1920)이 있고 열마다 9개의 직사각형(9 x 120 = 1080)이 있다. 시스템은 이들 직사각형을 선택적 갱신을 위한 기초를 형성하는 타일로서 사용할 수 있다. 도 6B에서, 다른 시스템은 직사각형(614)을 80 x 40 픽셀을 포함하는 타일(620)로 더 분할하고, 시스템은 이들 더 작은 타일을 선택적 갱신을 위한 기초로서 선택할 수 있다. 보다 유연한 시스템은 6개의 타일(620)로 이루어진 더 큰 직사각형(614) 및 타일 자체 둘다를 이용할 수 있으며 헤더 정보를 사용하여 어느 유형이 임의의 주어진 시간에 출력되는지를 나타낸다.

양 경우에, 인코딩 알고리즘의 기초를 형성하는 블록들이 타일 또는 직사각형 내에 들어간다. 8 x 8 블록을 가정할 때, 각각의 타일은 10 x 5 블록 구성을 가지며, 각각의 직사각형은 20 x 15 블록 구성을 갖는다. 보다 큰 직사각형 및 보다 작은 삼각형 둘다를 이용하는 시스템은 선택적 갱신 요건을 결정함에 있어서 각각에 대해 서로 다른 메카니즘을 사용할 수 있다. 양호한 일 실시예에서, 큰 직사각형은 그 직사각형이 변경되었는지 여부를 나타내는 연관된 상태 비트를 가질 수 있으며, 보다 작은 타일은 이러한 결정을 하기 위해 서명을 이용할 수 있다. 상태 비트 및 서명은 이하에 기술되는 바와 같이 S-버퍼로 관리될 수 있다.

MU-GPU(412)는 타일의 선택적 인코딩을 직접 수행하기 위해 처리를 통합할 수 있거나, 각각의 타일이 선택적 갱신 프로세스를 사용하여 검사되고 TSA(424)로 출력될 수 있으며 적절한 헤더를 포함한다. 이 헤더는 TSA(424)에 의해 처리되고, 헤더 내의 필드들에 기초하여, TSA(424)는 타일이 어느 RT 및 디스플레이 화면의 어디로 보내지는 것인지를 알게 된다. 적절한 경우, TSA(424)는 타일을 압축된 형식으로 인코딩하고, 임의의 요구되는 헤더 정보를 조정하며, 추가의 네트워크 처리를 위해 타일 및 헤더를 제공한다.

MU-GPU(412) 및 TSA(424)는 선택적 갱신 프로세스를 다르게 분할할 수 있다. 몇몇 경우에, MU-GPU(412)는 전체적인 관리를 수행할 수 있고, 갱신을 필요로 하는 타일만을 TSA(424)로 전송한다. 다른 경우에, TSA(424)는 어느 슬라이스가 실제로 갱신을 필요로 하는지를 결정하기 위해 슬라이스의 추가적인 필터링을 수행할 필요가 있다. MU-GPU(412) 내에서, 선택적 갱신 메카니즘은 하드와이어되어 있을 수 있거나 CPU 개입을 필요로 할 수 있고, 이 하드웨어는 드로잉 엔진 및 선택적 갱신 리프레시 엔진 둘다에 걸쳐 구현될 수 있다. 타일의 인코딩은 또한 MU-GPU(412)에서 또는 TSA(424)에서 수행될 수 있다. MU-GPU(412)는 또한 디지털 비디오 버스를 통해 RT에 대한 그래픽 드로잉 명령을 TSA(424)에 출력할 수 있거나, 소프트웨어 드라이버가 TSA(424)에 직접 명령을 제공할 수 있다.

선택적 타일 갱신의 경우, 제1 실시예에서, S-버퍼가 사용되며, 이 경우 MU-GPU(412)는, 각각의 타일에 대한 선택적 디스플레이 갱신을 관리하기 때문에, 각각 의 타일에 대한 상태 비트를 관리하는 드로잉 엔진 및 상태 비트를 모니터링하는 선택적 갱신 리프레시 엔진을 갖는다. 3D 그래픽에서 사용되는 Z-버퍼와 같이, S-버퍼는 별도의 데이터 메모리 평면(memory plane of data)으로 구현될 수 있다. Z-버퍼에서와 같이, 향상된 MU-GPU(412)의 하드웨어 드로잉 동작은 부가의 명령 없이 S-버퍼 상태 비트를 갱신할 수 있다. 상태 비트는 이어서 타일들 중 어느 것이 RT에서 갱신될 필요가 있는지를 결정하기 위해 선택적 갱신 하드웨어에 의해 사용된다. 디스플레이 제어기의 리프레시 사이클과 같이, 선택적 갱신 하드웨어는 주기적으로 S-버퍼를 순회하고 상태 비트를 판독할 수 있다. 상태 비트의 상태에 기초하여, 선택적 갱신 하드웨어는 갱신될 필요가 없는 타일을 무시하거나, 선택적 갱신을 위한 타일을 판독하고 그 타일을 헤더 정보와 함께 출력하며 그에 따라 상태 비트를 갱신한다. 덜 효율적인 구현에서, MU-GPU(412)는 S-버퍼를 발생하기 위해 더 종래의 그래픽 드로잉 동작을 사용할 수 있다.

특정의 S-버퍼 하드웨어를 필요로 하지 않는 다른 양호한 실시예에서, MU-GPU(412)는 갱신을 필요로 하는 연접된 타일들의 선택적 갱신 버퍼를 관리할 수 있다. 선택적 갱신 버퍼는 별도의 메모리 영역에 구축될 수 있다. MU-GPU(412)가 타일을 변경하는 동작을 수행할 때마다, MU-GPU(412)는 그 타일을 선택적 갱신 버퍼로 복사한다. 헤더 정보는 각각의 타일의 첫부분에 저장될 수 있고, 타일들이 서로 패킹될 수 있다. 디스플레이 제어기는 선택적 갱신 버퍼를 사용하고 표준의 디스플레이 제어기 출력 동작을 사용하여 리프레시 포트를 통해 이 버퍼를 출력하도록 설정되어 있다. MU-GPU(412)는 하나 이상의 버퍼를 링 버퍼로서 또는 연접된 타일의 연결 버퍼 리스트(linked buffer list)로서 관리할 수 있고 TSA(424)가 타일 리스트로서 취급하는 연속적인 출력을 SDVO 출력을 통해 제공할 수 있다. MU-GPU(412)가 리스트에서의 배치 우선순위를 조정하기 위해 다양한 방식이 사용될 수 있다. 이 방법은 다수의 RT를 지원하는 특정의 하드웨어를 더 적게 가지며 특수한 선택적 갱신 하드웨어를 거의 또는 전혀 갖지 않는 MU-GPU(412)를 이용하는 데 가장 효율적일 수 있다.

다른 양호한 실시예에서, TSA(424)는 MU-GPU(412)와 함께 어느 타일이 RT(300)에서의 갱신을 필요로 할 수 있는지를 결정하는 동작한다. MU-GPU(412)가 타일마다 상태 비트를 관리하는 기능은 너무 어려울 수 있으며 타일들을 큰 타일로 또는 전체 가상 RT 디스플레이로 그룹화할 수 있고 상태 비트에 대해 제한된 입도를 가질 수 있을 뿐이다. 큰 타일을 보다 작은 타일 갱신으로 축소하는 것은 각각의 타일에 대한 추적 서명에 기초하여 수행될 수 있다. 이 서명은 통상적으로 타일이 처음으로 처리될 때 발생되고 차후의 서명과 대조하여 검사된다. 이 서명은 들어오는 데이터를 바탕으로 동작하는 TSA(424)에 의해 또는 MU-GPU(412)의 선택적 갱신 하드웨어와 관련하여 발생 및 처리될 수 있다. TSA(424)가 각각의 타일에 대한 서명 검사를 수행하는 경우, 각각의 RT(300)로의 네트워크 대역폭이 보존될 수 있다. MU-GPU(412)가 서명 검사를 수행하는 경우, 비디오 경로를 통한 TSA(424)로의 대역폭도 역시 보존된다. MU-GPU(412)는 타일에 대응하는 서명 메모리 평면(memory plane of signature)을 발생 및 관리할 수 있으며, 이 경우 상태 비트는 서명 평면 또는 별도의 평면의 일부일 수 있다. 다른 대안으로서, 상태 비트 및 서명 비트는 RAM 캐시에서 관리될 수 있고 MU-GPU(412)에 의해 연결 리스트로 관리될 수 있다.

호스트(400) 상에서의 그래픽 동작에 의해 발생된 그래픽 명령의 유형 및 RT(300)의 기능에 따라, 이 명령은 캡슐화되어 RT에서 실행하기 위해 전송될 수 있거나 이 명령은 MU-GPU(412)에 의해 로컬적으로 실행될 수 있다. 많은 경우에, 이 명령이 RT에서 실행하기 위해 전송되지만, 이 명령은 또한 가상 디스플레이의 로컬 복사본을 유지하기 위해 MU-GPU(412)에 의해 로컬적으로 실행된다. 이상적으로는, 불필요한 타일 갱신 패킷이 RT로 전송되는 것을 방지하기 위해, 중복적인 로컬 그래픽 명령의 결과로서 변경되는 모든 타일이 상태 비트로 필터링 제거된다. 인코딩된 타일 대신에 명령을 전송하는 것이 통상적으로 보다 적은 대역폭을 필요로 하지만, 이것이 항상 가능한 것은 아니다. 선택적 갱신 버퍼를 수동으로 관리하는 시스템은 또한 RT로 전송되는 명령들도 고려한다. RT에서 실행되는 명령에 의해 갱신되는 타일은 이상적으로는 MU-GPU(412)에 의해 선택적 갱신 버퍼에 배치되지 않는다.

변경이 RT의 디스플레이에 반영되기 전에, 프록시 서버 또는 단말기 서비스 가속기의 가상 디스플레이 메모리가 갱신될 수 있다. 이들이 동일한 디스플레이에 상관되어 있지만, MU-GPU(412) 및 TSA(424)에 의해 관리되는 타일 및 서브프레임의 위치는 사용자 인터페이스 동작과 무관하게 배치된다. 사용자 인터페이스 동작의 결과, 타일 내에서 또는 다수의 타일에 걸쳐 디스플레이 변동이 있을 수 있다. 사용자 인터페이스 변동은 사용자 동작, AJAX 에이전트, 브라우저 또는 프록시 서버 로부터 개시될 수 있으며, 그 결과 가상 디스플레이 메모리에 대한 갱신이 있을 수 있다. 가상 디스플레이 메모리의 타일 또는 갱신된 서브프레임에서의 갱신이 RT에 반영되고 MU-GPU(412) 및 TSA(424)에 의해 관리된다.

다른 예에서, RT로 보내지는 그래픽 명령은 TSA(424)에 의해 처리되고 인코딩된 데이터 전송 및 수정된 그래픽 명령으로 분해된다. 예를 들어, 호스트 시스템은 오프스크린 메모리(off screen memory)로부터 또는 온스크린 메모리(on-screen memory)에 대한 패턴으로부터 BitBlt 동작을 수행하고자 할 수 있다. 이것은 MU-GPU(412) 서브시스템에서 즉각 수행될 수 있다. 그렇지만, RT에서, BitBlt에 대해 요청된 소스 데이터가 캐싱되지 않는다. 따라서, 그래픽 명령을 전송할 수 있기 위해서는, 먼저 소스 데이터 또는 패턴을 인코딩하고 캡슐화하여 RT로 전송하고 이어서 수정된 그래픽 명령을 캡슐화하여 RT로 전송할 필요가 있을 수 있다. 이 절차는 TSA(424)에 의해 오프로드될 수 있다. DirectX 드라이버가 MU-GPU(412)를 통해 명령을 제공하고 이어서 MU-GPU(412)가 이 명령을 TSA(424)로 출력하는 것이 가능하지만, DirectX 드라이버가 이 명령을 TSA(424)로 직접 전달하는 것도 종종 더 효율적이다.

도 7은 MU-GPU(Multi-User GPU)(412)를 TSA(Terminal Services Accelerator)(424)와 결합하여 집적 회로(TSA-GPU-IC) SOC(System-On-Chip)(710)를 형성하는 양호한 실시예를 나타낸 것이다. 결합된 TSA-GPU-IC(710)는 서브시스템(700)의 일부로서 온칩 또는 외부 RAM(736)을 포함할 수 있다. TSA-GPU(700)는 유사하거나 서로 다를 수 있는 하나 이상의 시스템 버스 인터페이스(406, 408)를 포함할 수 있다. TSA-GPU(700)는 2D 엔진(720), 3D 그래픽 처리 유닛(GPU)(722), PCI 익스프레스와 같은 다양한 시스템 버스에 대한 시스템 버스 인터페이스(732) 및 비디오 또는 기타 로컬 I/O를 위한 인터페이스를 포함할 수 있는 로컬 I/O(410)에 대한 제어를 포함한다. 그에 부가하여, SOC(710)는 비디오 압축기(724) 및 비디오 압축 해제기(726) 하드웨어의 소정의 조합 또는 그 비디오 관련 기능과 기타 비디오 관련 기능을 겸비하고 있는 소정 형태의 프로그램가능 비디오 프로세서(764)를 포함할 수 있다. 부가의 프로세서(756)도 역시 포함될 수 있다.

선택적 갱신을 수행하는 디스플레이 제어기에서의 다중-사용자 선택적 갱신(SUC, Selective Update with display Controller)(750) 및 요구되는 서브프레임 또는 타일을 압축하는 데이터 인코더(752)도 포함되어 있다. SUC(750)는 로컬 디스플레이에 대한 출력(222, 758)을 포함할 수 있지만, 원격 다중-사용자는 시스템 인터페이스(732) 또는 아마도 네트워크 제어기에의 직접 접속(426)을 통해 지원된다. 시스템 버스(760)는 여러가지 처리 장치들은 물론 시스템 인터페이스(732) 및 메모리 인터페이스(734) 간의 접속을 나타낸다. 시스템 버스(760)는 여러가지 형태의 크로스바 스위칭, 중재 전송(crossbar switching, arbitrated transfer)을 포함할 수 있으며 또한 향상된 성능을 위한 한 유닛으로부터 다른 유닛으로의 직접 경로를 가질 수 있다.

도 4의 다중-칩 TSA-GPU(700)에서, MU-GPU(412)는 SDVO 경로(414, 416)를 거쳐 TSA(424)에 접속되고, MU-GPU 및 TSA 각각은 그 자신의 RAM을 갖는다. 이와 달리, 도 7에서, TSA-GPU-IC(710)는 SDVO 경로 대신에 공유 RAM(736)을 사용한다. RAM(736)을 사용하면 전송을 위해 SDVO 경로를 사용할 필요가 없게 되며, 따라서 SDVO 대역폭 문제가 없어진다. 그에 부가하여, 메모리를 공유함으로써, SUC(750)는 메모리로부터 프레임 정보를 직접 판독할 수 있으며, 그에 따라 MU-GPU(412)에 의한 메모리의 판독이 없어도 된다.

기능 유닛 각각에 S-버퍼를 직접 포함하는 것 등의 몇가지 부가의 최적화가 TSA-GPU(700)의 SOC(710)에 포함될 수 있다. 또한, 도 5에 나타낸 바와 같이 고정 크기의 디스플레이로 다중-사용자 프레임 지원을 구현하는 대신에, TSA-GPU(700)가 그의 대응하는 원격 단말기에서의 해상도 및 컬러 깊이까지 일치되는 다수의 디스플레이에 대한 지원을 매핑하도록 설계될 수 있다. 메모리에서의 디스플레이를 대응하는 원격 디스플레이 시스템과 보다 직접적으로 일치시키는 것은 메모리 사용에 대한 부가된 효율성을 달성할 수 있다.

변경되어 선택적 갱신 스트림의 발생을 필요로 하는 디스플레이 프레임에 대한 인코딩 선택을 돕기 위해, S-버퍼 지원이 하드웨어적으로 또는 추적 소프트웨어 계층과 관련하여 사용될 수 있다. S-버퍼 지원은 헤더, 상태 비트, 서명 또는 이들 셋의 조합을 이용할 수 있으며 고정 크기의 타일 또는 가변 크기의 타일에 기초할 수 있다. SUC(750)는 디스플레이의 어느 서브프레임이 선택적 갱신을 필요로 하는지를 결정하기 위해 S-버퍼 지원을 이용할 수 있다. 헤더 정보는 선택적 갱신의 다운스트림 처리에 유용할 수 있다.

서로 다른 시스템이 감소된 크기의 헤더를 위해 또는 감소된 횟수의 선택적 갱신 전송을 위해 최적화될 수 있다. 예를 들어, 양호한 실시예는 64 비트 헤더를 포함하는 타일 기반 선택적 갱신 시스템을 이용할 수 있다. 헤더의 16 비트는 64K개의 가능한 RT 중 어느 것이 선택적 갱신의 의도된 수신자인지를 지정하는 데 사용될 수 있다. 다른 2 비트는 제한된 수의 고정 크기의 타일 중 어느 것이 선택적 갱신에 포함되는지를 나타내는 데 사용될 수 있다. 비트들의 다른 세그먼트는 선택적 갱신이 대응하는 디스플레이 상의 장소를 나타내는 타일 번호를 지정한다. 선택적 갱신 인코딩된 데이터는 이어서 헤더 다음에 온다. 우선순위, 에러 검사 및 기타 추적 정보를 지정하는 부가의 비트도 역시 포함될 수 있다.

다른 양호한 실시예에서, SUC(750)는 타일을 사용하지 않을 수 있으며 선택적 갱신 패킷에 대한 더 많은 설명을 필요로 한다. 예를 들어, 타일 위치를 지정하기 위해 숫자를 제공하는 대신에, 시스템은 선택적 갱신 직사각형의 시작 위치를 지정하기 위해 X 및 Y 오프셋을 필요로 할 수 있다. 선택적 갱신 직사각형은 그러면 수평 및 수직 방향 둘다에 대한 픽셀 또는 블록의 수로 기술된다. 이러한 시스템에 대한 헤더 정보가 더 많을 수 있지만, 원격 단말기에 대한 갱신을 수행하기 위한 고유의 전송의 횟수가 더 적을 수 있다.

RT의 성능 및 호스트(100)와 RT 간의 네트워크 특성에 따라, TSB(400)는, 선택적 갱신을 전송하는 대신에, 소정의 그래픽 명령을 직접 RT로 전송하기로 할 수 있다. 이들 그래픽 명령은 TSB CPU 서브시스템(402)에 의해 또는 프로세서(756)에 의해 관리될 수 있다. 이들 프로세서는 또한 DirectX 및 RDP 명령에 대한 명령 해석을 수행하는 것을 비롯한 프록시 서버 또는 기타 단말기 서비스 기능을 관리할 수 있다. 해석기로서, 프로세서(756) 또는 CPU 서브시스템(402)은 2D 그래픽 명 령, 3D 그래픽 명령, 비디오 스트림 및 기타 윈도잉 기능을 관리하기 위해 호스트 시스템 상에서 실행 중인 소프트웨어 드라이버를 오프로드한다. 이 해석기 기능들은 RT를 관리하는 계산 집중적인 양태들 중 다수를 수행하기 위해 데이터 인코더(752)와 결합될 수 있으며, 또한 호스트 시스템으로부터 다양한 RT로 전송될 명령, 데이터 및 비디오 스트림을 최적화할 수 있다. 프록시 서버는 TSB(400)와 RT 사이에 분할되어 있을 수 있다.

예를 들어, 다양한 패턴 BitBlt, 소스-화면 목적지 BitBlt 및 기타 비트맵 전송이 향상될 수 있다. 소스 데이터, 소스 패턴 또는 소스 비트맵을 필요로 하는 그래픽 명령은 데이터 인코더(752)를 통해 소스를 보다 효율적인 형식으로 인코딩할 수 있다. 인코딩된 소스 데이터, 소스 패턴 또는 소스 비트맵이 수정된 그래픽 명령과 함께 RT(300)로 전송된다. 목적지 RT는 인코딩된 소스를 수신하고, 이를 디코딩한 다음에, 수정된 그래픽 명령을 수신할 시에, 의도된 동작을 수행한다. 인코딩된 데이터 및 수정된 명령의 전송은 RDP 전송에 의하거나 TSA-GPU(700) 및 RT(300)에 의해 지원되는 RDP 유사 전송에 의할 수 있다.

TSB(400)에서의 비디오 스트림의 경우, DirectX 해석기 소프트웨어는 비디오 스트림 처리를 가로채기하여 오프로드하고 목표 RT에 최적의 스트림을 제공할 수 있다. 오프로드에서의 첫번째 단계는 프로세서 블레이드(200)가 다중-CPU 컴플렉스(202)에서 비디오 디코딩을 수행하지 않도록 하는 것이다. 호스트 기반 디코딩은 몇가지 부정적인 측면이 있으며, 가장 중요한 2가지 중에서 첫번째로, 실제 디코딩을 수행하는 데 상당한 수의 CPU 사이클이 걸린다. 둘째로, 호스트에서 비디 오 프레임을 디코딩하는 것이 반드시 프레임을 목표 RT에 디스플레이되게 하는 최상의 방법일 필요는 없다는 것이다. 그 대신에, DirectX 해석기 소프트웨어는 여전히 압축된 형태로 있는 비디오 스트림에 액세스하기 위해 DirectX 호출을 가로채기한다(몇몇 버전의 Microsoft Windows

에서는 DirectShow의 사용을 수반할 수 있음). DirectX 해석기는 RDP가 정상 동작을 계속하기 위해 RDP 소프트웨어 인터페이스를 가짜 프레임(mock frame)으로 속일 필요가 있을 수 있다.

한편, TSB(400)는 RT가 어느 비디오 스트림 형식을 디코딩할 수 있는지, 호스트 시스템으로부터 RT로의 네트워크 처리용량이 공칭상 얼마인지, 및 비디오 스트림에 대해 어느 해상도 및 디스플레이 특성이 의도되어 있는지를 알고 있다. 이 정보를 사용하여, TSB(400)는 네트워크, RT 및 디스플레이 출력 요건에 이상적인 스트림을 생성하기 위해 들어오는 비디오 스트림을 처리하도록 TSA-GPU를 설정한다. 이것은 하나의 인코딩 형식에서 다른 인코딩 형식으로 트랜스코딩하는 것, 한 비트레이트에서 다른 비트레이트로 트랜스레이팅하는 것, 프레임 레이트를 변경하는 것, 디스플레이 형식을 변경하는 것, 해상도를 변경하는 것 또는 이들의 소정의 조합을 수반할 수 있다. TSB(400)는 이어서 처리된 비트스트림을 캡슐화하고 이를 네트워크 처리를 위해 적절한 접속으로 전송한다.

시스템(100) 상에서 실행 중인 프록시 서버 또는 RDP 서버 소프트웨어가 프로세서 블레이드(200)와 TSB(400) 간에 파티션되는 몇가지 방법이 있다. 여기에서 2가지 실시예에 대해 상세히 살펴본다. 첫번째는 "종료 및 재생성(terminate and regenerate)"이고 두번째는 "오프로드 및 향상(offload and enhance)"이다. 각각 의 실시예의 양태들을 이용할 수 있는 실시예의 여러 변형들도 가능하다.

"종료 및 재생성"의 경우에, RDP 클라이언트는 TSB(400) 상에서 실행된다. 프로세서 블레이드(200) 상에서 실행 중인 RDP 서버에 관한 한, RDP 동작은 TSB(400)에 의해 종료된다. 이 경우, TSB(400)는 단일의 큰 디스플레이 맵(이 맵 내에서 각각의 사용자는 오프셋되어 있거나 각각의 가상 디스플레이를 그 자신의 매핑을 갖는 별도의 디스플레이로 봄)을 생성함으로써 다수의 가상 RT를 지원하기 위해 TSA-GPU(700)를 이용하여 가상 디스플레이 공간을 생성한다. RDP 클라이언트 소프트웨어는 보안 클라이언트 통신을 필요로 하는 RDP 호스트에 대해 프로세서 블레이드(200)와 TSB(400) 간의 키 교환 및 보안 처리를 사용할 필요가 있을 수 있다. RDP 클라이언트가 RDP 호스트로부터 명령을 수신할 때, 클라이언트는, TSA-GPU(700)를 이용하여, 디스플레이 프레임을 디스플레이 서브시스템으로 렌더링한다. "종료 및 재생성"에 있어서, TSB(400)는 TSB(400)와 RT 간에 통신하기 위해 원하는 수단 및 프로토콜이 무엇이든지 간에 그를 사용할 수 있다.

"종료 및 재생성" 동작의 양호한 실시예에서, TSB(400)는 다수의 RDP 클라이언트로 구성되어 있고, 각각의 RDP 클라이언트는 RT에 대응한다. 프로세서 블레이드(200)는 "가상" RDP 클라이언트와 통신하기 위해 스위치 패브릭을 사용한다. 그러면, TSB(400)는 VNC(Virtual Network Computing)를 사용하여 RT에 대해 서버로서 동작한다. RT와 호스트(100) 간의 모든 통신이 TSB(400)에 의해 관리된다. RT로부터의 VNC 키보드 및 마우스 명령은 TSB(400)에 의해 프로세서 블레이드(200)에 대한 RDP 명령으로 변환된다. VNC를 사용하는 모든 유형의 클라이언트는 호스 트(100)와 효과적으로 통신을 할 수 있으며, 이 경우 메인 프로세서 블레이드(200)는 비-VNC 서버를 실행하고 있다. "종료 및 재생성" 동작의 제2 양호한 실시예에서, TSB(400)는 인터넷 서버로서 동작하고, 브라우저를 실행하는 RT와 통신을 한다. 서로 다른 플랫폼 상의 서로 다른 브라우저가 서로 다른 기능을 가질 수 있기 때문에, TSB(400)는 브라우저 기반 클라이언트와 통신하기 위해 서로 다른 HTTP, XML, 자바 및 기타 메타데이터 프로토콜을 지원할 수 있다.

웹 서비스의 경우, "종료 및 재생성" 기능은 TSB(400) 상에서 동작하는 프록시 서버에 의해 수행된다. 프로세서 블레이드(200)는 웹 서버를 실행할 수 있거나 다른 곳에 위치하는 웹 서버에의 접속을 관리할 수 있다. 다른 대안으로서, TSB(400)는 웹 서버와 직접 통신을 할 수 있다. 프록시 서버로서, TSB(400)는 모든 웹 동작을 종료할 수 있다. TSB(400)는 업스트림 웹 서버에 계속하여 요청을 하는 AJAX 에이전트 등의 에이전트를 포함할 수 있다. TSB(400)는 이어서 RT 클라이언트와 직접 통신을 한다. TSB(400)는 RT가 지원하는 어떤 프로토콜이라도 사용할 수 있고, RT 통신이 완전히 별개의 프로토콜이 되도록 할 수 있거나 유사한 웹 기반 프로토콜을 재사용하기로 할 수 있다.

서버 기반 컴퓨팅의 제2 실시예에서, "오프로드 및 향상"은 프로세서 블레이드(200)의 클라이언트 통신에의 참여를 더 많이 유지한다. 프로세서 블레이드(200)에서의 추적 소프트웨어 계층은 여전히 DirectX 비디오, 그래픽 및 데이터 스트림을 TSB(400)로 리디렉션하고, TSB(400)는 DirectX 호출의 기능을 완료한다. 기능을 오프로드하는 것은 다중-CPU 컴플렉스(202)를 다중-사용자 시스템의 다른 사용자들이 이용할 수 있게 해준다. 최적의 처리를 가능하게 해주는 디스플레이 환경 및 네트워킹 대역폭을 알고 있는 TSB(400)에 의해 추가의 처리가 완료될 수 있다.

TSB(400) 상의 해석기 소프트웨어는 또한 그래픽 명령이 로컬적으로 수행됨과 동시에 실행을 위해 RT로 전달될 때 TSA-GPU(700)에서 S-버퍼를 관리하는 데 사용될 수 있다. TSA-GPU(700)이 그래픽 명령을 로컬적으로 실행하는 이유는 프레임 버퍼의 현재의 복사본이 장래의 사용을 위해 관리될 수 있도록 하기 위함이다. 그래픽 명령이 RT에서 실행되고 있기 때문에, 로컬 그래픽 명령의 결과로서 호스트에서 변하는 타일은 선택적 갱신 하드웨어로 하여금 인코딩된 타일을 전송하게 할 필요가 없다. 이것을 방지하기 위해, RDP 추적 소프트웨어는 어느 타일이 그래픽 명령에 의해 영향을 받는지를 계산할 필요가 있다. 타일 기반 선택적 갱신이 수행되지 않도록, 이들 타일에 대응하는 S-버퍼 내의 상태 비트가 관리될 수 있다.

추적 및 해석기 소프트웨어는 또한 변경되어 디스플레이 갱신 스트림의 발생을 필요로 하는 디스플레이 프레임에 대한 인코딩 선택을 돕는 데 사용될 수 있다. 원격 디스플레이 시스템(300)이 디스플레이를 재생성하는 데 필요한 데이터를 감소시키기 위해 인코딩이 수행된다는 것을 상기하기 바란다. 추적 소프트웨어 계층은 가장 최적인 유형의 인코딩이 수행될 수 있도록 하기 위해 프레임 또는 타일 내의 데이터의 유형을 식별하는 것을 도울 수 있다. 몇몇 RT는 그래픽 명령을 실행하기에 충분한 그래픽 처리 능력을 갖지 있지 않을 수 있으며, TSA-GPU(700)에 의해 처리되는 인코딩된 데이터를 전송받을 수 있다.

예를 들어, 추적 소프트웨어 계층이 타일 표면(surface of tile)이 실시간 비디오인 것으로 식별하는 경우, 완만한 공간적 천이(spatial transition) 및 시간적 지역성(temporal locality)을 갖는 비디오에 더 효과적인 인코딩 방식이 그 타일에 사용될 수 있다. 추적 소프트웨어 계층이 타일 표면이 대체로 텍스트인 것으로 식별하는 경우, 예리한 에지 및 많은 텍스트 공백에 더 효과적인 인코딩 방식이 사용될 수 있다. 어느 유형의 데이터가 어느 영역에 있는지를 식별하는 것은 복잡한 문제이다. 그렇지만, 추적 소프트웨어 계층의 이 실시예는 이 식별을 돕는 호스트 디스플레이 시스템 및 호스트 운영 체제의 그래픽 드라이버 아키텍처에의 인터페이스를 가능하게 해준다. 예를 들어, Microsoft Windows

에서, 소정의 DirectShow 명령을 이용하는 표면은 비디오 데이터일 가능성이 있는 반면, 텍스트와 통상적으로 연관되어 있는 컬러 확장 비트 블록 전송(Bit Blit)을 사용하는 표면은 텍스트일 가능성이 있다. 각각의 운영 체제 및 그래픽 드라이버 아키텍처는 그 자신의 특성 표시자를 가지고 있다. 다른 구현들은 다수의 유형의 데이터 인코딩을 병렬로 수행할 수 있고 이어서 인코더 피드백에 기초하여 최상의 결과를 생성하는 인코딩 방식을 사용하기로 할 수 있다.

"오프로드 및 향상"의 이 제2 실시예는 또한 웹 기반 서비스를 위한 프록시 서버 아키텍처에서 이용될 수 있다. 이러한 실시예에서, TSB(400)는 웹 서버와 직접 통신을 할 수 있거나 RT와 웹 서버 간의 통신을 조정하는 분할 프록시로서 기능할 수 있다. TSB(400) 및 RT 상에서 실행 중인 에이전트는 여러가지 웹 서버에 계속하여 요청을 할 수 있다. TSB(400)는 디스플레이를 위해 RT에 의해 정말로 필요 하게 될 때까지 웹 서버 정보를 캐싱할 수 있다. 상기한 바와 같이, TSB(400)는 통신 채널을 RT에 더 적합하게 할 뿐만 아니라 RT 내에서 이용가능한 기능 및 성능을 더 잘 매칭시키기 위해 여러가지 그래픽 및 비디오 명령 및 데이터를 재코딩 또는 재형식화할 수 있다. 여러가지 컨텐츠 관리 및 컨텐츠 형식 동작이 프록시 또는 분할 프록시 서버로서 동작하는 TSB(400)에 의해 수행될 수 있다.

다양한 데이터 유형에 대해, 몇몇 유형의 인코딩 방식은 특정 유형의 데이터에 특별히 더 유용하며, 몇몇 인코딩 방식은 덜 데이터 의존적이다. 예를 들어, RLE는 텍스트에는 아주 좋지만, 비디오에는 아주 좋지 않으며, DCT 기반 방식은 비디오에는 아주 좋지만 텍스트에는 아주 좋지 않고, 웨이블렛 변환 기반 방식은 비디오 및 텍스트 둘다에 대해 좋을 수 있다. 이 시스템에서 모든 유형의 무손실 또는 손실 인코딩이 사용될 수 있지만, 역시 무손실 또는 손실 유형일 수 있는 웨이블렛 변환 인코딩, 상세하게는 주변의 타일을 고려하지 않고 각각의 타일을 인코딩할 수 있는 결정론적 산술 코더를 갖는 점진적 웨이블렛 변환(progressive wavelet transform)이 이 응용에 특히 아주 적합하다. 더 나은 실시간 실행을 위해 처리를 조정하는 JPEG2000 웨이블렛 인코더의 파생물이 한 가능한 구현이다.

도 8은 도 2로부터의 BMC(800)을 더 상세히 나타낸 도면이다. BMC(800)는 간단한 마이크로콘트롤러일 수 있는 또는 캐시를 갖는 더 강력한 CPU일 수 있는 CPU(808)를 포함한다. BMC(800)는 또한 보안 프로세서(804), 네트워크 프로세서 및 MAC 제어기 또는 "NIC"(Network Interface Control)(806), RAM(218), 인터페이스 제어기(810) 및 소정 형태의 TSA-GPU(700)를 포함한다.

CPU(808)는 "대역외(out of band)"(OOB)에서 동작할 수 있는 온보드 프로세서로서, 이는 메인 CPU로부터 동적 소프트웨어 또는 개입이 필요하지 않다는 것을 의미한다. 이상적인 BMC(800)는 부가의 케이블링을 필요로 하지 않으며 프로세서 블레이드(200)의 완전한 원격 관리를 가능하게 해준다. 몇몇 경우에, BMC(800)는 다수의 블레이드에 대한 관리를 수행하기 위해 중앙 집중식으로 될 수 있다. 여기에 도시된 BMC(800)는 키보드, 비디오 및 마우스(KVM) 기능에 대한 지원을 포함한다. 일부 시스템에서, CPU(808)는 메인 시스템 CPU 상에서 실행되는 가상 머신에 의해 추가적으로 향상될 수 있다. 완전히 OOB이지는 않지만, 가상 머신은 다른 시스템 기능을 방해하지 않도록 설계될 수 있다.

BMC(800)와의 통신은 보안을 위해 보안 프로세서(804)를 사용하여 암호화될 수 있으며, 로컬 네트워크 인터페이스(214)를 이용할 수 있거나 버스(206)을 통해 또한 적절한 도 2의 패브릭 접속(140 또는 142)을 거쳐 패킷을 전송할 수 있다. 네트워크 인터페이스는 NIC(806)로 도시된 바와 같이 부분적으로 포함될 수 있으며, 이 NIC(806)는 다른 곳에 위치한 MAC 부분 및 나머지 물리 인터페이스(PHY)를 포함한다. 인터페이스(814)는 외부 PHY(도시 생략)과 인터페이스할 때 MII(Media Independent Interface) 또는 RMII(Reduced MII) 등의 표준을 따를 수 있다. 외부 PHY는 전용 장치 또는 다른 네트워킹 서브시스템의 일부일 수 있다.

BMC(800)에 대한 디스플레이 양태는 간단한 것에부터 복잡한 것에 이르기까지 다양할 수 있으며, 하나 이상의 로컬 또는 원격 사용자를 지원할 수 있다. 간단한 시스템이 디스플레이를 인코딩하기 위해 기본적인 그래픽 제어기 및 소프트웨 어를 이용할 수 있는 반면, 양호한 실시예는 원격 사용자가 완전 성능 가상 존재(full performance virtual presence)를 갖도록 그래픽 가속화, 선택적 갱신 및 갱신의 인코딩의 복잡한 조합을 이용한다. 그 자체로서, BMC(800)는 디스플레이 지원을 위해 TSA-GPU(700)의 사용을 보여준다. 동시 사용자의 수에 따라, 이러한 유형의 BMC(800) 응용에 대한 TSA-GPU(700)의 성능은 TSB(400)에서만큼 높을 필요가 없을 수 있지만, 기능이 유사할 수 있다.

원격 액세스를 위한 상위 레벨 가상 존재 특징을 지원하는 것에 부가하여, 온보드 프로세서는 온도, 전압, 음향, 센서 및 LED를 관리하는 것 등의 다양한 플랫폼 자율을 위해 여러가지 센서와 인터페이스할 수 있다. 중간 레벨 원격 경보 모니터링도 역시 모니터링 및 관리된다. 외부 관리 시스템과 통신하기 위해, BMC(800)는 웹 서버를 포함할 수 있고 IPMI(Intelligent Platform Management Interface) 및 ASMI(Active Server Management Interface) 등의 원격 관리를 표준화하기 위해 다양한 업계 노력에 부합할 수 있다. 동시 다수 사용자 및 DVD 드라이브 등의 가상 I/O 장치에 대한 지원도 포함되어 있을 수 있다. 또한, BMC(800)에는 온보드 센서와, 경로(802)를 거쳐 온보드 센서와 통신하는 외부 인터페이스 칩(850)과, 또는 경로(214)를 거쳐 다른 로컬 I/O 제어기와 직접 인터페이스할 수 있는 인터페이스 제어(810)도 도시되어 있다. 도 8에 도시된 바와 같이 시스템 버스(206)를 이용하는 대신에, 인터페이스 제어(810)는 BMC(800)를 시스템 관리 버스 등의 다른 버스와 인터페이스시킬 수 있다.

도 9는 본 발명의 일 실시예에 따른 단말기 서비스 가속화 및 프록시 서버 절차를 수행하는 방법 단계들의 흐름도이다. 명확함을 위해, 이 절차는 비디오를 비롯한 디스플레이 데이터를 참조하여 기술된다. 그렇지만, 오디오, 키보드, 마우스 및 기타 데이터에 관련된 절차도 본 발명과 관련하여 사용하기 위해 동일하게 생각된다. 먼저, 단계(910)에서, 다중 사용자 컴퓨터(100) 및 원격 단말기 시스템(300)은 다양한 서브시스템이 각각의 RT를 인에이블시키기 위해 호스트측 및 단말기측을 초기화 및 설정하는 데 다양한 절차를 따른다. 단계(912)에서, 애플리케이션은 디스플레이 명령, 디스플레이 데이터 갱신 또는 비디오 데이터 스트림의 형태로 갱신된 디스플레이 데이터를 제공한다. 애플리케이션 갱신은 애플리케이션 자체, 클라이언트에서의 사용자 동작 또는 애플리케이션, 프록시 서버 또는 클라이언트에서의 소정의 다른 에이전트로부터 개시될 수 있다. 애플리케이션 요청은 호스트 CPU 상에서 실행 중인 추적 소프트웨어 계층에 의해 가로채기될 수 있거나, 명령이 TSB(400) 상에서 실행 중인 프록시 서버 또는 단말기 서비스 가속기에 의해 가로채기될 수 있다. BMC(800)에 대해, 단계(912)에서, 추적 소프트웨어 계층이 포함되어 있지 않고, BMC(800)는 호스트 CPU와 무관하게 동작한다.

그래픽 동작이 2D 드로잉을 포함하는 경우, 단계(924)에서, 2D 드로잉 엔진 MU-GPU(412)는 양호하게는 RAM(430)에서의 적절한 가상 디스플레이에 대한 동작을 처리한다. 이와 유사하게, 단계(926)에서, MU-GPU(412)에 의해 RAM에서의 적절한 가상 디스플레이에 대해 3D 드로잉이 수행된다. 단계(928)에서, TSB(400)는 비디오 또는 그래픽 명령이 적절한 RT로 전달되는지를 판정할 수 있다. 단계(940)까지의 흐름은 바이패스 단계(928)에 의해 영향받지 않을 수 있다. 단계(940)에서, MU-GPU(412)는 각각의 가상 디스플레이를 디스플레이에 적합한 프레임으로 합성한다. 이 합성은 CPU 서브시스템(202), 2D 엔진, 3D 엔진 및 GPU(412) 내의 임의의 비디오 처리 요소에 의한 동작들의 임의의 조합으로 수행될 수 있다. 합성 단계의 일부로서, 그래픽 처리 하드웨어에 S-버퍼 관리를 포함하는 MU-GPU(412)의 경우, 드로잉 엔진은 각각의 타일에 대한 S-버퍼를 갱신한다.

복귀 경로(944)로 나타낸 바와 같이, TSB(400)는 필요에 따라 동일한 RT 또는 다른 RT에 대한 그 다음 프레임을 처리할 수 있다. 양호한 일 실시예에서, TSB(400)는, 애플리케이션 서버에 관한 한, 클라이언트가 드로잉 동작을 완전히 완료하도록 전체 클라이언트 스택을 실행할 수 있다. 이와 유사하게, TSB(400)는 웹 서버와 관련하여 웹 클라이언트 동작을 완료하기 위해 프록시 서버 또는 분할 프록시 서버로서 동작할 수 있다. TSB(400)는 다수의 사용자를 에뮬레이트하기 위해 클라이언트 프로토콜을 실행할 수 있다. TSB(400)가 서버에게 클라이언트측 동작이 완료되었음을 전달하면, TSB(400)는 이제 의도된 명령 또는 디스플레이 데이터를 목표 RT로 중계하기 위해 어떤 메카니즘이라도 사용할 수 있다. 앞서 기술한 바와 같이, TSB(400)는 디스플레이 갱신을 RT에 반영하기 위해 기존의 명령을 재전송하거나, 수정된 명령을 재형식화하거나 다른 메카니즘을 사용할 수 있다.

명령의 가로채기의 일부로서, TSB(400)는 로컬 가상 디스플레이 메모리에서 의도된 RT 디스플레이 화면을 완전히 합성할 수 있다. 합성 동작이 수행되면, 단계(946)는, 적절한 경우, 타일과, 연관된 S-버퍼 상태 비트 및 서명 비트를 관리한다. 단계(946)는 S-버퍼 상태 비트에 영향을 줄 수 있는 비디오 및 그래픽 바이패 스 단계(928)를 통해 처리된 모든 그래픽 및 비디오 동작을 고려한다. 예를 들어, 드로잉 동작이 단계(924)에서 수행됨과 동시에 단계(928)를 통해 원격 단말기로 바이패스된 경우, 그 드로잉 동작이 RT에서 행해질 때 그 동작에 의해 영향을 받는 타일들에 대해 선택적 갱신을 수행할 필요가 없다.

타일에 대한 상태 비트 및 서명이 MU-GPU(412) 내에서 또는 TSA(424)와 관련하여 행해질 수 있는 단계(946)에서 처리된 경우, 단계(950)는 타일의 선택적 갱신을 수행할 수 있다. 타일은 고정 크기 또는 가변 크기를 가질 수 있다. 타일에 포함된 헤더 정보는 형식은 물론 의도된 RT 목적지를 나타낸다. 단계(954)에서, TSA(424)는 단계(950)로부터 수신된 타일의 필요한 인코딩을 수행한다. 이 인코딩은 양호하게는 결정론적 방식이며, 이 경우 타일 및 주변 타일 내에서의 데이터의 배향이 인코딩 단계에서 고려될 필요가 없다. 또한, 단계(954)에서, 단계(928)에 뒤따르는 비디오 데이터 및 그래픽 명령이 처리된다. 비디오 데이터가 트랜스레이트될 수 있으며, 여기서 비트 레이트 또는 프레임 레이트가 변경되고, 주파수 또는 공간 영역에서 스케일링되며 필요한 경우 다른 인코딩 표준으로 트랜스코딩된다. 복귀 경로(968)을 통한 네트워크 피드백은, RT 정보와 함께, 둘다 인코딩 단계(954)를 결정하는 데 도움을 줄 수 있다.

단계(954)는 또한 그래픽 데이터의 인코딩을 수반할 수 있는 부가의 처리를 필요로 하는 그래픽 동작을 수행한다. 단계(958)에서, TSA(424) 또는 CPU(402)는 이전의 단계에서 처리된 그래픽 명령, 데이터 전송 또는 비디오 전송의 추가의 캡슐화를 수행한다. 네트워크 피드백은 또한 대역폭 및 지연시간과 특정의 패킷 크 기 및 전송 문제 등의 네트워크 특성과 관련하여 이 단계에서 고려된다. 단계(962)에서, 캡슐화된 패킷이 적절한 네트워크 제어기를 통해 처리되고, 이 패킷은 네트워크를 따라 적절한 RT(300)로 전송된다.

네트워크 프로세스 단계(962)는 시스템 제어로부터의 정보를 사용한다. 이 정보는 어느 원격 디스플레이가 어느 프레임 갱신 스트림을 필요로 하는지, 어느 유형의 네트워크 전송 프로토콜이 각각의 프레임 갱신 스트림에 대해 사용되는지, 및 각각의 프레임 갱신 스트림의 각각의 부분에 대해 우선순위 및 재시도 특성이 무엇인지에 관한 정보를 포함할 수 있다. 네트워크 프로세스 단계(962)는 로컬 I/O(428) 및 로컬 네트워크 접속(490)을 이용하여 TSA에 로컬적으로 관리될 수 있다. 다른 대안으로서, 블레이드 기반 시스템에서, 네트워크 준비 패킷은 네트워크 접속을 포함하는 프로세서 블레이드(200)에 의해 또는 다른 프로세서 블레이드에 위치하는 네트워크 프로세서에 의해 처리하기 위해 시스템 패브릭 버스(140 또는 142) 중 하나를 통해 전송될 수 있다. 다양한 네트워크로는 기가비트 이더넷, 10/1000 이더넷, 전력선 이더넷, 동축 케이블 기반 이더넷, 전화선 기반 이더넷, 또는 802.11a, b, g, n, s 및 장래의 파생물 등의 무선 이더넷 표준이 있을 수 있다. 다른 비이더넷 접속(non-Ethernet connection)도 가능하며, USB, 1394a, 1394b, 1394c 또는 UWB(Ultra Wide Band) 또는 WiMAX 등의 기타 무선 프로토콜을 포함할 수 있다.

도 10은 본 발명의 일 실시예에 따른 네트워크 수신 및 디스플레이 절차를 수행하는 방법에서의 단계들의 흐름도이다. 명확함을 위해, 이 절차는 비디오를 포함한 디스플레이 데이터를 참조하여 기술된다. 그렇지만, 오디오 및 기타 데이터에 관한 절차도 본 발명과 관련하여 사용하기 위해 똑같이 생각된다. RT(300)는 기능 동작들을 수행하기 위해 간단한 제어 프로그램을 실행하도록 구성될 수 있거나, 드라이버 또는 애플리케이션을 실행하는 운영 체제 기반 프로세서 시스템일 수 있거나, JAVA 처리 또는 진보된 AJAX 처리를 포함한 더 많은 에이전트를 포함하거나 포함하지 않을 수 있는 몇몇 유형의 클라이언트에서 실행 중인 브라우저일 수 있다. 그에 부가하여, RT(300)는 디스플레이 갱신을 가져오는 사용자 동작 또는 에이전트 동작에 기초하여 요청을 개시할 수 있다.

도 10의 실시예에서, 먼저, 단계(1012)에서, 원격 단말기(300)는 양호하게는 경로(390)를 통해 호스트 컴퓨터(200)로부터 네트워크 전송을 수신한다. 그 다음에, 단계(1014)에서, 네트워크 제어기336)는 양호하게는 전송이 유선이든 무선이든지 간에 전송된 데이터를 수신하기 위해 네트워크 프로토콜을 실행하는 네트워크 처리 절차를 수행한다.

단계(1020)에서, CPU(324)는 전송이 어느 기능 유닛으로 보내지는 것인지를 결정하기 위해 들어오는 전송을 해석한다. 들어오는 전송이 2D 그래픽 명령인 경우, CPU(324)는 2D 드로잉 엔진(332)을 통해 동작을 초기화하고, 3D 명령인 경우, 3D 드로잉 엔진(334)을 통해 동작을 초기화하며, 비디오 데이터 스트림인 경우, 비디오 디코더(328)를 통해 동작을 초기화하고, 인코딩된 데이터 타일인 경우, 데이터 디코더(326)를 통해 동작을 초기화한다. 일부 드로잉 명령은 드로잉 엔진 및 데이터 디코더(326) 둘다를 사용할 수 있다. 몇몇 경우에, 들어오는 전송 데이터 는 필요할 때 사용하기 위해 저장될 수 있다. 다양한 형태의 AJAX 및 에이전트 처리가 궁극적으로 필요할 수 있거나 필요하지 않을 수 있는 데이터에 대한 투기적 요청을 할 수 있다.

다양한 횟수의 명령 및 데이터 전송이 행해질 수 있으며, 다양한 기능 유닛이 동작하고 양호하게는 데이터 정보를 적절한 디스플레이가능 형식으로 조작한다. 단계(1030)에서, 각각의 기능 유닛으로부터의 조작된 데이터는 프레임 관리자(330)를 통해 조립되고, 갱신된 디스플레이 프레임을 생성하여 RAM(312)에 넣을 수 있다. 갱신된 디스플레이 프레임은 이전 프레임으로부터의 디스플레이 프레임 데이터, 조작되고 디코딩된 새로운 프레임 데이터, 및 새로운 프레임 데이터의 전송 동안에 일어난 디스플레이 데이터 에러를 감추기 위해 필요한 임의의 처리를 포함할 수 있다.

마지막으로, 단계(1040)에서, 디스플레이 제어기(330)는 원격 단말기 시스템(300)의 사용자가 보도록 가장 최근에 완료된 디스플레이 프레임 데이터를 원격 단말기 디스플레이 화면(310)에 제공한다. 디스플레이 리프레시는 플리커를 피하기 위해 원격 단말기 제어기(314)와 디스플레이(310) 사이에서 통상적으로 초당 60회 내지 72회로 동작하는 비동기 동작이다. 단계(1030)에서 새로운 디스플레이 프레임을 생성하는 것은 통상적으로 상당히 더 적은 횟수로 일어나지만, 필요할 때에 초당 30 프레임 이상으로 행해질 수 있다. 화면 보호기 또는 절전 모드가 없는 경우, 디스플레이 프로세서는 디스플레이 리프레시 도중에 피드백 경로(1050)로 나타낸 바와 같이 가장 최근에 완료된 디스플레이 프레임으로 계속하여 원격 디스플레 이 화면(310)을 갱신한다.

본 발명은 따라서 사용자가 광범위한 응용에서 효과적으로 이용할 수 있는 원격 단말기를 지원하는 다중-사용자 서버 기반 컴퓨터 시스템을 구현한다. 예를 들어, 기업은 컴퓨터 시스템의 랙을 한 장소에 설치하고 원격 장소에 있는 사용자에게 그의 데스크톱에서 아주 간단하고 저렴한 원격 단말기 시스템(300)을 제공할 수 있다. 서로 다른 원격 장소가 LAN, WAN을 통해 또는 다른 접속을 통해 지원될 수 있다. RT는 데스크톱 퍼스널 컴퓨터 또는 노트북 퍼스널 컴퓨터일 수 있으며, 다른 시스템에서 셀 전화, PDA 등의 특수 장치일 수 있거나, 휴대용 비디오 플레이어, 게임기 또는 원격 제어 시스템 등의 다른 가전 제품과 결합될 수 있다. 사용자는 호스트 시스템이 로컬 사용자에게 제공할 수 있는 동일한 레벨의 소프트웨어 호환성 및 유사한 레벨의 성능을 달성하기 위해 다중-사용자 시스템(100)의 호스트 컴퓨터를 유연성있게 이용할 수 있다. 따라서, 본 발명은 최적의 시스템 상호 운용성 및 기능성을 용이하게 해주기 위해 다양한 이기종 컴포넌트들을 이용하는 유연한 다중-사용자 시스템을 효과적으로 구현한다.

본 발명이 양호한 실시예를 참조하여 이상에 설명되어 있다. 이 개시 내용을 고려하면 당업자에게는 다른 실시예들에 명백할 것이다. 예를 들어, 본 발명은 상기한 양호한 실시예에 기술된 것과 다른 구성을 사용하여 용이하게 구현될 수 있다. 그에 부가하여, 본 발명은 양호한 실시예로서 상기한 것과 다른 시스템과 관련하여 효과적으로 사용될 수 있다. 따라서, 양호한 실시예에 대한 이들 및 다른 변형이 본 발명에 포함되는 것으로 보아야 하며, 이는 첨부된 청구범위에 의해서만 제한된다.

Claims (20)

1. 다수의 원격 단말기를 지원할 수 있는 디스플레이 프록시 서버 시스템으로서,

   다수의 단말기에 대한 디스플레이 프레임들을 저장할 수 있는 디스플레이 메모리,

   각각이 원격 단말기에서의 디스플레이 프레임에 대응할 수 있는 디스플레이 프레임들을 발생하는 하나 이상의 드로잉(drawing) 엔진, 및

   디스플레이 프레임들의 수정된 서브 프레임들을 추적하고 이 추적에 기초하여 상기 디스플레이 메모리로부터 선택적 갱신을 수행하는 수단

   을 갖는 그래픽 및 디스플레이 서브시스템,

   상기 디스플레이 프록시 서버 시스템을 하나 이상의 호스트 CPU에 접속시키는 수단, 및

   상기 선택적 갱신만이 네트워크 서브시스템을 거쳐 상기 원격 단말기들 중 대응하는 단말기로 전송되도록 상기 디스플레이 메모리로부터의 선택적 갱신을 관리하는 수단

   을 포함하는 디스플레이 프록시 서버 시스템.
2. 제1항에 있어서,

   상기 원격 단말기들은 인터넷 브라우저를 실행하고 상기 디스플레이 프록시 서버 시스템을 통해 웹 갱신을 요청하며, 상기 디스플레이 프록시 서버 시스템은 웹 서버에 상기 웹 갱신을 요청하고 그로부터 상기 웹 갱신을 수신하며 상기 웹 갱신을 인코딩된 부분 프레임 갱신으로 변환하고 상기 인코딩된 부분 프레임 갱신을 상기 인터넷 브라우저에 제공하는 프록시 기능을 수행하는 디스플레이 프록시 서버 시스템.
3. 제1항에 있어서,

   상기 원격 단말기들은 인터넷 브라우저를 실행하고 상기 디스플레이 프록시 서버 시스템에 컨텐츠 기반 프레임 요청을 수행하며, 상기 디스플레이 프록시 서버 시스템은 상기 디스플레이 프록시 서버 시스템에 이미 캐싱된 데이터를 사용하여 프레임의 어느 부분이 변경되었는지에 기초하여 부분 프레임 갱신을 합성, 인코딩 및 공급하는 디스플레이 프록시 서버 시스템.
4. 제1항에 있어서,

   상기 디스플레이 프록시 서버 시스템은 블레이드(blade) 시스템으로 구현되고, 하나 이상의 호스트 CPU에 접속시키는 상기 수단은 시스템 백플레인을 통해 제공되는 디스플레이 프록시 서버 시스템.
5. 제1항에 있어서,

   상기 디스플레이 프록시 서버 시스템은 가전 제품으로서 구현되고, 네트워크 접속 및 디스플레이 출력 경로 둘다에 의해 서버 시스템에 연결되는 디스플레이 프록시 서버 시스템.
6. 제1항에 있어서,

   상기 디스플레이 프록시 서버 시스템은,

   애플리케이션을 실행 중인 호스트 CPU와 통신하고,

   마치 클라이언트인 것처럼 상기 애플리케이션에 응답을 하며,

   그 다음에 상기 원격 단말기에 선택적 디스플레이 갱신을 수행하는 디스플레이 프록시 서버 시스템.
7. 제1항에 있어서,

   상기 디스플레이 프록시 서버 시스템은 웹 액세스를 수행할 때 상기 다수의 원격 단말기에 DNS 탐색(lookup) 기능을 제공하는 디스플레이 프록시 서버 시스템.
8. 제1항에 있어서,

   상기 디스플레이 프록시 서버 시스템은, 마치 해당 가상 머신에 전용된 그래픽 제어기가 있는 것처럼 각각이 그래픽 동작을 요청하는 하나 이상의 가상 머신을 실행 중인 하나 이상의 호스트 CPU와 통신하고, 상기 디스플레이 프록시 서버 시스템은 상기 다수의 가상 머신 그래픽 요청을 로컬적으로 관리하는 디스플레이 프록시 서버 시스템.
9. 제8항에 있어서,

   상기 디스플레이 프록시 서버는 상기 로컬적으로 관리되는 가상 머신 그래픽 요청을 이용하여 상기 요청하는 가상 머신들에 대한 가상 디스플레이를 생성하고 그 후 상기 가상 디스플레이의 인코딩된 갱신을 네트워크를 통해 상기 원격 단말기들 중 대응하는 원격 단말기로 전송하는 디스플레이 프록시 서버 시스템.
10. 하나 이상의 원격 단말기를 지원할 수 있는 베이스보드 관리 제어 시스템(baseboard management control system)으로서,

    그래픽 제어기 및 디스플레이 서브시스템

    을 포함하며,

    상기 그래픽 제어기 및 디스플레이 서브시스템은,

    호스트 CPU의 요청으로 디스플레이 메모리에서 그래픽 프로세서 동작을 수행하여 디스플레이 프레임 데이터를 발생하는 수단,

    디스플레이 프레임들의 수정된 서브 프레임들을 추적하고 이 추적에 기초하여 선택적 갱신을 수행하는 수단,

    상기 선택적 갱신을 인코딩하는 수단, 및

    상기 선택적 갱신만이 네트워크 서브시스템을 거쳐 상기 원격 단말기들 중 대응하는 원격 단말기로 전송되도록 상기 디스플레이 메모리로부터의 선택적 갱신을 관리하는 수단

    을 갖는 베이스보드 관리 제어 시스템.
11. 제10항에 있어서,

    상기 선택적 갱신은 고정된 타일 크기의 서브프레임들에 기초하는 베이스보드 관리 제어 시스템.
12. 제10항에 있어서,

    상기 디스플레이 관리 시스템은 S-버퍼를 사용하여 선택적 갱신을 관리하는 베이스보드 관리 제어 시스템.
13. 제10항에 있어서,

    상기 시스템은 상기 그래픽 처리 동작의 운영 체제 기능들을 수행하기 위해 운영 체제 가상 머신 모드에서 상기 호스트 CPU와 통신하는 베이스보드 관리 제어 시스템.
14. 제13항에 있어서,

    상기 시스템은 상기 운영 체제 가상 머신 모드와 분리되어 있는 보호 관리 가상 머신 모드에서 실행 중인 상기 호스트 CPU와 통신하고, 상기 관리 가상 머신 모드는 상기 원격 단말기들에 대한 상기 갱신 기능들 중 일부를 관리하는 베이스보드 관리 제어 시스템.
15. 다수의 원격 단말기를 지원할 수 있는 블레이드 기반 다중-사용자 시스템으로서,

    백플레인에 접속된 하나 이상의 프로세서 블레이드,

    다수의 단말기에 대한 디스플레이 프레임들을 저장할 수 있는 디스플레이 메모리,

    각각이 원격 단말기에서의 디스플레이 프레임에 대응할 수 있는 디스플레이 프레임들을 발생하는 하나 이상의 드로잉 엔진, 및

    디스플레이 프레임들의 수정된 서브 프레임들을 추적하고 이 추적에 기초하여 상기 디스플레이 메모리로부터 선택적 갱신을 수행하는 수단

    을 갖는 그래픽 및 디스플레이 서브시스템을 포함하는 하나 이상의 단말기 서비스 가속기 블레이드,

    상기 프로세서 블레이드들을 하나 이상의 단말기 서비스 가속기 블레이드에 접속시키는 수단, 및

    상기 선택적 갱신만이 네트워크 서브시스템을 거쳐 상기 원격 단말기들 중 대응하는 단말기로 전송되도록 상기 디스플레이 메모리로부터의 선택적 갱신을 관리하는 수단

    을 포함하는 블레이드 기반 다중-사용자 시스템.
16. 제15항에 있어서,

    상기 하나 이상의 단말기 서비스 가속기 블레이드는,

    애플리케이션 소프트웨어를 실행 중이고 상기 그래픽 및 디스플레이 서브시스템을 가상화하는 다중-사용자 원격 클라이언트 프로토콜을 이용하는 호스트 CPU와 통신하고,

    상기 원격 사용자 클라이언트로서 가상 그래픽 기능을 수행하며,

    그 후 상기 원격 단말기에 가상 디스플레이 서브시스템으로부터의 선택적 디스플레이 갱신을 수행하는 블레이드 기반 다중-사용자 시스템.
17. 제15항에 있어서,

    상기 단말기 서비스 블레이드는, 마치 상기 단말기 서비스 블레이드가 각각의 가상 머신에 전용된 각자의 그래픽 제어기를 포함하는 것처럼 각각이 그래픽 동작을 요청하는 하나 이상의 가상 머신을 실행 중인 하나 이상의 CPU와 통신하는 블레이드 기반 다중-사용자 시스템.
18. 제15항에 있어서,

    상기 단말기 서비스 블레이드는 다수의 독립적인 가상 머신 모드 CPU로부터의 가상 머신 그래픽 요청을 로컬적으로 관리하여 가상 머신들에 대한 가상 디스플레이를 생성하기 위해 상기 그래픽 및 디스플레이 서브시스템을 이용하고, 그 후 상기 가상 디스플레이의 인코딩된 갱신을 네트워크를 거쳐 원격 단말기들로 전송하며, 상기 다수의 독립적인 가상 머신 모드 CPU는 서로를 알지 못하는 블레이드 기 반 다중-사용자 시스템.
19. 제15항에 있어서,

    상기 프로세서 블레이드들은 웹 서버로서 동작하는 블레이드 기반 다중-사용자 시스템.
20. 제15항에 있어서,

    상기 블레이드 기반 다중-사용자 시스템은 다수의 웹 서버에 액세스하는 다수의 원격 단말기에 대한 인터넷 서비스 관리 기능을 제공하는 블레이드 기반 다중-사용자 시스템.

Images