KR101898565B1 - 전송을 위한 서버 시스템의 그래픽 데이터 프로세싱 - Google Patents

전송을 위한 서버 시스템의 그래픽 데이터 프로세싱 Download PDF

Info

Publication number
KR101898565B1
KR101898565B1 KR1020147001108A KR20147001108A KR101898565B1 KR 101898565 B1 KR101898565 B1 KR 101898565B1 KR 1020147001108 A KR1020147001108 A KR 1020147001108A KR 20147001108 A KR20147001108 A KR 20147001108A KR 101898565 B1 KR101898565 B1 KR 101898565B1
Authority
KR
South Korea
Prior art keywords
data
graphics
server system
buffer
processor
Prior art date
Application number
KR1020147001108A
Other languages
English (en)
Other versions
KR20140079350A (ko
Inventor
사챠키 코네루
케 인
디나카르 무나갈라
Original Assignee
신씨 아이엔씨.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 신씨 아이엔씨. filed Critical 신씨 아이엔씨.
Publication of KR20140079350A publication Critical patent/KR20140079350A/ko
Application granted granted Critical
Publication of KR101898565B1 publication Critical patent/KR101898565B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/60—Memory management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/00—3D [Three Dimensional] image rendering
    • G06T15/005—General purpose rendering architectures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/14—Digital output to display device ; Cooperation and interconnection of the display device with other functional units
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/20—Processor architectures; Processor configuration, e.g. pipelining
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/12—Selection from among a plurality of transforms or standards, e.g. selection between discrete cosine transform [DCT] and sub-band transform or selection between H.263 and H.264
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/146—Data rate or code amount at the encoder output
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/156—Availability of hardware or computational resources, e.g. encoding based on power-saving criteria
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/172—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a picture, frame or field
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/46—Embedding additional information in the video signal during the compression process
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614—Multiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/426—Internal components of the client ; Characteristics thereof
    • H04N21/42653—Internal components of the client ; Characteristics thereof for processing graphics
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4348—Demultiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8146—Monomedia components thereof involving graphical data, e.g. 3D object, 2D graphics
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer

Abstract

전송을 위해서 서버의 그래픽 데이터를 선택하는 방법, 시스템 및 장치가 개시된다. 한 방법은 상기 서버 시스템의 그래픽 메모리로부터 데이터를 읽는 단계를 포함한다. 상기 그래픽 메모리로부터 읽혀진 상기 데이터는, 그 데이터가 처음으로 읽혀지고 있는 것이며, 그리고 상기 서버 시스템의 프로세서에 의해서 써지지 않았다면, 전송 버퍼 내에 놓여진다. 한 시스템은 그래픽 메모리, 프레임 버퍼 및 프로세서를 포함하는 서버 시스템을 포함한다. 상기 서버 시스템은 상기 그래픽 메모리로부터 데이터를 읽도록 동작할 수 있다. 상기 서버 시스템은, 상기 데이터가 처음으로 읽혀지고 있는 것이며, 그리고 렌더링 동안에 상기 프로세서에 의해서 써지지 않았다면, 상기 데이터를 상기 전송 버퍼 내에 놓아두도록 동작 가능하다.

Description

전송을 위한 서버 시스템의 그래픽 데이터 프로세싱{Processing of graphics data of a server system for transmission}
관련된 출원
본 특허 출원은 2010년 6월 17일에 출원된 미국 임시 특허 출원 일련번호 61/355,768에 대한 우선권을 주장한다.
기술 분야
설명된 실시예들은 일반적으로 그래픽 데이터를 전송하는 것에 관련된다. 더 상세하게는, 상기 설명된 실시예들은 클라이언트 시스템으로의 전송을 위한 서버 시스템 상에서의 그래픽 데이터 프로세싱 그리고 클라이언트 시스템 상에서의 프로세싱을 위한 방법, 장치 및 시스템에 관한 것이다.
클라우드 컴퓨팅이 시작된 것은 분산 컴퓨팅으로부터 집중식 컴퓨팅 (centralized computing)으로의 파라다임 이동을 초래하고 있다. 집중식 컴퓨터는 "집중화 (centralized)"되는 시스템의 대부분의 리소스들을 포함한다. 이 리소스들은 중앙 프로세싱 유닛 (central processing unit (CPU)), 메모리, 저장부 및 네트워킹을 위한 지원부를 포함하는 집중식 서버를 포함하는 것이 보통이다. 애플리케이션들은 집중식 서버 상에서 실행되며 그리고 그 결과들은 하나 또는 그 이상의 클라이언트들에게 전달된다.
집중식 컴퓨팅 작업들은 많은 애플리케이션들에서 잘 동작하지만, 소비자들에게는 점점 더 인기가 있는 그래픽이 풍부한 애플리케이션들을 실행시키는데 있어서는 기대에 미치지 못한다. 씬-클라이언트 (thin-client) 애플리케이션들을 위한 그래픽을 원격으로 프로세싱하기 위해서 독점의 기술들이 현재 사용된다. 독점적인 기술들은 마이크로 소프트 RDP (Remote Desktop Protocol), 인터넷 프로토콜을 통한 개인용 컴퓨터 (Personal Computer over Internet Protocol (PCoIP)), VMware View 및 Citrix 독립적 컴퓨팅 구조 (Independent Computing Architecture (ICA))를 포함하며 그리고 프레임/디스플레이 버퍼에 압축 기술을 적용할 수 있을 것이다.
프레임 버퍼의 내용이 증가되게 변하기 때문에 비디오 압축 방식은 씬-클라이언트 애플리케이션들을 위한 그래픽 원격 프로세싱에 가장 적합하다. 비디오 압축 방식은 즉각적인 네트워크 대역폭 가용성, 계산의 집중성을 기반으로 하는 적응적인 압축 기술이며 그리고 서버 리소스들 상에 추가적인 부담을 놓는다. 비디오 압축 방식에서, 이미지 품질이 타협되고 그리고 압축 단계로 인해서 추가적인 레이턴시 (latency)가 초래된다.
계산 요구들을 줄이고, 무손실 압축을 가능하게 하며 그리고 레이턴시를 개선하는 그래픽 데이터 전송을 위한 방법, 장치 및 시스템을 가지는 것이 바람직하다.
일 실시예는 전송을 위해서 서버의 그래픽 데이터를 선택하는 방법을 포함한다. 상기 방법은 상기 서버 시스템의 그래픽 메모리로부터 데이터를 읽는 단계를 포함한다. 상기 데이터가 처음으로 읽혀지고 있는 것이며, 그리고 그래픽 렌더링 동안에 상기 서버 시스템의 프로세서에 의해서 써지지 않았으면, 상기 그래픽 메모리로부터 읽혀진 상기 데이터는 전송 버퍼 내에 놓여진다.
다른 실시예는 전송을 위해서 서버의 그래픽 데이터를 선택하는 시스템을 포함한다. 상기 시스템은 프로세서 및 그래픽 메모리를 포함한 서버 시스템을 포함한다. 상기 서버 시스템은 상기 그래픽 메모리로부터 데이터를 읽도록 동작할 수 있다. 상기 서버 시스템은, 상기 데이터가 처음으로 읽혀지고 있는 것이며, 그리고 그래픽 렌더링 동안에 상기 프로세서에 의해서 써지지 않았다면, 상기 데이터를 상기 전송 버퍼 내에 놓아두도록 동작 가능하다.
상기 설명된 실시예들의 다른 모습들 그리고 이점들은, 설명된 실시예들의 원칙들을 예로서 도시한 첨부한 도면들과 함께 취해진 다음의 상세한 설명으로부터 명백할 것이다.
본 발명의 효과는 본 명세서의 해당되는 부분들에 개별적으로 명시되어 있다.
도 1은 서버 시스템 및 클라이언트 시스템 실시예의 블록도를 보여준다.
도 2는 서버로부터 클라이언트로의 전송을 위해 그래픽 데이터를 선택하는 방법의 일 예의 단계들을 포함하는 흐름도이다.
도 3은 전송 버퍼 내에 데이터를 놓아두는 방법의 일 예의 단계들을 포함하는 흐름도이다.
도 4는 전송을 위해 서버 시스템의 그래픽 데이터를 선택하는 방법의 일 예의 단계들을 포함하는 흐름도이다.
도 5는 전송 버퍼 내 데이터를 놓아두는가의 여부를 결정하기 위해서 사용되는 상태-비트들을 세팅하고 리셋하는 예를 보여준다.
도 6은 클라이언트 시스템에서 동작하는 방법의 단계들을 포함하는 흐름도이다.
도 7은 서버 시스템 그리고 클라이언트 시스템의 실시예의 블록 도면을 보여준다.
도 8은 그래픽 시스템에서 하드웨어 지원 메모리 가상화의 블록 도면을 보여준다.
도 9는 그래픽 시스템에서 하드웨어 가상화의 블록 도면을 보여준다.
도 10은 그래픽 시스템에서 패스트 콘텍스트 스위칭 (fast context switching)의 블록 도면을 보여준다.
도 11은 그래픽 시스템에서의 스칼라/벡터 적응적 실행의 블록 도면을 보여준다.
도 12는 그래픽 시스템에서의 스마트한 프리-페치/프리-디코드 기술의 흐름도를 보여준다.
도 13은 비디오 프로세싱 시스템에서 비디오 인코딩을 위한 움직임 추정의 도면을 보여준다.
도 14는 비디오 프로세싱 시스템에서 비디오 포스트-프로세싱을 위한 탭 필터링의 도면을 보여준다.
도 15는 단일 명령어 다중 데이터 (Single Instruction Multiple Data (SIMD)) 분기 기술의 흐름도를 보여준다.
도 16은 프로그램 가능한 출력 병합기의 흐름도를 보여준다.
설명된 실시예들은 전송을 위해서 그래픽 데이터를 선택하기 위한 방법들, 장치들 및 시스템들에서 구체화된다. 이 실시예들은 서버 시스템과 클라이언트 시스템 사이에서 낮은 레이턴시 (latency)를 유지하면서 그래픽 데이터의 무손실 또는 거의-무손실 전송을 제공한다. 상기 설명된 실시예들에 대해서, 무손실 및 거의-무손실은 서로 교체하여 사용될 수 있을 것이며 그리고 무손실 또는 거의-무손실의 압축 및 전송 방법들을 의미할 수 있다. 상기 설명된 실시예들에 대해서, 프로세서는 그래픽 프로세싱 유닛 (GPU), 중앙 프로세싱 유닛 (CPU), 가속 프로세싱 유닛 (APU) 및 디지털 신호 프로세서 (DSP) 중 어느 하나 또는 모두를 포함하지만 그것들로 한정되지는 않는, 그래픽들을 처리하는 기기를 언급하는 것이다. 클라이언트 시스템의 링크 대역폭 그리고/또는 기능들에 종속하여, 상기 설명된 실시예들은 비디오 스트림의 전송을 또한 포함한다. 상기 설명된 실시예들에 대해서, 그래픽 스트림은 그래픽 및 명령 데이터의 부분집합인 압축되지 않은 데이터를 언급하는 것이다. 상기 설명된 실시예들에 대해서, 비디오 스트림은 압축된 프레임 버퍼 데이터를 언급하는 것이다.
도 1은 그래픽 서버-클라이언트 코-프로세싱 (co-processing) 시스템의 실시예의 블록 도면을 보여준다. 상기 시스템은 서버 시스템 (110) 그리고 클라이언트 시스템 (140)으로 구성된다. 서버 시스템 (110)의 이 실시예는 그래픽 메모리 (112), 중앙 프로세싱 유닛 (CPU) (116), 그래픽 프로세싱 유닛 (GPU) (120), 그래픽 스트림 (124), 비디오 스트림 (128), MUX (130), 제어 (132) 및 링크 (134)를 포함한다. 상기 클라이언트 시스템 (140)의 이 실시예는 클라이언트 그래픽 메모리 (142), CPU (144) 및 GPU (148)를 포함한다.
서버 시스템
설명된 실시예들에 대해 도 1에서 보이는 것처럼, 그래픽 메모리 (112)는 명령 및 그래픽 데이터 (114), 프레임 버퍼 (118), 전송 버퍼 (122), 그리고 압축된 프레임 버퍼 (126)를 포함한다. 상기 설명된 실시예들에 대해서, 그래픽 메모리 (112)는 서버 시스템 (110) 내에 존재한다. 다른 실시예에서, 그래픽 메모리 (112)는 서버 시스템 (110) 내에 존재하지 않을 수 있을 것이다. 상기 서버 시스템은 그래픽 데이터를 프로세싱하고 그리고 상기 클라이언트 시스템으로 전송하기 위해서 데이터를 관리한다. 그래픽 메모리 (112)는 동적인 랜덤 액세스 메모리 (Dynamic Random Access memory (DRAM)), 정적인 랜덤 액세스 메모리 (Static Random Access Memory (SRAM)), 플래시 메모리, 콘텐트 어드레서블 메모리 또는 어떤 다른 유형의 메모리 중 어느 하나 또는 모두일 수 있다. 설명된 실시예들에 대해서, 그래픽 메모리 (112)는 그래픽 데이터를 저장하는 DRAM이다. 설명된 실시예들에 대해서, 읽혀진 또는 메모리에 써지는 데이터 블록은 캐시-라인으로 언급된다. 설명된 실시예들에 대해서, 명령 및 그래픽 데이터 (114)의 캐시-라인의 상태는 그래픽 메모리 (112) 내에 저장된다. 다른 실시예에서, 상기 상태는 분리된 메모리 내에 저장될 수 있다. 이 실시예에서, 상태-비트들은 캐시-라인 또는 캐시-라인의 부분집합의 상태를 저장하기 위해서 사용된 메모리의 하나 또는 그 이상의 상태 비트들의 집합에 관련된다. 캐시-라인은 상태-비트들의 하나 또는 그 이상의 집합들을 구비할 수 있다.
설명된 실시예들에 대해서, 그래픽 메모리 (112)는 (도 1에서는 보이지 않는) 시스템 메모리 내에 위치한다. 다른 실시예에서, 그래픽 메모리 (112)는 분리된 전용의 비디오 메모리 내에 있을 수 있다. 상기 CPU 상에서 동작하는 그래픽 애플리케이션은 그래픽 데이터를 시스템 메모리로 로드한다. 설명된 실시예들에 대해서, 그래픽 데이터는 적어도 인덱스 버퍼들, 버텍스 (vertex) 버퍼들 그리고 텍스처 (texture)들을 포함한다. GPU (120)의 그래픽 드라이버는, 예를 들면, 그래픽 애플리케이션에 의해 만들어진 그래픽 애플리케이션 프로그래밍 인터페이스 (Application Programming Interface (API)) 호출들을 명령 데이터로 번역한다. 설명된 실시예들에 대해서, 그래픽 API는 OpenGL 또는 DirectX와 같은 산업 표준 API를 언급하는 것이다. 설명된 실시예들에 대해서, 상기 그래픽 및 명령 데이터는 복제 (copying) 또는 리매핑 (remapping) 중 어느 하나에 의해서 그래픽 메모리 내에 위치한다. 보통은, 상기 그래픽 데이터는 크며 그리고 실제로는 그 모습대로 클라이언트 시스템들로 전송되지 않는 것이 보통이다.
GPU (120)는 명령 및 그래픽 데이터 (114) 내 명령 및 데이터를 프로세싱하고 그리고 그래픽 렌더링 끝 부분에서 프레임 버퍼 (118) 또는 그래픽 렌더링 동안에 전송 버퍼 (122) 중 어느 하나에 데이터를 선택적으로 놓는다. GPU (120)는 그래픽을 조종하고 그리고 디스플레이하기 위한 특별한 프로세서이다. 설명된 실시예들에 대해서, GPU (120)는 2D, 3D 그래픽 및/또는 비디오를 지원한다. 설명될 것처럼, GPU (120)는 압축된 프레임 버퍼 (126) 내에 위치시키는 것을 위해서 압축된 데이터 생성을 관리하며 그리고 압축되지 않은 그래픽 및 명령 데이터의 부분집합이 전송 버퍼 (122) 내에 위치된다. 전송 버퍼로부터의 데이터는 그래픽 데이터를 포함하며 그리고 그래픽 스트림 (124)으로서 언급된다.
전송 버퍼 (122)는 그래픽 렌더링하는 동안에 명령 및 그래픽 데이터의 선택된 부분집합으로 채워진다. 명령 및 그래픽 데이터 (114)로부터의 데이터의 선택된 부분집합은, 그 데이터의 부분집합을 프로세싱함으로써 상기 클라이언트 시스템에 의해서 획득된 그 결과들이 명령 및 그래픽 데이터 (114)의 전체 콘텐트들을 프로세싱하는 것과 동일하거나 또는 거의 동일할 수 있도록 한다. 전송 버퍼 (122)를 채우기 위해서 명령 및 그래픽 데이터 (114)로부터 데이터의 부분집합을 선택하는 프로세스는 도 2에 관련하여 더 설명된다. 그래픽 렌더링 프로세스 동안에, GPU (120)는 전송 버퍼 (122)를 채운다. 설명된 실시예들에 대해서, 전송 버퍼의 콘텐트들은 그래픽 데이터와 함께 적어도 명령 데이터 또는 그래픽 API 명령 호출들을 포함한다. 일 실시예에 대해, 전송 버퍼 (122)의 할당된 크기는 상기 링크 상의 최대 가용 대역폭에 의해서 적응적으로 결정된다. 예를 들면, 프레임 버퍼의 크기는 상기 서버 시스템과 상기 클라이언트 시스템 사이의 링크의 대역폭이 변함에 따라서 시간에 따라 동적으로 변할 수 있다.
이 실시예에서, GPU (120)는 프레임 버퍼 (118) 그래픽 렌더링 그리고 압축된 프레임 버퍼 (126) 생성을 담당한다. 이 실시예에서, 클라이언트가 그래픽 스트림을 전송하기 위한 기능들을 구비하지 않거나 또는 대역폭이 충분하지 않으면 압축된 프레임 버퍼 (126)가 생성된다. 상기 압축된 프레임 버퍼는 산업 표준의 압축 기술들, 예를 들면, MPEG2 및 MPEG4를 이용하여 프레임 버퍼 (118)의 콘텐트들을 인코딩함으로써 생성된다.
그래픽 스트림 (124)은 압축된 그래픽 데이터 및 적어도 데이터 유형 정보를 구비한 헤더를 적어도 포함한다. 그래픽 스트림 (124)은 그래픽 랜더링 동안에 생성되며 그리고 상기 전송 버퍼가 데이터를 가지고 있으면 이용 가능할 수 있을 것이다.
비디오 스트림 (128)은 압축된 비디오 데이터 및 압축해제를 위해 데이터 유형을 번역하기 위해 필요한 정보를 운반하는 헤더를 적어도 포함한다. 비디오 스트림 (128)은 압축된 프레임 버퍼 (126)가 생성되면 그리고 생성될 때에 이용 가능할 수 있다.
mux (130)는 상기 전송 버퍼 (122)로부터의 데이터에 의해서 생성된 그래픽 스트림 (124) 그리고 압축된 프레임 버퍼 (126)로부터의 데이터에 의해서 생성된 비디오 스트림 (128) 사이에서의 선택을 도시한다. mux (130)에 의한 선택은 프레임 단위 (frame-by-frame)를 기반으로 하여 수행되며 그리고, 몇몇의 실시예들에서는 상기 GPU (120)에 의해서 적어도 생성된 참조번호 132의 제어에 의해서 제어된다. 프레임은 디스플레이를 위해서 프레임-버퍼를 생성하기 위한 프로세싱 시간의 간격이다. 다른 실시예들에 대해서, 제어 (132)는 CPU 및/또는 GPU에 의해서 생성된다. 설명된 실시예들에 대해서, 제어 (132)는 상기 서버 시스템 (132)과 상기 클라이언트 시스템 (140) 사이 링크 (134)의 대역폭 그리고 상기 클라이언트 시스템 (140)의 프로세싱 기능들 중 어느 하나에 적어도 부분적으로 종속한다.
mus (130)는 상기 그래픽 스트림과 상기 비디오 스트림 사이에서 선택하며, 그 선택은 클록 사이클 당 한 번 발생할 수 있으며, 이는 보통은 한 프레임보다 작다. 이 실시예에서, 링크 (134) 상으로 전송된 데이터는 압축된 프레임 버퍼 그리고/또는 전송 버퍼로부터의 데이터로 구성된다. 몇몇의 실시예들에 대해서, 링크 (134)는 서버 시스템 (110)으로부터 클라이언트 시스템 (140)으로 그래픽/비디오 스트림을 전송하기 위한 전용의 광역 그래픽 네트워크 (Wide Area Graphics Network (WAGN))/로컬 영역 그래픽 네트워크 (Local Area Graphics Network (LAGN))이다. 일 실시예에서, 속도 및 신뢰성의 최적 조합을 제공하기 위해서 혼성 전송 제어 프로토콜 (Transmission Control Protocol (TCP))-사용자 데이터그램 프로토콜 (User Datagram Protocol (UDP))이 구현될 수 있을 것이다. 예를 들면, 상기 TCP 프로토콜은 상기 명령/제어 패킷들을 전송하기 위해서 사용되며 그리고 상기 UDP 프로토콜은 데이터 패킷들을 전달하기 위해서 사용된다. 예를 들면, 명령/제어 패킷은 이전에 설명된 명령 데이터일 수 있으며, 상기 데이터 패킷들은 상기 그래픽 데이터일 수 있다.
클라이언트 시스템
상기 클라이언트 시스템은 상기 서버 시스템으로부터 데이터를 수신하고 그리고 사용자 디스플레이를 위해서 상기 수신한 데이터를 관리한다. 상기 설명된 실시예들에 대해서, 클라이언트 시스템 (140)은 적어도 클라이언트 메모리 (142), CPU (144), 그리고 GPU (148)를 포함한다. 적어도 프레임 버퍼를 포함하는 클라이언트 그래픽 메모리 (142)는 DRAM (Dynamic Random Access memory), SRAM (Static Random Access Memory), 플래시 메모리, 콘텐트 어드레스블 메모리 또는 다른 유형의 메모리일 수 있다. 이 실시예에서 클라이언트 그래픽 메모리 (142)는 명령 및 그래픽 데이터를 저장하는 DRAM이다.
일 실시예에서, 상기 서버 시스템 (110)으로부터 링크 (134)를 경유하여 수신된 그래픽/비디오 스트림은 데이터의 프레임이며 그리고 디스플레이를 위해 프레임 버퍼를 생성하기 위해서 표준의 그래픽 렌더링 또는 비디오 프로세싱 기술들을 이용하여 처리된다. 상기 수신한 프레임은 적어도 헤더 및 데이터를 포함한다. 상기 설명된 실시예들에 대해서, 상기 GPU는 데이터를 처리하기 위해서 압축되지 않은 그래픽 스트림 또는 압축된 비디오 스트림을 적어도 포함할 수 있는 데이터 유형을 탐지하기 위해서 상기 헤더를 읽는다. 상기 수신한 데이터를 핸들링하는 방법은 도 5에 관련하여 설명된다.
도 2는 상기 서버로부터 상기 클라이언트로의 전송을 위해서 그래픽 데이터를 선택하는 방법의 일 예의 단계들을 포함하는 방법 (200)의 흐름도이다. 단계 210에서, 명령 데이터 버퍼 생성이 발생한다. 이 단계에서, 시스템 메모리 내 명령 데이터를 변환하기 위해서 그래픽 소프트웨어 애플리케이션 명령들은 상기 GPU 소프트웨어 드라이버에 의해서 컴파일된다. 이 단계는 상기 시스템 메모리에 그래픽 데이터를 로딩하는 프로세스를 또한 포함한다.
단계 220에서, 명령 및 그래픽 데이터 버퍼가 할당된다. 이 단계에서, 프리 (free) 또는 사용되지 않은 그래픽 메모리 (112)의 일부는 요구사항 (requirement)을 기반으로 하여 명령 및 그래픽 데이터 (114)로서 정의되며 그리고 시스템 메모리 내의 상기 명령 및 그래픽 데이터는 상기 그래픽 메모리가 전용의 비디오 메모리라면 그래픽 메모리 (112)로 복사되며 또는 상기 그래픽 메모리가 시스템 메모리의 일부가 아니라면 시스템 메모리 내의 상기 명령 및 그래픽 데이터는 그래픽 메모리 (112)로 리맵/복사된다.
단계 230에서, 그래픽 데이터는 서버 시스템 (110) 상에서 렌더링된다. 명령 및 그래픽 데이터 (114)로부터 읽혀진 서버 시스템 (110) 내의 그래픽 데이터는 GPU (120)에 의해서 렌더링된다. 설명된 실시예들에 대해서, 그래픽 렌더링 또는 3D 렌더링은 3차원 씬 (scene) 데이터를 기반으로 하여 2차원 이미지를 산출하는 프로세스이다. 그래픽 렌더링은 폴리곤들을 프로세싱하고 그리고 디스플레이를 위해서 프레임 버퍼 (118)의 콘텐트들을 생성하는 것을 포함한다. 삼각형들, 라인들 & 포인트들과 같은 폴리곤들은 버텍스 버퍼/버퍼들 내에 저장된 버텍스들과 연관된 속성들을 구비하며 그리고 그 폴리곤들이 어떻게 프로세싱 되는가를 결정한다. 위치 좌표들은 선형의 (스케일링, 회전, 변환 등) 그리고 뷰 (세계 그리고 뷰 스페이스) 변환을 겪는다. 상기 폴리곤들은 그 내부에 둘러싸여진 픽셀들을 판별하기 위해서 래스터화 (rasterized) 된다. 텍스처링 (texturing)은 이 픽셀들 상으로 텍스처 이미지들을 인가하고/페이스트 (paste)하기 위한 기술이다. 상기 픽셀 색상 값들은 프레임 버퍼 (118)로 써진다.
단계 240은 압축 기술을 결정하기 위해서 상기 클라이언트 기능들을 체크하는 것을 포함한다. 상기 설명된 실시예들에 대해서, 클라이언트 그래픽 메모리 (142)의 크기 및 대역폭, 상기 클라이언트 시스템 내의 그래픽 API 지원, GPU (148)의 성능 그리고 클라이언트 시스템 (140)의 압축해제 기능들은 클라이언트 시스템 기능들을 구성한다.
상기 클라이언트 시스템이 기능들을 구비할 때에, 전송 버퍼가 생성된다. 단계 260에서, 전송 버퍼 (122)의 콘텐트들은 그래픽 렌더링 동안에 생성된다. 데이터가 렌더링되면 그리고 렌더링될 때에 데이터는 전송 버퍼 (122)에 써진다. 그래픽 및 명령 데이터의 부분집합이 식별되며 그리고 데이터의 유일 인스턴스 (unique instance)들이 전송 버퍼 (12) 내에 데이터를 놓아두는 것을 위해서 선택되며, 이는 도 3에 관련하여 설명된다. 전송 버퍼로부터의 데이터는 그래픽 스트림 (124)으로 언급된다.
단계 270에서, 참조번호 200의 방법은 서버 시스템 (110)과 클라이언트 시스템 (140)을 연결시키는 링크 (134)의 대역폭을 적어도 체크한다. 충분한 대역폭이 이용 가능하면, 그래픽 스트림 (124)은 단계 290에서 전송된다.
이용 가능한 대역폭이 충분하지 않으면 또는 상기 클라이언트 시스템이 기능들을 구비하지 않는다면, 압축된 프레임 버퍼 (126)가 생성된다. 단계 250에서, MPEG2, MPEG4 또는 어떤 다른 압축 기술들을 이용하여 프레임 버퍼의 콘텐트들을 인코딩함으로써 압축된 프레임 버퍼가 생성된다. 압축 기술을 선택하는 것은 상기 클라이언트 기능들에 의해서 결정된다. 그래픽 렌더링이 완료된 이후에, 상기 압축된 프레임 버퍼는 프레임 버퍼 (118)의 압축 동안에 채워진다. 단계 280에서, 압축된 프레임 버퍼가 전송된다.
도 3은 데이터를 전송 버퍼 (122) 내에 위치시키는 방법의 일 예의 단계들을 포함하는 방법 (300)의 흐름도이다. 단계 310에서, 캐시-라인 또는 데이터의 블록이 서버 시스템에 의해서 명령 및 그래픽 데이터 (114) 또는 프레임 버퍼 (118) 그래픽 렌더링으로부터 읽혀진다
단계 320에서, 상기 캐시-라인 내의 데이터가 새로운 것인가의 여부를 판별하기 위해서 상기 캐시-라인이 처음으로 읽혀지는 것인가에 대해 체크된다. 그 데이터가 이전에 읽혀졌다면, 그 데이터는 클라이언트 시스템 (140) 상에서 이용 가능하며 또는 전송 버퍼 (122) 내에 존재하며; 상기 캐시-라인이 더 이상 처리되지 않으며 참조번호 300의 방법은 단계 310으로 돌아간다. 상기 캐시-라인이 처음으로 읽혀지고 있는 것이라면, 상기 클라이언트 시스템은 상기 데이터를 가지고 있지 않으며 그리고 상기 전송 버퍼 (122) 내에 존재하지 않으며, 참조번호 300의 방법은 단계 330으로 진행한다.
단계 330에서, 프레임 버퍼 (118) 또는 명령 및 그래픽 데이터 (114)의 캐시-라인이 체크되어, 그 캐시-라인 내의 데이터가 그래픽 렌더링 동안에 프로세서에 의해서 써졌는가의 여부를 검사한다. 상기 캐시-라인 내의 데이터가 프로세서에 의해서 써졌다면, 캐시-라인 내의 데이터는 프로세싱되지 않으며 그리고 참조번호 300의 방법은 단계 310으로 돌아간다. 상기 캐시-라인이 상기 프로세서에 의해서 써지지 않았다면, 그러면 참조번호 300의 방법은 단계 340으로 진행한다. 단계 340에서, 상기 캐시-라인은 전송 버퍼 (122) 내에 놓여진다.
도 4는 전송을 위해서 서버 시스템의 그래픽 데이터를 선택하는 방법의 예의 단계들을 포함하는 흐름도이다. 첫 번째 단계 (410)는 상기 서버 시스템의 그래픽 메모리로부터 데이터를 읽는 것을 포함한다. 두 번째 단계 (420)는 그 데이터가 처음으로 읽혀지고 있는 것이며, 그리고 그래픽 렌더링 동안에 상기 서버 시스템의 프로세서에 의해서 써지지 않았다면 전송 버퍼 내에 그 데이터를 놓아주는 것을 포함한다. 세 번째 단계 (430)는 상기 전송 버퍼 내의 상기 데이터를 클라이언트 시스템으로 전송하는 것을 포함한다. 일 실시예에서, 상기 프로세서는 CPU 및/또는 GPU이다.
이 실시예에서, 상기 서버 시스템은 중앙 프로세싱 유닛 (CPU) 그리고 그래픽 프로세싱 유닛 (GPU)를 포함한다. 상기 GPU는 프레임 버퍼의 데이터를 압축하고 그리고 압축된 프레임 버퍼로 위치시키는 것을 제어한다. 상기 GPU는 상기 압축된 프레임 버퍼의 압축된 데이터 또는 상기 전송 버퍼의 압축되지 않은 데이터 중 어느 하나를 클라이언트 시스템으로의 전송을 위해서 선택하는 것을 제어한다.
제1 상태-비트를 체크하는 것은 상기 데이터가 처음으로 읽혀지고 있는 것인가의 여부를 판별한다. 그 제1 상태-비트는 상기 데이터가 상기 전송 버퍼 내에 놓여지며 그리고 아직 전송되지 않을 때에 세팅된다.
읽혀지고 있는 그 데이터는 데이터의 블록인 캐시-라인일 수 있다. 하나 또는 그 이상의 상태-비트들은 상기 캐시-라인의 상태를 정의한다. 다른 실시예에서, 상기 캐시-라인의 각 서브-블록은 하나 또는 그 이상의 상태-비트들을 구비할 수 있다. 일 실시예에 대해서, 상기 데이터는 복수의 블록들을 포함하며, 그리고 상기 데이터가 처음으로 읽혀지고 있는가의 여부를 판별하는 것은 적어도 하나의 블록에 대응하는 적어도 하나의 상태-비트를 체크하는 것을 포함한다.
제2 상태-비트는 상기 데이터가 상기 프로세서에 의해서 써지지 않았는가의 여부를 판별한다. 상기 제2 상태-비트는 상기 프로세서가 상기 그래픽 메모리에 쓸 때에 세팅된다. 상기 제1 상태-비트는 상기 그래픽 메모리의 다이렉트 메모리 액세스 (direct memory access (DMA)) 또는 상기 그래픽 메모리의 재할당을 탐지하면 리셋된다. 상기 제2 상태-비트는 상기 그래픽 메모리의 다이렉트 메모리 액세스 (direct memory access (DMA)) 또는 상기 그래픽 메모리의 재할당을 탐지하면 리셋된다. DMA는 상기 시스템 메모리로부터 그래픽 메모리로 데이터를 복사하는 프로세스를 언급하는 것이다.
전송을 위해서 서버 시스템의 그래픽 데이터를 선택하는 상기 방법은 상기 그래픽 메모리의 프레임 버퍼의 데이터를 압축하는 것을 더 포함한다.
전송을 위해서 서버 시스템의 그래픽 데이터를 선택하는 상기 방법은 상기 서버 시스템과 클라이언트 시스템 사이의 링크 대역폭, 그리고 상기 클라이언트 시스템의 기능들 중 적어도 하나를 체크하는 단계를 더 포함하며, 상기 서버 시스템은 상기 링크들의 대역폭 그리고 상기 클라이언트 시스템의 상기 기능들 중 적어도 하나를 적어도 부분적으로 기반으로 하여 상기 전송 버퍼 또는 상기 압축된 프레임 버퍼 중 적어도 하나를 전송한다.
상기 프레임 버퍼의 데이터를 프레임 단위 기반으로 압축하는가의 여부를 결정하고, 그리고 상기 데이터의 일부를 매 프레임마다 상기 전송 버퍼 내에 놓아두기 위해서, 상기 대역폭 그리고 상기 클라이언트 기능들은 프레임 단위를 기반으로 하여 체크된다. 어떤 실시예에 대해서, 프레임 단위 기반으로 체크하는 것은 상기 클라이언트 기능들 그리고 상기 대역폭을 각 프레임의 시작에서 체크하고, 그리고 그에 따라서, 상기 압축된 또는 압축되지 않은 데이터를 상기 프레임에 대해 상기 프레임 버퍼 또는 전송 버퍼 내에 놓아두는 것을 포함한다.
적절한 대역폭이 이용 가능하고 그리고 상기 클라이언트가 그래픽 스트림 (124)를 프로세싱할 수 있으면, 상기 전송 버퍼는 상기 클라이언트 시스템으로 전송된다. 상기 대역폭 그리고 상기 클라이언트 기능들이 상기 그래픽 스트림 (124)이 전송될 수 없다는 것을 결정하면, 그러면 압축된 프레임 버퍼 데이터 그리고 옵션으로는 부분적으로 압축되지 않은 전송 버퍼 데이터가 상기 클라이언트 시스템으로 전송된다. 상기 클라이언트 시스템이 압축되지 않은 데이터를 핸들링하기 위한 기능들을 구비하지 않으면, 그러면 압축된 프레임 버퍼 데이터가 상기 클라이언트 시스템으로 전송된다. 상기 전송 버퍼가 상기 클라이언트 시스템으로 전송될 수 있으면, 상기 압축 페이즈 (phase)는 탈락되고 그리고 어떤 압축된 비디오 스트림도 생성되지 않는다.
상기 서버 시스템은 상기 프레임 버퍼의 데이터의 다음의 압축을 위해서 레퍼런스 프레임/프레임들을 유지한다. 각 프레임에 대해서, 무손실 그래픽 데이터 또는 손실 비디오 압축 데이터 중 어느 하나를 송신하기 위한 결정이 내려진다. 상기 서버 상에서 특별한 프레임에 대한 비디오 압축을 구현할 때에, 이전의 프레임들이 레퍼런스 프레임들로서 사용된다. 상기 레퍼런스 프레임들은 상기 클라이언트로 전송된 무손실 프레임 또는 손실 프레임에 대응한다.
도 5는 전송 버퍼 내에 데이터를 놓아두어야 하는가의 여부를 결정하기 위해서 사용되는 상태-비트들의 세팅 및 리세팅의 예를 보여준다. 설명된 실시예들에 대해서, 클라이언트 시스템으로의 전송을 위해서 전송 버퍼 내에 캐시-라인이 놓여질 수 있는가를 결정하기 위해서 적어도 두 개의 상태-비트들이 필요하다. '00', '01', '11' 그리고 '10'은 상기 상태-비트들의 상태 또는 상기 상태-비트들의 값을 나타낸다.
'00' 상태로부터: 서버 그래픽 데이터의 캐시-라인이 프로세서들에 의해서 명령 및 그래픽 데이터 (114) 그리고/또는 프레임 버퍼 (118)로부터 처음으로 읽혀지거나 또는 써질 때에 (단계 310), 각 캐시-라인의 상태-비트들은 '00'의 값을 가지며, 이는 또한 상태 '00'으로 언급된다. 상기 캐시-라인은 상기 프로세서들에 의해서 읽혀지거나 또는 상태를 변경시키기 위해서 상기 프로세서에 의해서 써지는 것 중 어느 하나를 수행할 수 있다. 상기 프로세서가 상기 캐시-라인을 읽을 때에, 상기 상태-비트들은 '01' 상태로 업데이트 된다. 상기 캐시-라인이 상기 프로세서에 의해서 써지면, 상기 캐시-라인의 상기 상태-비트들은 '10' 상태로 업데이트 된다.
'01' 상태로부터: 상기 캐시-라인이 클라이언트 시스템 (140)으로 전송될 때에 상기 프로세서에 의해서 읽혀진 상기 캐시-라인의 상태 비트들은 상태 '11'로 업데이트 된다. 상기 캐시-라인이 대역폭의 제한들로 인해서 전송되지 않았다면 상기 상태-비트들은 '00' 상태로 리셋된다.
'11' 상태로부터: 상기 캐시-라인이 전송 버퍼 (122)를 경유하여 클라이언트 시스템 (140)으로 전송될 때에 상기 상태-비트들은 값 '11'을 가질 수 있다. 상기 캐시-라인이 메모리 재할당 또는 다이렉트 메모리 액세스 (DMA) 동작으로 인해서 클리어될 때에 상기 상태-비트들은 리셋된다.
'10' 상태로부터: 프로세서 (120)에 의해서 캐시-라인이 일단 써지면, 그 캐시-라인은 전송 버퍼를 경유하여 전송될 수 없으며 그리고 '10'인 것으로 가정된다. 상기 캐시-라인의 상태-비트들은 메모리 재할당 또는 다이렉트 메모리 액세스 (DMA) 동작으로 인해서 리셋된다.
도 6은 클라이언트 시스템을 동작시키는 방법의 단계들을 포함하는 방법 (600)의 흐름도이다. 단계 610에서, 하나 또는 그 이상의 핸드셰이킹 동작들에서 클라이언트 시스템 (140)은 서버 시스템 (110)과의 접속을 설립하며 그리고 클라이언트 시스템 (140)의 기능들과 통신한다. 단계 620에서, 클라이언트 시스템 (140)은 서버 시스템 (110)으로부터 데이터의 프레임을 수신한다. 이 실시예에서, 수신된 상기 데이터는 데이터의 유형 그리고 데이터에 이어지는 압축 기술의 유형에 관한 정보를 구비한 헤더를 포함한다. 상기 수신된 데이터는 하나 또는 그 이상의 헤더 그리고 데이터 조합들을 포함하며, 그래서 상기 헤더와 데이터가 아마도 인터리브 (interleave)될 수 있도록 한다.
단계 630에서, 참조번호 600의 방법은 상기 데이터 유형을 탐지하기 위해서 상기 데이터 헤더를 읽는다. 참조번호 600의 방법이 압축되지 않은 데이터를 탐지하면, 참조번호 600의 방법은 단계 640으로 진행한다. 그 방법 (600)이 압축된 데이터를 탐지하면, 그 방법 (600)은 단계 650으로 진행한다. 수신된 데이터의 그래픽 렌더링은 단계 640에서 발생한다. 단계 650에서, 참조번호 600의 방법은 상기 수신된 데이터를 압축 해제한다. 단계 660에서, 데이터는 디스플레이를 위해서 클라이언트 그래픽 메모리 (142)의 프레임 버퍼 내에 놓여진다.
확장 및 대안들 (Extensions and Alternatives)
네트워크 그래픽
도 6은 서버 시스템 및 클라이언트 시스템의 실시예의 블록 도면을 보여준다. 클라우드 컴퓨팅이 시작으로, 분산 컴퓨팅으로부터 집중식 컴퓨팅으로 파라다임이 이동하고 있다. 상기 시스템 내의 모든 리소스들은 집중화된다. 이것들은 CPU, 저장부, 네트워킹 등을 포함한다. 애플리케이션들은 집중식 서버 상에서 실행되며 그리고 그 결과들은 클라이언트들에게 향한다. 이 모델은 여러 시나리오들에서 잘 동작하지만 그러나, 소비자 공간에서 점점 더 중요하게 되어가고 있는 그래픽이 풍부한 애플리케이션들을 실행하는 것을 해결하기에는 실패했다. 집중식 그래픽 계산은 아직 적절하게 해결되지 않았다. 이는 GPU의 가상화 그리고 GPU 출력 버퍼들을 상기 클라이언트로 전달하는 것에 대한 대역폭 압박들에 따른 문제들 때문이다.
씬-클라이언트 애플리케이션들을 위한 그래픽을 리모팅 (remoting)하기 위해서 상이한 독점적인 기술들이 현재 사용된다. 이것들은 마이크로소프트 RDP (Remote Desktop Protocol), PCoIP, VMware View 그리고 Citrix ICA를 포함한다. 이것들 모두는 프레임/디스플레이 버퍼에 적용된 몇몇 유형의 압축 기술에 의존한다. 상기 프레임 버퍼 콘텐트가 증가하면서 변경하는 특징이 주어지면, 비디오 압축 방식이 가장 적합하다. 비디오 압축은 순간적인 대역폭 가용성을 기반으로 하여 스스로를 적응적 압축으로 적합하게 하는 기술이다. 비디오 압축 기술은 아주 작은 한계들을 가진다. 이것들은 다음의 것들을 포함한다:
o 계산 집약적이며 그리고 서버 리소스들 상에 대량의 추가적인 부담을 부가한다.
o 적절한 압축을 달성하기 위해서, 이미지 품질에 대해서 타협이 이루어진다.
o 원격 그래픽에서 네트워크 레이턴시 (latency)는 문제이다. 압축 페이즈 (compression phase)로 인해서 추가적인 레이턴시가 도입된다.
그래픽 API의 발전은 API 레벨에서 가변이지만 상대적으로 낮은 대역폭 인터페이스를 또한 생성했다. 프로세싱을 위해서 상기 GPU가 필요로 하는 상이한 리소스들/서피스들 (인덱스들, 버텍스들, 상수 버퍼들 (constant buffers), 셰이더 (shader) 프로그램들, 텍스처들)이 존재한다. 3d 그래픽 프로세싱에서, 이 리소스들은 다중의 프레임들을 위해서 재사용되며 그리고 크로스-프레임 캐싱 (cross-frame caching)을 가능하게 한다. 버텍스 및 텍스처 데이터는 이용 가능한 비디오 메모리 공간 (foot-print)의 가장 큰 소비자들이지만, 그 데이터의 작은 비율만이 실제로 사용되며 그리고 활용은 다중의 프레임들을 가로질러서 전개된다.
3D API의 상기-설명된 특성은 API 리모팅의 방식을 개발하기 위해서 활용된다. 대역폭 요구사항들을 크게 손질 (trim)하기 위해서 그리고 API 리모팅을 가능하게 하기 위해서 서버-클라이언트 코-프로세싱 (co-processing) 모델이 개발되었다. 상기 서버는 모든 데스크탑 그래픽 애플리케이션들이 상기 서버 상에서 동작하는 스탠드-얼론 시스템으로 동작한다. 실행하는 동안에, 주요한 정보가 모여지며 이는 클라이언트 측 상에서 동일한 것을 실행하기 위해서 필요한 데이터의 최소 집합을 식별한다. 상기 데이터는 그러면 네트워크를 통해서 전달된다. 상기 API 인터페이스 대역폭이 가변이므로, 적절한 대역폭 가용성을 보증할 수 없다. 그래서 적응적인 기술이 채택되며, 그럼으로써, 필요한 API 리모팅 대역폭이 이용 가능한 대역폭을 초과할 때에, (최소의 데이터-전달을 위한 통계를 생성하기 위해서 어쨌든 서버 측에서 생성되었던) 디스플레이 프레임이 비디오-인코딩되며 그리고 네트워크를 통해서 송신된다. 그 결정은 프레임 입도 (frame granularity)에서 이루어진다.
메모리 내의 데이터는 캐시-라인들의 형상으로 저장된다. 비트-맵은 각 캐시-라인의 상태를 추적하는 서버 측 상에서 유지된다. 상기 비트-맵은 다음을 표시한다.
● 0 - 상기 캐시-라인은 깨끗하다 (마지막 DMA 쓰기 이후에 써진 적이 없으며 또는 결코 액세스된 적이 없음)
● 1 - 클라이언트로 전달되었음
특별한 캐시-라인이 액세스되고 그리고 그 상태가 '0'일 때에, 그 액세스된 데이터는 네트워크 링 내에 놓여지며 그리고 그 상태는 '1'로 업데이트 된다. 상기 네트워크 링이 넘치면 (overflow), 즉, API 리모팅을 위해 필요한 대역폭이 이용 가능한 네트워크 대역폭을 초과하면, 실행은 계속되지만 상기 비트맵/네트워크 링을 업데이트하지는 않는다. 상기 네트워크 링 내의 상기 데이터는 상기 클라이언트로 흘러간다. 최종의 디스플레이 버퍼를 생성한 이후에, 그것은 전송을 위해서 적응적으로 비디오-인코딩된다. 시간이 흐르면, API 리모팅을 위한 대역폭 요구사항들은 점차적으로 감소되며 그리고 결국은 그것을 가능하게 할 것이다.
상기 서버로부터 상기 클라이언트로 그래픽 네트워크 데이터를 운반하기 위해서 전용의 WAGN/LAGN (Wide/Local Area Graphics Network)이 구현된다. 속도 및 신뢰성의 최적 조합을 제공하기 위해서 혼성 TCP-UDP 프로토콜이 구현된다. 상기 TCP 프로토콜은 상기 명령/제어 패킷들 (명령 버퍼들/셰이더 프로그램들)을 전송하기 위해서 사용되며 그리고 상기 UDP 프로토콜은 상기 데이터 패킷들 (인덱스 버퍼들/버텍스 버퍼들/텍스쳐들/상수 버퍼들)을 전달하기 위해서 사용된다.
상기 서버 상에서 그래픽 프리-프로세서 (pre-processor)에 대한 필요성을 피하기 위해서, 서버 측 상에서 동작하는 소프트웨어는 프로세싱을 위해서 상기 클라이언트로 송신될 트래픽을 생성할 수 있다. 상기 서버 상에서 동작하는 드라이버 스택은 작업 부하를 프로세싱하기 위해서 필요한 서피스들/리소스들/상태를 식별하고 그리고 연관된 데이터를 시스템 네트워크를 통해서 상기 클라이언트로 푸시할 수 있을 것이다. 개념적으로는, 상기에서 언급된 대역폭 감소 방식 (소프트웨어 래스터라이저 (rasterizer)를 이용하여 서버 상에서의 작업 부하를 동작시키고 그리고 클라이언트 측 상에서의 프로세싱을 위한 최소의 데이터를 식별한다)이 또한 구현될 수 있으며 그리고 짧게-목록화된 데이터가 상기 클라이언트로 전달될 수 있다.
그래픽 가상화 (Graphics Virtualization) - 하드웨어 지원
가상화는 컴퓨팅 리소스들의 물리적인 특성들을 감추어서 다른 시스템들, 애플리케이션들 또는 최종 사용자들이 그 리소스들과 상호작용 (interact)하는 방식을 단순화하는 기술이다. 상기 제안은 그래픽 리소스들의 가상화를 지원하기 위해서 하드웨어에서 구현된 상이한 특징들을 목록화 한다. 이 특징들은 다음의 것들을 포함한다:
메모리 가상화 (Memory virtualization)
도 7은 그래픽 시스템에서 메모리 가상화를 돕는 하드웨어의 블록 도면을 보여준다. 비디오 메모리는 가상 머신들 (VMs) 사이에서 분할된다. 각 VM에 할당된 메모리의 양은 활용도 및 가용도를 기반으로 하여 정기적으로 업데이트 된다. 그러나, VM들 사이에 겹치는 메모리는 존재하지 않는다는 것이 보장되며 그래서 비디오 메모리 관리는 상기 VM들에 의해서 수행될 수 있도록 한다. 하드웨어는 32 MB의 메모리 블록들에 관하여 각 VM에 대한 할당의 추적을 보유한다. 그래서 상기 VM들에 의해서 사용된 주소들을 실제의 비디오 메모리 주소들로 리매핑하는 것은 하드웨어에 의해서 수행된다.
하드웨어 가상화 (Hardware virtualization)
도 8은 그래픽 시스템에서의 하드웨어 가상화의 블록 도면을 보여준다. VM들에 전용인 하드웨어를 모습을 제공하기 위해서, 각 VM에게는 상기 하드웨어로의 엔트리 포인트가 제공된다. VM들은 작업 부하들을 상기 하드웨어로 타임-슬라이스 방식으로 배달한다. 상기 하드웨어는 각 VM들로부터 이 작업 부하들을 실행하는 것을 공정하게 중재하고 관리하기 위한 메커니즘을 구축한다.
빠른 컨텍스트 - 스위칭 (Fast context- switching)
도 9는 그래픽 시스템에서의 빠른 컨텍스트 스위칭의 블록 도면을 보여준다. 하드웨어 가상화를 이용하여, 컨텍스트 스위치들의 개수 (작업 부하들을 변경하는 것)는 더욱 많을 것이다. 효과적인 하드웨어 가상화를 얻기 위해서, 상기 VM들 사이에서 스위칭할 때에 최소의 오버헤드를 가지기 위해서 빠른 컨텍스트-스위칭이 필요하다. 상기 하드웨어는 스위치 레이턴시를 감추기 위해서 빠른 응답 그리고 또한 동시 발생의 컨텍스트 세이브 (save) 및 복구를 위한 스레드-레벨 컨텍스트 스위칭을 구현한다.
스칼라/벡터 적응적 실행 (Scalar/Vector adaptive execution)
도 10은 그래픽 시스템에서 스칼라/벡터 적응적 실행의 블록 도면을 보여준다.
프로세서는, 상기 기기에 맞추어서 프로그램된, 정의된 명령어-집합을 가진다. 상이한 명령어-집합들이 여러 해에 걸쳐서 개발되었다. OpenCL/DirectCompute 용의 베이스라인 스칼라 명령어-집합은 하나의 데이터 엔티티 상에서 동작하는 명령어들을 정의한다. 벡터 명령어-집합은 다중의 데이터 상에서 동작하는 명령어들을 정의하며, 즉, 그것들은 SIMD이다. 3D 그래픽 API들 (openGl/DirectX)은 4-채널 오퍼랜드들을 동작시키는 벡터 명령어 집합을 정의한다.
우리가 가진 방식은 상기 프로세서 코어가 동등한 효율성을 가지고 스칼라/4-D 벡터 명령어 집합들의 적응적인 실행들을 수행하도록 하는 기술을 여기에서 정의한다. 온-칩 레지스터들 또는 메모리 내 버퍼들로부터 읽혀진 데이터 오퍼랜드 (operand)들은 ALU 계산 블록 폭의 4배이다. 상기 데이터는 4 클록에 걸쳐서 상기 계산 블록으로 직렬화 된다. 벡터 명령어들에 대해서, 데이터의 4개 집합들은 실행 스레드 (execution thread) 용의 하나의 레지스터에 대응한다. 스칼라 명령어들에 대해서, 데이터의 4개 집합들은 네 개의 실행 스레드들 용의 하나의 레지스터에 대응한다. 상기 ALU의 출력에서, 결과 데이터의 4개 집합들이 모여지며 그리고 상기 온-칩 레지스터들로 반대로 써진다.
스마트 프리-페치/프리-디코드 기술 (Smart Pre-fetch/Pre-decode technique)
도 11은 그래픽 시스템에서 스마트 프리-페치/프리-디코드 기술의 흐름도를 보여준다.
오늘날의 프로세서들은 계산 코어 내에 다중의 파이프라인 스테이지 (stage)들을 구비한다. 피딩된 파이프라인을 보유하는 것은 설계자들에 대한 도전이다. (메모리로부터의) 페치 레이턴시 (Fetch latency)들 그리고 분기하는 것 (branching)은 성능에는 크게 불리하다. 이 문제점들에 중점을 두어 다루기 위해서, 계산 파이프라인에서의 높은 효율성을 유지하기 위해서 많은 복잡함이 추가된다. 그 기술들은 추론적인 프리페칭 (speculative prefetching) 그리고 분기 예측 (branch prediction)을 포함한다. 이 솔루션들은 단일-스레드 시나리오들에서 필요하다. 다중-스레드 프로세서들은 문제점들의 이 동일한 집합을 완화시키기 위해서 유일한 실행 모델로 자신들을 참가시킨다.
다중-스레드 프로세서 상에서 어떤 스레드 용의 프로그램을 실행하면서, 단 하나의 명령어 캐시-라인만이 (이는 다중 명령어들 시간으로 만들어진 것이다. 상기 명령어 캐시-라인 내 명령어들을 처리하기 위해서 필요한 클록들은 상기 명령어 페치 레이턴시와 부합한다. 이는 비-분기 시나리오에서, 상기 명령어 페치 레이턴시가 숨겨지는 것을 보장한다. 메모리로부터 명령어 캐시-라인을 수신하면, 그것은 프리-디코딩된다. 비조건적인 분기 명령어라면) 현재 페치되며, 다음 명령어 캐시-라인에 대한 페치는 분기 명령어 포인터로부터 발행된다. 조건적인 분기 명령이 존재하면, 다음 명령어 캐시-라인을 페치하는 것은 상기 분기가 해소될 때까지 연기된다. 다중의 스레드들이 존재하기 때문에, 이 메커니즘은 효율의 감소의 결과가 되지 않는다.
상기 명령어 캐시-라인을 프리-디코딩할 때에, 추출된 정보의 다른 조각은 메모리로부터 요청된 모든 데이터 오퍼랜드들에 관한 것이다. 이 데이터 오퍼랜드들 모두에 대한 메모리 페치는 이 포인트에서 발행된다.
비디오 프로세싱 (Video Processing)
도 12는 비디오 프로세싱 시스템에서 비디오 인코딩의 도면을 보여준다. 완전하게 프로그램 가능한 다중-스레드 비디오 프로세싱 엔진이 디코드/인코드/트랜스코드 및 다른 비디오 포스트-프로세싱 (post-processing) 연산들을 수행하기 위해서 구현된다. 비디오 프로세싱은 비트-스트림들을 분석하고 그리고 픽섹들의 블록들에 대한 계산들을 포함한다. 프레임 내 다중 블록들이 존재하는 것은 효율적인 멀티-스레드 프로세싱을 가능하게 한다. 모든 블록 계산들은 SIMD 방식으로 수행된다. SIMD 프로세싱으로부터의 최대 이점을 실현하기 위한 주요 사항은 상기 SIMD 엔진을 위한 적절한 폭을 설계하고 그리고 그 엔진이 필요로 하는 데이터를 그 엔진에게 공급하기 위한 하부구조를 또한 제공하는 것이다. 이 데이터는, 온-칩 레지스터들 또는 메모리 내 버퍼들로부터의 데이터일 수 있는 오퍼랜드들과 함께 상기 명령어들을 포함한다.
비디오 디코딩 - 스트림 특성들 & 스트림 마커 아이디 (identification)에 대한 고-레벨의 분석을 포함하며, 마커들 사이의 비트-스트림 데이터의 가변-길이 분석이 이어진다. 이는 빠른 분석을 위한 특별한 명령어들을 갖춘 프로그램 가능 프로세서 내에서 구현된다. 이어지는 수학적인 연산들 (역 양자화 (Inverse Quantization), IDCT, 움직임 보상 (Motion Compensation), 디-블로킹 (De-blocking), 디-링잉 (De-ringing))을 위해서, 바이트 & 워드 오퍼랜드들에 관한 연산들을 가속하기 위한 바이트 엔진이 정의되었다.
비디오 인코딩 - 움직임 추정은 고-밀도 SAD4x4 명령어를 이용하여 최선의 부합을 결정하기 위하여 수행된다 (소스 내 네 개의 4x4 블록들 각각은 레퍼런스 내 16개의 상이한 4x4 블록들에 대비하여 비교된다). DCT, 양자화 그리고 상기 바이트 엔진에서 수행되는 비디오 디코딩이 이어진다. 이어지는 가변-길이-코딩은 특별한 비트-스트림 인코딩 및 패킹 명령어들을 이용하여 수행된다.
비디오 트랜스코딩 - 디코딩 및 인코딩을 위해서 정의된 기술들의 조합을 이용한다.
비디오 포스트-프로세싱 (Video post-processing)
도 13은 비디오 프로세싱 시스템 내에서의 비디오 포스트-프로세싱의 도면을 보여준다. 여러 포스트-프로세싱 알고리즘들은 수평 및 수직 방향에서 픽셀들을 필터링하는 것을 포함한다. 메모리 그리고 온-칩 레지스터들 내 그 메모리의 조직으로부터 픽셀 데이터를 페치하는 것은 양 방향들에서 데이터에 효율적으로 액세스하는 것을 가능하게 한다. 상기 필터링은 여러 형상들 (수평, 양방향, 사각형, 수직)에서 도트-프로덕트 명령어들 (dp5, dp9 & dp 16)을 이용하여 수행된다.
분기 기술 (Branch technique)
도 14는 분기 기술의 흐름도를 보여준다. SIMD (하나의 그룹 내 다중 스레드들) 방식으로 프로그램들을 프로세싱할 때에, 상기 그룹 내 상이한 스레드들이 프로그램에서 상이한 경로들을 취하는 시나리오들이 나타난다. SIMD 엔진에서 조건적인 그리고 비조건적인 두 가지 모두의 분기들을 처리하기 위한 간단한 그리고 저렴한 방식이 여기에서 설명된다.
실행 명령어 포인터 (instruction pointer (IP))는 상기 그룹 내 각 스레드 용의 플래그 비트와 함께 유지된다. 상기 플래그는 그 스레드가 동일한 흐름 내에 현재의 실행으로서 존재하며, 그러므로 스스로의 플래그 세트를 가진 스레드들에 대해서만 실행이 일어난다는 것을 표시한다. 상기 플래그는 실행의 시작 부분에서 모든 스레드들에 대해 세팅된다. 조건적인 분기 때문에, 스레드가 현재의 실행 코드 경로를 취하지 않으면, 그것의 플래그는 턴 오프되며 그리고 그것의 실행 IP는 그것이 이동할 필요가 있는 포인터로 세팅된다. 병합 포인트들에서, 플래그들이 턴 오프된 스레드들의 실행 IP는 현재의 실행 IP와 비교된다. 그 IP들이 부합하면, 상기 플래그가 세팅된다. 분기 포인트들에서, 모든 현재의 활성 스레드들이 분기를 취하면, 현재의 실행 IP는 모든 스레드들 중에서 가장 가까운 (현재의 실행 IP로부터 최소의 포지티브 델타인) 실행 IP로 세팅된다.
프로그램 가능한 출력 병합기 (Programmable Output Merger)
도 15는 프로그램 가능한 출력 병합기의 흐름도를 보여준다. 3D 그래픽 API (openGL, DirectX)는 상기 도면에 보이는 것처럼 프로세싱 파이프라인을 정의한다. 대개의 파이프라인 스테이지 (stage)들은 적절한 엔트리들 (버텍스들/폴리곤들/픽셀들) 상에서 동작하는 프로그램들인 셰이더 (shader)들로서 정의된다. 각 셰이더 스테이지는 이전의 스테이지로부터 (또는 메모리로부터) 입력들을 수신하며, 그 입력들을 프로세싱하기 위해 다른 입력 리소스들 (프로그램들, 상수들, 텍스쳐들 ...)을 이용하고 그리고 출력들을 다음의 스테이지로 배달한다. 프로세싱 동안에, 변수들의 임시 저장을 위해서 범용 레지스터들의 집합이 사용된다. 다른 스테이지들은 상태에 의해서 제어되는 고정-기능 블록들이다.
상기 API들은 전체 파이프라인을 정의하는 상태 모두를 다중의 그룹들로 분류한다. 하드웨어에서 이 상태 그룹들의 직교성 (orthogonality)을 유지하는 것은, 즉, 상기 상태 그룹들을 서로에게 독립적으로 보유하는 것은 드라이버 컴파일러에서의 종속성들을 제거하며 그리고 상태-없는 드라이버를 가능하게 한다.
상기 3D 파이프라인의 최종 스테이지들은 픽셀들 상에서 동작한다. 상기 픽셀들이 셰이드 (shade)된 이후에, 출력 병합기 상태는 그 픽셀 값들이 같이-위치한 프레임 버퍼 값들과 어떻게 블렌드되고/결합되는가를 정의한다.
우리의 프로그램 가능 출력 병합기에서, 이 상태는 픽셀 셰이더 실행 이전에 그리고 이후에 동작하는 서브루틴의 쌍으로 구현된다. 프리픽스 (prefix) 서브루틴은 프레임 버퍼 값들의 페치를 발행한다. 서픽스 (suffix) 서브루틴은 블렌드 (blend) 명령어들을 가진다. (범용 레지스터들 안에 생성된) 픽셀-셰이더 출력들은 (상기 프리픽스 서브루틴에 의해서 페치된) 프레임 버퍼 값들과 상기 서픽스 서브루틴에서 상기 블렌드 명령어들을 이용하여 결합될 필요가 있다. 상기 픽셀-셰이더 상태와 직교성을 유지하기 위해서, 상기 픽셀-셰이드 출력 레지스터들은 그처럼 태그되며 그리고 상기 서픽스 서브루틴에서 이 레지스터들에 액세스하기 위해서 CAM (Content Addressable Memory)이 사용된다.
레지스터 리매핑 (Register Remapping)
이것은 프로그램에서 사용된 레지스터들을 최적화/최소화하기 위한 컴파일러 기술이다. 셰이더 프로그램들에서 사용된 레지스터들의 리매핑을 수행하기 위해서, 밑에서-부터의 (bottoms-up) 접근 방식이 사용된다.
상기 프로그램은 고정된 크기의 명령어들을 이용하여 위에서-밑으로 (top-to-bottom) 미리-컴파일 (pre-compile)된다.
이 미리-컴파일된 프로그램은 그러면 밑에서-위로 (bottom-to-top) 분석된다. 레지스터 맵은 범용 레지스터들 (general purpose registers (GPR))을 위해서 유지되며, 이는 원래의 레지스터 번호 그리고 상기 리매핑된 레지스터 번호 사이의 매핑을 추적한다. 셰이더 프로그램들 내 레지스터들이 4-채널이기 때문에, 채널 인에이블 비트들 (channel enable bits) 또한 상기 레지스터 맵 내에서 추적된다.
출력 레지스터에 기여하지 않는 모든 명령어들은 제거된다.
레지스터가 명령어 내에서 소스로서 사용되고 그리고 상기 레지스터 맵에서는 발견되지 않을 때에, 그 레지스터는 사용되지 않은 레지스터로 리매핑되며 그리고 그것은 그 레지스터 맵에 놓여진다.
명령어 내에서 소스/목적지로서 사용된 레지스터가 상기 레지스터 맵에서 발견되면, 그것은 그에 따라서 다시 이름이 부여된다.
(GPR에 다시 이름이 부여된 이후에) GPR이 목적지 레지스터이면 그 GPR은 상기 레지스터 맵에서 제거되며 그리고 상기 레지스터 맵 내 모든 인에이블된 채널들은 (목적지 레지스터 마스크마다) 써진다.
일단 상기 밑에서-위로의 컴파일이 완료되면, 가변 길이 명령어들을 이용하기 위해서 상기 프로그램은 위에서-밑으로 한번 더 다시 컴파일될 수 있다. 또한, 인에이블된 채널들의 부분-집합만을 구비한 몇몇의 레지스터들은 하나의 단일 레지스터로 병합될 수 있다.
비록 특정의 실시예들이 설명되고 예시되었지만, 상기 설명된 실시예들은 그렇게 설명되고 그리고 예시된 부분들의 특정 형상들 또는 배치로 제한되는 것이 아니다. 상기 실시예들은 첨부된 청구항들에 의해서만 제한된다.

Claims (21)

  1. 전송을 위해서 서버 시스템의 그래픽 데이터를 선택하는 방법으로서:
    상기 서버 시스템의 그래픽 메모리로부터 데이터를 읽는 단계;
    상기 데이터가 처음으로 읽혀지고 있는가를 체크하는 단계;
    그래픽 렌더링 동안에 상기 서버 시스템의 프로세서에 의해 상기 데이터가 써졌는가를 체크하는 단계로, 상기 데이터가 클라이언트 시스템 상에서 이용가능한가 또는 전송 버퍼 내에 존재하는가를 체크하는 단계를 포함하는 체크 단계;
    상기 데이터가 처음으로 읽혀지고 있는가의 상기 체크에 의해 판별되듯이 상기 데이터가 처음으로 읽혀지고 있다면, 그리고 그래픽 렌더링 동안에 상기 서버 시스템의 프로세서에 의해 상기 데이터가 써졌는가의 상기 체크에 의해 판별되듯이 그래픽 렌더링 동안에 상기 서버 시스템의 프로세서에 의해서 써지지 않았다면, 상기 데이터를 전송 버퍼 내에 놓아두는 단계로, 상기 데이터가 처음으로 읽혀지고 있고 그리고 그래픽 렌더링 동안에 상기 서버 시스템의 프로세서에 의해 써졌다면 상기 데이터는 상기 전송 버퍼 내에 놓이지 않으며, 그리고 상기 데이터는 그래픽 및 명령 데이터의 부분집합을 포함하며, 그리고 상기 그래픽 렌더링은 3차원 씬 (scene) 데이터를 기반으로 하여 2차원 이미지를 산출하는 프로세스를 포함하는, 단계; 그리고
    상기 전송 버퍼의 상기 데이터를 상기 클라이언트 시스템으로 전송하는 단계를 포함하는 방법.
  2. 제1항에 있어서,
    상기 프로세서는 중앙 프로세싱 유닛 (CPU) 및 그래픽 프로세싱 유닛 (GPU) 중 적어도 하나를 포함하며,
    상기 방법은,
    상기 GPU가 프레임 버퍼의 데이터를 압축하고 그리고 압축된 프레임 버퍼에 배치하는 것을 제어하고, 그리고
    상기 클라이언트 시스템으로의 전송을 위해서 상기 GPU가 상기 압축된 프레임 버퍼의 압축된 그래픽 데이터 또는 상기 전송 버퍼의 데이터 중 어느 하나를 선택하는 것을 제어하는 것을 더 포함하는, 방법.
  3. 제1항에 있어서,
    상기 데이터가 처음으로 읽혀지고 있는 것인지를 판별하는 것은 적어도 하나의 제1 상태-비트를 체크하는 것을 포함하는, 방법.
  4. 제3항에 있어서,
    상기 적어도 하나의 제1 상태-비트는 데이터가 상기 전송 버퍼 내에 놓일 때에 세팅되는, 방법.
  5. 제4항에 있어서,
    상기 적어도 하나의 제1 상태-비트는 상기 그래픽 메모리의 다이렉트 메모리 액세스 (DMA) 또는 상기 그래픽 메모리의 재할당 중 적어도 하나를 탐지하면 리셋되는, 방법.
  6. 제1항에 있어서,
    상기 데이터가 상기 프로세서에 의해서 써지지 않았다는 것을 판별하는 것은 적어도 하나의 제2 상태-비트를 체크하는 것을 포함하는, 방법.
  7. 제6항에 있어서,
    상기 적어도 하나의 제2 상태-비트는 상기 프로세서가 상기 그래픽 메모리에 쓸 때에 세팅되는, 방법.
  8. 제7항에 있어서,
    상기 제2 상태-비트는 상기 그래픽 메모리의 다이렉트 메모리 액세스 (DMA) 또는 상기 그래픽 메모리의 재할당 중 적어도 하나를 탐지하면 리셋되는, 방법.
  9. 제1항에 있어서,
    상기 데이터는 복수의 블록들을 포함하며, 그리고 상기 데이터가 처음으로 읽혀지고 있는가를 판별하는 것은 적어도 하나의 블록에 대응하는 적어도 하나의 상태-비트를 체크하는 것을 포함하는, 방법.
  10. 제1항에 있어서,
    상기 그래픽 메모리의 프레임 버퍼의 데이터를 압축하는 단계를 더 포함하는, 방법.
  11. 제10항에 있어서,
    상기 서버 시스템과 상기 클라이언트 시스템 사이 링크의 대역폭, 그리고 상기 클라이언트 시스템의 기능들 중 적어도 하나를 체크하는 단계를 더 포함하며,
    상기 서버 시스템은 상기 압축된 프레임 버퍼 데이터 또는 전송 버퍼의 데이터 중 적어도 하나를, 상기 링크의 상기 대역폭 그리고 상기 클라이언트 시스템의 상기 기능들 중 적어도 하나를 적어도 부분적으로 기반으로 하여 전송하는, 방법.
  12. 제11항에 있어서,
    상기 대역폭 그리고 상기 기능들을 체크하는 것은 프레임 단위 (frame-by-frame) 기반으로 수행되는, 방법
  13. 제11항에 있어서,
    상기 프레임 버퍼의 데이터를 프레임 단위 기반으로 압축하는가의 여부를 결정하고, 그리고
    상기 데이터의 적어도 일부를 매 프레임마다 상기 전송 버퍼에 놓아두는 것을 더 포함하는, 방법.
  14. 제1항에 있어서,
    상기 서버 시스템으로부터 수신된 압축된 비디오를 상기 클라이언트 시스템이 압축 해제하는 것을 허용하기 위해서 상기 서버 시스템이 상기 클라이언트 시스템으로 레퍼런스 프레임을 제공하는 단계 그리고
    심지어 상기 레퍼런스 프레임이 무손실 (lossless)일 때에 프레임 버퍼의 데이터의 이후의 압축을 위해서 상기 레퍼런스 프레임을 유지하는 단계를 더 포함하는, 방법.
  15. 전송을 위해서 그래픽 데이터를 선택하는 시스템으로서:
    프로세서 및 그래픽 메모리를 포함한 서버 시스템을 포함하며, 상기 그래픽 메모리는 프레임 버퍼 및 전송 버퍼를 포함하며, 상기 서버 시스템은:
    상기 그래픽 메모리로부터 데이터를 읽도록 동작 가능하며;
    상기 데이터가 처음으로 읽혀지고 있는가를 체크하도록 동작 가능하며;
    그래픽 렌더링 동안에 상기 서버 시스템의 프로세서에 의해 상기 데이터가 써졌는가를 체크하도록 동작 가능하며 - 상기 데이터가 클라이언트 시스템 상에서 이용가능한가 또는 전송 버퍼 내에 존재하는가를 체크하는 것을 포함한다 -;
    상기 데이터가 처음으로 읽혀지고 있는가의 상기 체크에 의해 판별되듯이 상기 데이터가 처음으로 읽혀지고 있다면, 그리고 그래픽 렌더링 동안에 상기 서버 시스템의 프로세서에 의해 상기 데이터가 써졌는가의 상기 체크에 의해 판별되듯이 그래픽 렌더링 동안에 상기 서버 시스템의 프로세서에 의해서 써지지 않았다면, 상기 데이터를 전송 버퍼 내에 놓아두도록 동작 가능하며, 상기 데이터가 처음으로 읽혀지고 있고 그리고 그래픽 렌더링 동안에 상기 서버 시스템의 프로세서에 의해 써졌다면 상기 데이터는 상기 전송 버퍼 내에 놓이지 않으며, 그리고 상기 데이터는 그래픽 및 명령 데이터의 부분집합을 포함하며, 그리고 상기 그래픽 렌더링은 3차원 씬 (scene) 데이터를 기반으로 하여 2차원 이미지를 산출하는 프로세스를 포함하는, 시스템.
  16. 제15항에 있어서,
    상기 프로세서는 중앙 프로세싱 유닛 (CPU) 및 그래픽 프로세싱 유닛 (GPU) 중 적어도 하나를 포함하며,
    상기 GPU는 상기 프레임 버퍼의 데이터를 압축하고 그리고 압축된 프레임 버퍼에 배치하는 것을 제어하고, 그리고
    상기 GPU는 클라이언트 시스템으로의 전송을 위해서 상기 압축된 프레임 버퍼의 압축된 그래픽 데이터 또는 상기 전송 버퍼의 데이터 중 어느 하나를 선택하는 것을 제어하는, 시스템.
  17. 제16항에 있어서,
    상기 시스템은 상기 서버 시스템에 링크된 클라이언트 시스템을 더 포함하며,
    상기 클라이언트 시스템은 적어도 하나의 프로세서 및 클라이언트 그래픽 메모리를 포함하며,
    상기 GPU는 상기 데이터의 데이터 헤더 내 정보를 기반으로 하여 상기 클라이언트 그래픽 메모리의 프레임 버퍼 내에 상기 데이터를 놓기 위해서 상기 데이터를 렌더링하는지 또는 상기 데이터를 압축 해제하는지를 결정하는, 시스템.
  18. 제15항에 있어서,
    상기 서버 시스템은 상기 프레임 버퍼의 데이터를 압축하도록 동작할 수 있는, 시스템.
  19. 제18항에 있어서,
    상기 서버 시스템과 클라이언트 시스템 사이 링크의 데이터 대역폭에 종속하여 상기 전송 버퍼의 상기 데이터 또는 상기 프레임 버퍼의 상기 압축된 데이터를 전송하는 사이에서 선택하도록 상기 서버 시스템이 동작할 수 있는 것을 더 포함하는, 시스템.
  20. 제19항에 있어서,
    클라이언트 시스템의 기능들에 종속하여 상기 전송 버퍼의 상기 데이터 또는 상기 프레임 버퍼의 상기 압축된 데이터를 전송하는 사이에서 선택하도록 상기 서버 시스템이 동작할 수 있는 것을 더 포함하며,
    상기 서버 시스템은 클라이언트 시스템에 링크된, 시스템.
  21. 제1항에 있어서,
    상기 전송 버퍼의 할당된 크기는 상기 서버 시스템과 상기 클라이언트 시스템 사이 링크의 대역폭을 적어도 기반으로 하여 적응적으로 결정되는, 방법.
KR1020147001108A 2011-06-16 2011-12-14 전송을 위한 서버 시스템의 그래픽 데이터 프로세싱 KR101898565B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13/161,547 US8754900B2 (en) 2010-06-17 2011-06-16 Processing of graphics data of a server system for transmission
US13/161,547 2011-06-16
PCT/US2011/064992 WO2012173650A1 (en) 2011-06-16 2011-12-14 Processing of graphics data of a server system for transmission

Publications (2)

Publication Number Publication Date
KR20140079350A KR20140079350A (ko) 2014-06-26
KR101898565B1 true KR101898565B1 (ko) 2018-09-13

Family

ID=45328222

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020147001108A KR101898565B1 (ko) 2011-06-16 2011-12-14 전송을 위한 서버 시스템의 그래픽 데이터 프로세싱

Country Status (4)

Country Link
US (1) US8754900B2 (ko)
KR (1) KR101898565B1 (ko)
GB (1) GB2510056B (ko)
WO (1) WO2012173650A1 (ko)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8745173B1 (en) 2011-12-30 2014-06-03 hopTo Inc. Client computing system for and method of receiving cross-platform remote access to 3D graphics applications
US20170365237A1 (en) * 2010-06-17 2017-12-21 Thincl, Inc. Processing a Plurality of Threads of a Single Instruction Multiple Data Group
US9373152B2 (en) * 2010-06-17 2016-06-21 Thinci, Inc. Processing of graphics data of a server system for transmission including multiple rendering passes
US9600350B2 (en) * 2011-06-16 2017-03-21 Vmware, Inc. Delivery of a user interface using hypertext transfer protocol
US9378560B2 (en) * 2011-06-17 2016-06-28 Advanced Micro Devices, Inc. Real time on-chip texture decompression using shader processors
US8766990B1 (en) 2011-12-30 2014-07-01 hopTo Inc. Server computing system for and method of providing cross-platform remote access to 3D graphics applications
US8769052B1 (en) 2011-12-30 2014-07-01 hopTo Inc. Cloud-based server computing system for and method of providing cross-platform remote access to 3D graphics applications
US9420322B2 (en) * 2012-03-14 2016-08-16 Time Warner Cable Enterprises Llc System and method for delivering compressed applications
US9858052B2 (en) * 2013-03-21 2018-01-02 Razer (Asia-Pacific) Pte. Ltd. Decentralized operating system
CN105190530B (zh) * 2013-09-19 2018-07-20 思杰系统有限公司 传输硬件渲染的图形数据
US20150220293A1 (en) * 2014-01-31 2015-08-06 LEAP Computing, Inc. Systems and methods for performing graphics processing
US9704270B1 (en) 2015-07-30 2017-07-11 Teradici Corporation Method and apparatus for rasterizing and encoding vector graphics
US10460513B2 (en) * 2016-09-22 2019-10-29 Advanced Micro Devices, Inc. Combined world-space pipeline shader stages
JP6809249B2 (ja) * 2017-01-23 2021-01-06 コニカミノルタ株式会社 画像表示システム
US10319063B2 (en) * 2017-02-24 2019-06-11 Ati Technologies Ulc System and method for compacting compressed graphics streams for transfer between GPUs
KR102136699B1 (ko) 2018-10-24 2020-07-22 한국건설기술연구원 3d 침수 정보 표출 장치 및 방법
US10981059B2 (en) * 2019-07-03 2021-04-20 Sony Interactive Entertainment LLC Asset aware computing architecture for graphics processing

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6195391B1 (en) * 1994-05-31 2001-02-27 International Business Machines Corporation Hybrid video compression/decompression system
US5758342A (en) * 1995-01-23 1998-05-26 International Business Machines Corporation Client server based multi-processor file system wherein client files written to by a client processor are invisible to the server
US6624761B2 (en) 1998-12-11 2003-09-23 Realtime Data, Llc Content independent data compression method and system
CA2301996A1 (en) 2000-03-13 2001-09-13 Spicer Corporation Wireless attachment enabling
EP1301041A1 (en) 2001-10-05 2003-04-09 Matsushita Electric Industrial Co., Ltd. Video data transmission method and apparatus
KR100422252B1 (ko) 2001-12-20 2004-03-11 삼성전자주식회사 씬 클라이언트 네트워크 시스템과 그 네트워크 시스템의데이터 전송 방법
EP1527613B1 (en) 2002-07-31 2014-09-10 Koninklijke Philips N.V. Method and apparatus for encoding a digital video signal
US7242400B2 (en) * 2002-11-13 2007-07-10 Ati Technologies Ulc Compression and decompression of data using plane equations
US7076735B2 (en) * 2003-07-21 2006-07-11 Landmark Graphics Corporation System and method for network transmission of graphical data through a distributed application
KR20050114047A (ko) 2004-05-31 2005-12-05 삼성전자주식회사 원격지에 소재하는 다수의 클라이언트들을 지원하는 방법및 서버
US8274909B2 (en) * 2009-03-26 2012-09-25 Limelight Networks, Inc. Conditional protocol control
GB0716158D0 (en) * 2007-08-17 2007-09-26 Imagination Tech Ltd Data compression
US8150175B2 (en) * 2007-11-20 2012-04-03 General Electric Company Systems and methods for image handling and presentation
US20110047476A1 (en) * 2008-03-24 2011-02-24 Hochmuth Roland M Image-based remote access system
JP2009290552A (ja) 2008-05-29 2009-12-10 Fujifilm Corp 動画圧縮装置および動画圧縮プログラム
US8441494B2 (en) * 2009-04-23 2013-05-14 Vmware, Inc. Method and system for copying a framebuffer for transmission to a remote display
GB0916924D0 (en) 2009-09-25 2009-11-11 Advanced Risc Mach Ltd Graphics processing systems
NO331356B1 (no) 2009-10-16 2011-12-12 Cisco Systems Int Sarl Fremgangsmater, dataprogrammer og anordninger for koding og dekoding av video
KR20110060181A (ko) 2009-11-30 2011-06-08 한국전자통신연구원 무손실/준무손실 영상 압축 장치 및 방법
US9519728B2 (en) 2009-12-04 2016-12-13 Time Warner Cable Enterprises Llc Apparatus and methods for monitoring and optimizing delivery of content in a network
CN102741830B (zh) 2009-12-08 2016-07-13 思杰系统有限公司 用于多媒体流的客户机侧远程呈现的系统和方法

Also Published As

Publication number Publication date
US8754900B2 (en) 2014-06-17
GB2510056A (en) 2014-07-23
US20110310105A1 (en) 2011-12-22
KR20140079350A (ko) 2014-06-26
WO2012173650A1 (en) 2012-12-20
GB2510056B (en) 2017-12-27
GB201322404D0 (en) 2014-02-05

Similar Documents

Publication Publication Date Title
KR101898565B1 (ko) 전송을 위한 서버 시스템의 그래픽 데이터 프로세싱
US11847719B2 (en) Apparatus and method for managing data bias in a graphics processing architecture
EP3385838B1 (en) Apparatus and method for remote display and content protection in a virtualized graphics processing environment
US10387992B2 (en) Apparatus and method for dynamic provisioning, quality of service, and prioritization in a graphics processor
US20170365237A1 (en) Processing a Plurality of Threads of a Single Instruction Multiple Data Group
US9892053B2 (en) Compaction for memory hierarchies
US9640150B2 (en) Selecting data of a server system for transmission
US11354769B2 (en) Page faulting and selective preemption
US20170178277A1 (en) Specialized code paths in gpu processing
US9996892B2 (en) Apparatus and method for efficient graphics processing in a virtual execution environment
CN108369748B (zh) 用于光线追踪架构中的负载平衡的方法和装置
US20200371804A1 (en) Boosting local memory performance in processor graphics
US11341212B2 (en) Apparatus and method for protecting content in virtualized and graphics environments
WO2016171817A1 (en) Optimized depth buffer cache apparatus and method
WO2017166272A1 (en) Method and apparatus of periodic snapshotting in graphics processing environment
US9830676B2 (en) Packet processing on graphics processing units using continuous threads

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right