发明内容
本发明要解决的技术问题在于,针对现有技术的上述开销较大、负载不平衡的缺陷,提供一种开销较小、负载较平衡的实现中央处理器和图形处理器功能的多线程处理器及方法。
本发明解决其技术问题所采用的技术方案是:构造一种实现中央处理器和图形处理器功能的多线程处理器,包括:
图形固定功能处理模块:用于图形处理中数据的固定功能处理;
多线程并行中央处理模块:用于通过统一的线程调度实行中央处理功能和图形处理中的可编程处理功能,并将已经过所述可编程处理功能的图形数据通过存储模块与所述图形固定功能处理模块进行交互;
存储模块:用于为所述图形固定功能处理模块和多线程并行中央处理模块提供统一的储存空间进行数据的存储、缓冲或/和交互。
在本发明所述的多线程处理器中,所述图形固定功能处理模块为单独的、通过所述存储模块与所述多线程并行中央处理模块交换数据的ASIC。
在本发明所述的多线程处理器中,所述图形数据可编程处理包括对图形数据进行顶点渲染和/或像素渲染;所述图形固定功能处理模块通过L2缓存与所述多线程并行中央处理模块连接。
在本发明所述的多线程处理器中,所述图形固定功能处理模块还通过设置在所述多线程并行中央处理模块内的中断控制接口接受所述多线程并行中央处理模块的控制或向所述多线程并行中央处理模块发出中断请求。
在本发明所述的多线程处理器中,所述多线程并行中央处理模块为多线程虚拟通道处理器。
在本发明所述的多线程处理器中,所述多线程虚拟通道处理器包括两个并行的多线程虚拟通道处理内核。
在本发明所述的多线程处理器中,每个所述多线程虚拟通道处理内核包括:
并行的多个线程处理引擎:用于处理被分配给该线程处理引擎的任务或线程;
线程控制器:用于取得、判断和控制所述多个线程处理引擎的状态,将处于等待队列中的线程或任务分配到所述多个线程处理引擎中;
本地存储区域:用于存储所述线程处理引擎处理的数据,配合所述线程处理引擎完成数据处理。
寄存器:用于数据及线程缓冲、指令缓冲的内部存储系统以及用于存储所述并行处理器的各种状态。
在本发明所述多线程处理器中,所述线程处理引擎包括算术逻辑运算单元以及与所述算术逻辑运算单元对应的乘加器;所述本地存储区域包括多个本地存储单元,所述本地存储单元在所述线程处理引擎工作时被配置对应于所述线程处理引擎。
本发明还揭示了一种实现中央处理器和图形处理器功能的数据处理方法,包括如下步骤:
A)执行图形处理主运用程序及同时继续其他中央处理运用程序;
B)图形处理主运用程序产生多个任务或数据
C)将要处理的图形数据或任务和其他中央处理应用程序分配到多个内核(Kernel)中,建立内核队列;
D)判断内核是否准备好?如是,执行下一步骤;否则,重复本步骤;
E)判断运行所述的线程资源是否准备好?如是,实例化内核并执行下一步骤,否则,重复本步骤;
F)对所述数据或任务进行可编程功能处理。
在本发明所述的方法中,其图形处理特征在于,还包括如下步骤:
F)将已经经过所述可编程功能处理的图形数据进行固定功能处理;
或G)将已经经过所述固定功能处理的图形数据进行可编程功能处理。
在本发明所述的方法中,可编程功能处理包括顶点渲染和/或像素渲染;所述固定功能处理包括点阵化、纹理和光栅操作。
在本发明所述的方法中,步骤C)中进一步包括:
C1)将待处理的图像数据分配到空闲的内核,并配置处理所述内核中图形数据的渲染器;
C2)排列所述内核使其成为待处理的内核队列。
在本发明所述的方法中,所述步骤D)进一步包括:
D1)判断是否有空闲的线程资源,如无,重复本步骤;如有,执行下一步骤;
D2)将所述队列中的内核配置到所述线程资源中,并使其开始运行。
在本发明所述的方法中,图形数据固定功能处理部分为独立于所述处理器内核、并通过处理器的L2缓存与所述处理器内核连接的硬件结构。
在本发明所述的方法中,步骤G进一步包括:
G1)将已经通过可编程功能处理的图形数据发送到L2缓存中;
G2)图形数据固定功能处理部分由所述L2缓存中读取数据并处理。
在本发明所述的方法中,所述步骤H)中,通过图形数据固定功能处理部分对所述处理器发出中断信号,使得其读取L2缓存中的数据的方式将图形数据传送到处理器中进行可编程功能处理。
实施本发明的实现中央处理器和图形处理器功能的多线程处理器及方法,具有以下有益效果:由于在单个处理器架构上实现了CPU及GPU的功能,因此其硅片使用面积使用面积均较小;同时,由于GPU的可编程功能是通过与CPU处理数据的线程处理方式实现的,而在CPU处理数据是使用多个并行的MVP(MultithreadVirtualPipeline)核,每个MVP核中有包括多个并行的线程处理引擎,因此可以在多个线程处理引擎之间实现负载平衡。
具体实施方式
下面将结合附图对本发明实施例作进一步说明。
如图1所示,在本发明实现中央处理器和图形处理器功能的多线程处理器及方法实施例中,该多线程处理器包括图形固定功能处理模块11、多线程并行中央处理模块和存储模块;在图1中多线程并行中央处理模块包括两个MVP(MultithreadVirtualPipeline)核,即MVP012和MVP113;而存储模块包括图1中的L2缓存14和DDR215,这些存储器通过总线与上述图形固定功能处理模块11及多线程并行处理模块连接,用于为图形固定功能处理模块11和多线程并行中央处理模块提供统一的储存空间进行数据的存储、缓冲或/和交互;而图形固定功能处理模块11用于图形处理中数据的固定功能处理;多线程并行中央处理模块则用于通过统一的线程调度实现程序处理功能和图形处理中的数据的可编程处理功能,并将已经过可编程处理功能的图形数据通过存储模块(具体来讲,是通过L2缓存14)与图形固定功能处理模块11进行交互。
在本实施例中,上述图形固定功能处理模块11是独立于上述MVP核(12、13)的硬件结构。也就是说,图形固定功能处理模块11是外挂在MVP核上的ASIC,由于图形固定功能处理模块11的功能较为固定,其电路结构相对而言较为成熟,在处理的过程中需要的计算量也不大,因此一个单独的ASIC较为实用。在本实施中,上述图形固定处理模块11通过总线AHB3与L2缓存14连接,而L2缓存14由通过总线分别与MVP012和MVP113连接,这样,不管在上述两个MVP核中执行图形数据的可编程功能处理,都可以和上述图形固定功能处理模块11之间实现数据的交换。此外,上述图形固定功能处理模块11还分别与系统总线和DDR215连接,便于取得输出和输入数据。而上述两个MVP核同样分别与L2缓存14和系统总线连接。
在本实施例中,图形数据的固定功能处理包括点阵化、纹理和光栅操作等处理过程;而图形数据的可编程功能处理则主要包括对数据的顶点渲染和像素渲染处理。对于可编程功能处理而言,是在上述两个MVP核中实现的,通过上述两个MVP核中的一个或多个线程,采用与处理程序或用户程序同样的方式,实现上述图形可编程功能的处理;当完成上述可编程功能处理后需要对图形数据进行固定功能处理时,将数据写入L2缓存14并通知上述图形固定功能处理模块11,图形固定功能处理模块11读取数据并采取要求的处理措施,之后将数据输出或送回MVP核中的线程进行后续的处理。
图2示出了一个MVP核的具体的结构。如图2所示,在一个MVP核中,包括多线程并行流数据处理单元21、线程控制器22、系统总线接口23、DMA(动态内存存取控制器)24、本地存储器25、数据缓存26、指令缓存27、MMU(MemoryManagementUnit,内存管理单元)28以及中断控制器29;其中,多线程并行流数据处理单元21用于处理被分配给该处理单元的任务或数据线程;多线程并行流数据处理单元21中包括多个并行的线程处理引擎,这些线程处理引擎运行被分配到其中的线程或任务的一部分;当一个线程运行完成之后,运行该线程的线程处理引擎被释放,之后,另外一个线程被分配到该线程处理引擎运行。线程控制器22用于取得、判断和控制所述多个线程处理引擎的状态,将处于等待队列中的线程或任务分配到上述多个线程处理引擎中;本地存储区域用于存储上述线程处理引擎处理的数据,配合上述线程处理引擎完成数据处理;本地存储区域有多个本地存储器组成。在本实施例中,本地存储器被配置到各个线程处理引擎。在每次处理不同数据时,改变该线程处理引擎配置的本地存储区域即可,不需要对存储在不同本地存储区域中的数据作出实际的移动。此外,MVP核中还包括寄存器,寄存器用于数据及线程缓冲、指令缓冲的内部存储系统以及用于存储所述并行处理器的各种状态。在本实施例中,寄存器包括数据缓存26、指令缓存27、MMU28、中断控制器29以及DMA24;
在本实施例中,上述线程处理引擎包括算术逻辑运算单元以及与所述算术逻辑运算单元对应的乘加器;本地存储区域包括多个本地存储单元(即本地存储器),所述本地存储单元在所述线程处理引擎工作时被配置对应于所述线程处理引擎。总的来讲,上述MVP核及其内部的多线程并行流数据处理单元与中国专利号为:200910190339.1,名称为“并行处理器及其线程处理方法”,中国专利号为:200910188409.X,名称为“一种流数据处理方法及流处理器”这两件专利中的相应部分的结构是大致相同的。其处理数据的方法也是大致相同的。关于上述MVP核的具体结构和工作流程,可以参见上述两件专利的描述。在本申请中仅对上述MVP核做简单的描述。
图3示出了在本实施例中处理图形数据时其可编程功能与固定功能处理之间的接口结构示意图。在图3中,多个线程处理引擎分别与配置到其中的本地存储器连接;同时,有都与统一的渲染存储器31连接,这个渲染存储器31就是该处理器的L2缓存;同时,该渲染存储器31还分别与光栅处理单元ROP34、纹理处理单元TEX33以及栅格处理单元RAST32连接,而在本实施例中,上述光栅处理单元ROP34、纹理处理单元TEX33以及栅格处理单元RAST32分别为上述图形固定功能处理模块中的一部分。同时,上述L2缓存在处理程序数据时也要使用。由此可见,在本实施例所描述的处理器中,不管其执行的是CPU的功能还是GPU的功能,其使用的存储空间是统一的,没有分别的。这与传统的、同时具有CPU和GPU两个芯片的系统是完全不同的。
本实施例还揭示了一种在上述处理器中处理图形数据的方法,如图4所示,包括如下步骤:
步骤S41开始图形处理:在本实施例中,由于该处理器同时具有CPU和GPU的功能,因此,该处理器处理的任务(task)可以是通常情况下CPU处理的程序数据,也可以是通常情况下GPU处理的图形数据。当该任务是通常情况下CPU处理的程序数据时,该处理器按照上述两个专利所描述的方法处理,虽然其使用MVP核中的一系列特点来处理这些数据,但在一般的意义上来讲,还是没有超出CPU的处理方式;当该任务是通常情况下GPU处理的图形数据,则开始执行图形处理主程序,这个图形处理主程序在任务层面上来讲与CPU的处理程序相似,但是,在具体的步骤上,还是有所不同的。在本步骤中,进入图形处理主程序,使用OPENGLCALL调出OPENGL的渲染功能(或者叫渲染函数)。
步骤S42配置可编程处理功能:在本步骤中,对于在上述步骤中使用OPENGLCALL调出的OPENGL渲染功能进行配置,渲染功能也可以称为渲染器,渲染器包括顶点渲染器(vertexshader)和像素渲染器(pixelshader),分别用于对图形数据进行顶点渲染和像素渲染。这正是图形数据的可编程功能处理中最为重要的两个处理步骤。这些渲染器配置后将被发送到上述处理这些图形数据的线程处理引擎,指导或限制这些实行图形数据可编程功能处理的线程引擎如何处理分配到其中的数据。
步骤S43将数据分配到各内核中:在本步骤中,将一个任务中的数据分配为多个单元,使得分配后的数据单元可以被一个线程处理,这就形成了一个内核(kernel)。当然,也可能一个任务要处理的数据是流数据,正在不断的送来,这种情况下,同样需要将已经接收的数据分配到多个单元,这些单元中的数据正好可以填满一个本地存储器,使得这些本地存储器可以和空出的线程配合,实现图形数据的可编程处理功能。在本实施例中,上述图形数据的可编程处理过程实际上和CPU中处理用户程序时是一样的,如果将渲染器看做用户程序,则除了其调出的过程及经过处理的数据可能还需要进行固定功能处理之外,从方法上来讲,基本与CPU处理用户程序是一样的。值得一提的是,在本步骤中,如果任务的数据长度够长,在执行完步骤S49并将本次分配的数据处理完成之后,还需要返回本步骤,再次对任务未处理的数据分配,并重复下面的步骤,直到该任务完成为止。值得一提的是,中央处理器处理的数据也是像本步骤一样分配的或中央处理器在处理其传统意义上的数据或任务是也是具有本步骤的。换句话说,在本步骤中分配数据时并不管或考虑这些数据是由传统意义上的中央处理器(CPU)处理的,还是由传统意义上的图形处理器(GPU)处理的;仅仅是将其作为数据分配到内核中;同时还设置了如何处理这些数据,这正是如前所述的调用图形处理主程序;在处理CPU数据或任务时,仅仅是前面的调用的主程序不同。这正是本发明与传统意义上的CPU加GPU结构的一个不同之处。在本实施例中,仅仅是出于描述清楚的考虑,将GPU处理的图形数据单独列出步骤S41-S49来描述;而在实际运行时,上述传统意义上的CPU处理数据或任务和GPU处理的数据或任务并没有分开处理,而是混在一起处理的,其处理的过程也大致与步骤S41-S49相同,不同点仅仅在于,在处理CPU数据或任务时,调出的不是步骤S41、S42中的图形处理的主程序或配置内容,而是CPU数据或任务需要的程序或配置内容;而在处理之后也不用输送到图形固定功能模块去处理,而是做与其要求适应的处理。总之,在系统的角度而言,上述CPU和GPU处理的数据或任务是没有区别的,仅仅是处理时的方法(或调用的处理程序)不同而已。同时,由于系统线程的并行,使得系统中多个线程可以同时分别对传统意义上的CPU任务和GPU任务同时处理。
步骤S44排列内核形成队列:在本步骤中,将上述步骤得到的内核按照其数据先后顺序排成队列,等候处理。如果线程被建立且有空闲的线程引擎,则在本步骤中形成的内核队列中依次取出并处理这些内核。
步骤S45创建线程:在本步骤中,创建线程。所谓线程的建立就是将上面步骤中得到的内核及渲染器配置到空闲的线程引擎中,使得线程引擎可以按照设定的渲染功能对数据进行处理。
步骤S46内核准备好?在本步骤中,判断内核是否已经准备好,如是,执行下一步骤,否则,重复本步骤。在本步骤中,内核是否准备好的判断标准有两个,一个是判断输入到该内核的数据是否已经准备好,另外一个是该内核输出的存储空间是否已经准备好;当上面两个条件都满足时,认为该内核已经准备好;其中任何一个条件不满足,则认为该内核没有准备好。
步骤S47内核实例化:在本步骤中,将上述内核在线程引擎上实例化,也就是将上述渲染器和数据传输到上述被选中的线程引擎上,并使得其以可执行的方式存在于上述线程引擎中。
步骤S48线程资源准备好?在本步骤中,判断线程资源是否准备好,如准备好,执行下一步骤;否则,重复本步骤。在本实施例中,上述线程资源是否准备好,也就是该线程引擎是否配置好。
步骤S49开始图形可编程处理功能线程:在本步骤中,线程引擎开始执行配置好的线程,对图形数据进行定点渲染或像素渲染。在本实施例中,由于图形处理程序的不同,配置到内核中的图形数据需要进行的渲染也是不同,例如,在一些情况下,可能这些数据除了进行顶点渲染之外,还有进行像素渲染;而在另一些情况下,可能这些数据只需要进行顶点渲染或像素渲染。在需要进行两种渲染的情况下,本地存储单元会被另外配置到另一种渲染的线程中,进行另外一种渲染。
在执行完上述可编程功能的处理之后,如果需要进行图形数据的固定功能处理,将上述经过渲染处理的数据通过L2缓存发送到固定功能处理模块,使得这些数据可以进行固定功能的处理。在本实施例中,上述数据传递是通过Store指令来实现的。同样,如果数据在固定功能处理模块中处理后还需要配置到上述线程中,则上述固定功能处理模块将上述数据通过L2缓存送回并可通过中断的方式告诉上述线程
图5示出了在处理图形数据时,系统、图形处理主程序、渲染器、内核、线程以及固定功能处理模块之间的关系示意图。在图5中,示出了由操作系统到进入图形处理主程序、设置vs(顶点渲染)和ps(像素渲染)、将数据分配到多个内核、建立多个线程以及外接的图形数据固定功能处理模块之间的关系。在图5中,示出了8个内核(K0-K8)以及4个线程(Thr0-Thr3)用于处理图形数据,实现图形数据的可编程供功能。
图6示出了在本实施中,某一时刻上述两个MVP核所包含的8个线程引擎的工作情况,在图6中,线程0用于运行操作系统,线程1用于运行用户程序P0(即USERP0),而在该用户程序P0中,又使用了两个线程分别运行P0中的两个函数,其分别是线程3(USERP0K0)和线程5(USERP0K1),其中USERP0K0表示用户程序P0的第0个函数;USERP0K1表示用户程序P0的第1个函数;而线程2则用于3DrenderP1,也就是说,线程2用于运行图形处理的着色程序P1,同时,线程4、线程6和线程7分别用于程序P1中的顶点渲染中的第0个数据(P1VSK0);而线程6和线程7分别用于程序P1中的像素渲染中的第0个数据(P1PSQ0)和第1个数据(P1PSQ1)。由上面的描述可以看出,在本实施例中,不光是渲染器之间可以并行,而且在上述通常的用户程序和图形数据处理程序之间也是并行的。因此,由此可以看出,在上述MVP核中的8个线程引擎,可以在上述系统程序与图形处理程序之间可以达到较好的负载平衡。当然,图6只是示例性的表明线程引擎的工作状态。在其他实施例或本实施例的其他时刻,这8个线程引擎并不一定是这种工作状态,例如,可能8个引擎都在处理CPU的用户程序或GPU的图形用户程序等。
图7是本实施中一段时间内的用于3D处理的工作流程示意图。在图7中,示出了Time0-Time1314个时钟期间,4个线程引擎与上述内核队列及图形固定功能处理模块之间的相互之间的数据交换及动作流程。在图7中,处理器在相邻的时钟上并不一定处理同一个线程引擎上的动作,这就使得在处理器的角度来看,这些线程引擎的工作是并行的。在图7中:
在Time0时,Time0:launch3D-appmain,即线程0或线程引擎0开始3D运用主程序;
而在Time1时,Time1:instantiatek1,k2vsandk3,k4ps,即在线程0上,实例化需要进行vs的数据k1和k2,同时还实例化需要进行ps的数据k3和k4;
在Time2时,Time2:launchk1vsv0,也就是在线程1中,加载vs数据k1,并开始运算或处理;
在Time3时,Time3:launchk3psq0,也就是在线程2中,加载ps数据k3;
在Time4时,Time4:launvhk4psq1,在线程3中,加载ps数据k4;这些加载都是发生在各线程及内核队列之间;
在Time5时,Time5:k3psq0wait,线程2上的ps数据(k3psq0)开始等待;
在Time6时,Time6:launchk2vsv1,也就是在线程2上上载需要进行进行vs处理的数据k2,此时,由于k3等待,线程2空闲,所以开始加载另一个内核数据k2,并开始处理;
在Time7时,Time7:retr.texwakeupk3,固定功能处理模块发出中断请求,传回纹理处理的结果,并唤醒前面等待的内核k3;
在Time8时,Time8:k1exit,线程1中,内核k1处理完成并退出;
在Time9时,Time9:relaunchk3,由于在上面的时钟内数据k1退出,线程1空闲,所以在线程1上重新上载之前在线程2等待的数据k3,此处实现了在线程之间实时调度,使得每个线程引擎的负载可以动态地达到平衡。
在Time10时,Time10:k3exittowaitforretr.tex,在线程1上,数据k3退出,并等待固定功能处理模块的处理结果;
在Time11时,Tim11:k2exit,线程2中,处理完数据k2并退出;
在Time12时,Time12:k4exit,线程3中,处理完数据k4并退出;
在Time13时,Time13:mainexit,线程0中,整个3D-appmain处理完成并退出。
通过上面的描述,可以清楚地看到在一个图形运用处理程序中,是如何实通过线程引擎实现顶点渲染和像素渲染的,也可以看到多个内核是如何在多个线程引擎之间运作并达到动态负载平衡的,还可以看到图形的可编程功能处理部分与固定功能处理部分之间的数据传输是如何实现的。
以上所述实施例仅表达了本发明的几种实施方式,其描述较为具体和详细,但并不能因此而理解为对本发明专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干变形和改进,这些都属于本发明的保护范围。因此,本发明专利的保护范围应以所附权利要求为准。