CN105741227A - 渲染方法和装置 - Google Patents

Abstract

本发明公开了一种渲染方法和装置。其中，该方法包括：主线程将渲染命令发送给至少一个渲染线程，其中，主线程用于处理应用的逻辑，渲染命令为不依赖于应用的逻辑的渲染命令；至少一个渲染线程获取渲染命令，并根据渲染命令更新应用的画面。本发明解决了有技术中执行图形渲染和逻辑处理均在一个线程中进行所导致问题，提高了渲染效率。

Description

渲染方法和装置

技术领域

本发明涉及互联网领域，具体而言，涉及一种渲染方法和装置。

背景技术

现有技术提出了一种基于DirectX的多线程渲染技术，可以通过主线程渲染上一帧中帧线程检测到的可见性对象列表，通过与主线程同步的帧更新线程对当前帧中的对象进行更新，通过动态加载线程动态加载场景资源、模型资源、特效、OBJ文件和ANI文件，当有线程触发或唤醒时，通过监听网络服务器线程接收服务器发送过来的消息包并插入到消息队列中，供主线程处理。

但是由于目前大部分移动设备，例如iPhone、iPad、Android设备都不支持DirectX这一图形API，导致现有技术的多线程渲染技术无法应用于不支持DirectX的设备上。并且，在现有技术中，图形渲染和逻辑处理一般在一个者线程中进行处理，这样的处理方式会降低计算的并行度，渲染效率不高。

针对有技术中执行图形渲染和逻辑处理均在一个线程中进行所导致问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种渲染方法和装置，以至少解决有技术中执行图形渲染和逻辑处理均在一个线程中进行所导致问题。

根据本发明实施例的一个方面，提供了一种渲染方法，包括：主线程将渲染命令发送给至少一个渲染线程，其中，所述主线程用于处理应用的逻辑，所述渲染命令为不依赖于所述应用的逻辑的渲染命令；至少一个所述渲染线程获取所述渲染命令，并根据所述渲染命令更新所述应用的画面。

进一步地，所述方法还包括：加载线程进行输出输入IO读取操作。

进一步地，至少一个所述渲染线程中的每个渲染线程均对应一个上下文，其中，所述上下文用于保存渲染对应的信息，每个所述渲染线程对应的上下文共享一个资源组，所述资源组中包括渲染资源。

进一步地，所述方法还包括：建立至少一个上下文为所述主线程、和/或所述加载线程创建资源，其中，创建资源的所述至少一个上下文与每个所述渲染线程对应的上下文共享所述资源组。

进一步地，所述主线程将所述渲染命令发送给至少一个所述渲染线程包括：所述主线程将所述渲染命令发送到命令队列中；至少一个所述渲染线程获取所述渲染命令包括：至少一个所述渲染线程从所述命令队列中获取所述渲染命令。

进一步地，所述命令队列是使用环形缓冲RingBuffer来构建无锁的队列。

进一步地，判断是否具有多核处理器；在判断结果为是的情况下，建立所述主线程和至少一个所述渲染线程；在判断结果为否的情况下，建立同时执行渲染和所述应用的逻辑的一个线程。

根据本发明实施例的另一方面，还提供了一种渲染装置，包括：发送模块，位于主线程中，用于将渲染命令发送给至少一个渲染线程，其中，所述主线程用于处理应用的逻辑，所述渲染命令为不依赖于所述应用的逻辑的渲染命令；获取模块，位于至少一个所述渲染线程中，用于获取所述渲染命令，并根据所述渲染命令更新所述应用的画面。

进一步地，所述装置还包括：IO模块，位于加载线程中，用于进行输出输入IO读取操作。

进一步地，第一建立模块，用于为至少一个所述渲染线程中的每个渲染线程建立对应一个上下文，其中，所述上下文用于保存渲染对应的信息，每个所述渲染线程对应的上下文共享一个资源组，所述资源组中包括渲染资源。

进一步地，所述装置还包括：所述第一建立模块，还用于建立至少一个上下文为所述主线程、和/或所述加载线程创建资源，其中，创建资源的所述至少一个上下文与每个所述渲染线程对应的上下文共享所述资源组。

进一步地，所述发送模块，用于将所述渲染命令发送给至少一个所述渲染线程包括：所述主线程将所述渲染命令发送到命令队列中；所述获取模块，用于获取所述渲染命令包括：至少一个所述渲染线程从所述命令队列中获取所述渲染命令。

进一步地，所述命令队列是使用环形缓冲RingBuffer来构建无锁的队列。

进一步地，所述装置还包括：判断模块，用于判断是否具有多核处理器；第二建立模块，用于在判断结果为是的情况下，建立所述主线程和至少一个所述渲染线程；在判断结果为否的情况下，建立同时执行渲染和所述应用的逻辑的一个线程。

本发明实施例采用主线程将渲染命令发送给至少一个渲染线程，其中，所述主线程用于处理应用的逻辑，所述渲染命令为不依赖于所述应用的逻辑的渲染命令；至少一个所述渲染线程获取所述渲染命令，并根据所述渲染命令更新所述应用的画面。通过本发明解决了有技术中执行图形渲染和逻辑处理均在一个线程中进行所导致问题，提高了渲染效率。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的渲染方法的流程图；

图2是根据本发明实施例的可选的渲染方法的示意图；以及

图3是根据本发明实施例的渲染装置的结构框图；

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

下面，首先对本发明实施例中涉及的相关技术术语进行解释，以方便对本发明实施例的理解。

OpenGL：开放图形库(英语：OpenGraphicsLibrary，缩写为OpenGL)是个定义了一个跨编程语言、跨平台的应用程序界面(API)的规范，它用于生成二维、三维图像。这个接口由近三百五十个不同的函数调用组成，用来从简单的图形比特绘制复杂的三维景象。而另一种程序界面系统是仅用于MicrosoftWindows上的Direct3D。OpenGL常用于CAD、虚拟实境、科学可视化程序和电子游戏开发。

OpenGLES：OpenGLES(OpenGLforEmbeddedSystems)是OpenGL三维图形API的子集，针对手机、PDA和游戏主机等嵌入式设备而设计。该API由Khronos集团定义推广，Khronos是一个图形软硬件行业协会，该协会主要关注图形和多媒体方面的开放标准。

OpenGLShareGroup：OpenGL中的共享资源组，用于管理一系列OpenGL内部资源，包括贴图、顶点缓冲区等。

OpenGLContext：OpenGL中的设备上下文，其中保存了任意一个OpenGL实例中的所有状态。

在本实施例中提供了一种渲染方法，图1是根据本发明实施例的渲染方法的流程图，如图1所示，该方法包括如下步骤：

步骤S102，主线程将渲染命令发送给至少一个渲染线程，其中，主线程用于处理应用的逻辑，渲染命令为不依赖于应用的逻辑的渲染命令。

步骤S104，至少一个渲染线程获取渲染命令，并根据渲染命令更新应用的画面。

在上述步骤中，可以将图形渲染分发到独立的线程上执行，与主线程并行执行，提升计算并行度。

上述应用可以是游戏应用，例如网络游戏，手机游戏等，但不仅限于此，其他类型的应用也可以实现本发明上述实施例的目的。本发明以上述应用是手机游戏对本发明上述实施例进行说明。

图2是根据本发明实施例的可选的渲染方法的示意图，在一种可选的方案中，如图2所示，可以建立多个线程，其中一个线程作为主线程，其他至少一个线程作为渲染线程，主线程计算游戏第N帧画面的逻辑，第N+1帧画面的逻辑和第N+2帧画面的逻辑，并将不依赖与游戏逻辑上下文的渲染命令发送给渲染线程，渲染线程根据接收到的渲染命令更新游戏第N帧画面，第N+1帧画面和第N+2帧画面。

为了使IO读取操作不影响主线程的运行，在一个可选的实施例中，可以建立独立的用于进行IO读取操作的线程，可以称为加载线程。加载线程主要处理输入输出IO读取操作，例如，读入贴图文件/模型顶点数据等，然后调用OpenGLAPI创建对应的GPU(GraphicProcessingUnit的缩写，图形处理器)资源，例如贴图、顶点数据等。通过上述可选实施例，可以单独建立一个加载线程进行输入输出IO读取操作，不去阻塞主线程，或者渲染线程，从而进一步提升计算并行度，提升渲染效率。

在另一个可选实施例中，至少一个渲染线程中的每个渲染线程可以均对应一个上下文，该上下文用于保存渲染对应的信息。每个渲染线程对应的上下文共享一个资源组，资源组中包括渲染资源。通过该实施例，可以使渲染线程共享相同的资源，并且，由于使用了不同的上下文，还可以避免共享资源的冲突。上述渲染对应的信息可以是渲染状态等状态数据，但不仅限于此，其他类型的渲染信息也可以实现本发明上述实施例的目的，渲染资源可以是OpenGL的内部资源，例如贴图，顶点缓冲区等。

当然，也可以为主线程，和/或加载线程建立至少一个上下文，该至少一个上下文用于为主线程、和/或所述加载线程创建资源，该至少一个上下文可以与每个渲染线程对应的上下文共享资源组。通过上述方案，可以为主线程、和/或加载线程建立用于创建资源的至少一个上下文，并将该至少一个上下文与渲染线程对应的上下文共享同一个资源组，从而保证主线程、和/或加载线程加载的资源可以为渲染线程使用。

此处需要说明的是，不同于可以原生支持线程安全调用的DirectXAPI，OpenGLES的官网文档就指明，对于同一个上下文(OpenGLContext)而言，OpenGLES的接口不是线程安全的。OpenGL中，规定每个要调用OpenGLAPI的线程都必须拥有一个上下文(OpenGLContext)，并且它将渲染状态等状态数据保存在OpenGLContext中，对这些状态数据的操作是不加锁的，也就是说，如果多个线程共享同一个OpenGLContext，会由于多个线程同时调用OpenGLAPI而导致这个OpenGLContext中的状态错乱。但假如多个线程分别拥有独立的OpenGLContext，而不引入OpenGLShareGroup，则会导致这些OpenGLContext里的渲染资源无法共享(贴图、顶点数据等)，也就是做不到一个线程负责渲染、一个线程负责加载并创建贴图这样的高效并行操作，而只能把所有渲染资源相关的操作挤到渲染线程里。

通过上述方案，可以为每一个渲染线程创建一个用于保存渲染对应的信息的上下文(OpenGLContext)，使所有的上下文共享同一个资源组(OpenGLShareGroup)，并且该资源组中包括渲染资源，从而实现不同渲染线程都可以调用OpenGLAPI，同时他们之间又可以有效地共享渲染资源，提高渲染效率。

主线程向渲染线程传送渲染命令的方式有很多，在本实施例中，提供了一种可选的方式。主线程将渲染命令发送到命令队列中，然后，至少一个渲染线程从命令队列中获取渲染命令。例如，可以构建一个命令队列(RenderCommand队列)，主线程(或者其他线程)不停地将不依赖于游戏逻辑上下文的渲染命令发送到这个队列，同时渲染线程不停地取出并处理队列中的渲染命令，更新游戏画面。

在另一种可选的方案中，可以建立一个OpenGLWrapper，它用于直接包装并替代原有的OpenGLAPI调用，每一个对OpenGLWrapper的调用都会被发送到命令队列(RenderCommand队列)中，等待渲染线程去处理。

通过上述方案，可以将主线程发送的渲染命令保存在命令队列(例如，命令队列可以是使用环形缓冲RingBuffer构建的无锁队列)中，从而实现主线程和渲染线程的同步并行渲染。此处需要说明的是，无锁队列通常依赖CPU指令级别的CAS(CompareAndSwap/Set)来实现线程安全，其消耗远比有锁队列中使用的锁(互斥锁/临界区等)小得多。因为锁操作通常需要进行一系列系统调用，发生内核态与用户态的切换等等，这些都是比较低效的操作。如图2所示的内容中，使用了环形缓冲RingBuffer构建的无锁的命令队列(RenderCommandQueue)，从而保证最大化数据传递效率。

作为一个比较优的实施例，多者多线程技术在单核处理器(上述处理器可以是CPU，GPU等，但不仅限于此)情况下，效果可能会有所折扣，例如，多个线程在单核CPU上执行时会发生频繁的线程上下文切换，从而导致单核设备性能下降。因此，多线程渲染技术还需要考虑单核处理器的情况。

首先，判断是否具有多核处理器。在判断结果为是的情况下，建立主线程和至少一个渲染线程。在判断结果为否的情况下，建立同时执行渲染和应用的逻辑的一个线程。

在一种可选的方案中，可以判断当前设备是否具备多核CPU，如果是的话则进入本发明上述实施例提供的多线程渲染技术流程，建立主线程和至少一个渲染线程，使用多线程进行画面的渲染；否则退化到原本的单线程渲染技术流程，建立同时执行渲染和应用的逻辑的一个线程，即直接在主线程进行画面的渲染。

通过上述方案，可以在具有多个处理器的设备上建立多个线程，在具有单核处理器的设备上建立一个线程，从而既实现在多核处理器上将图形渲染的API分发到独立的线程上，与主线程并行执行，解决了现有技术中执行图形渲染和逻辑处理均在一个线程中进行所导致的问题，提升计算并行度和渲染效率，又保证对于单核CPU的情况进行特殊处理，直接在主线程上执行渲染任务，避免在单核CPU上使用多线程技术有可能会降低运行效率的问题。

本发明上述实施例提供的方案可以兼容大部分移动设备，包括所有iOS与Android设备；可以将图形渲染的API分发到独立的线程上执行，与游戏引擎主线程并行执行，提升游戏引擎性能；在OpenGLESAPI线程不安全的情况下，解决多个线程同时调用OpenGLESAPI时的线程安全问题。

在本实施例还提供了一种渲染装置实施例，图3是根据本发明实施例的渲染装置的结构框图，如图3所示，该装置包括：

发送模块32，位于主线程中，用于将渲染命令发送给至少一个渲染线程，其中，主线程用于处理应用的逻辑，渲染命令为不依赖于应用的逻辑的渲染命令。

获取模块34，位于至少一个所述渲染线程中，用于获取渲染命令，并根据渲染命令更新应用的画面。

上述应用可以是游戏应用，例如网络游戏，手机游戏等，但不仅限于此，其他类型的应用也可以实现本发明上述实施例的目的。本实施例以上述应用是手机游戏进行说明。

在一个可选的实施方式中，上述装置还可以包括：IO模块，位于加载线程中，用于进行输出输入IO读取操作。例如，读入贴图文件/模型顶点数据等，然后调用OpenGLAPI创建对应的GPU(GraphicProcessingUnit的缩写，图形处理器)资源，例如贴图、顶点数据等。

在另一个可选的实施方式中，上述装置还可以包括：第一建立模块，用于为至少一个渲染线程中的每个渲染线程建立对应的上下文，该上下文用于保存渲染对应的信息。每个渲染线程对应的上下文共享一个资源组，资源组中包括渲染资源。

上述渲染对应的信息可以是渲染状态等状态数据，但不仅限于此，其他类型的渲染信息也可以实现本发明上述实施例的目的，渲染资源可以是OpenGL的内部资源，例如贴图，顶点缓冲区等。

当然，该第一建立模块还可以用于建立至少一个上下文为主线程、和/或加载线程创建资源，该至少一个上下文与每个渲染线程对应的上下文共享同一个资源组，从而保证主线程、和/或加载线程加载的资源可以为渲染线程使用。

主线程向渲染线程传送渲染命令的方式有很多，在本实施例中，提供了一种可选的方式。发送模块还可以用于主线程将渲染命令发送到命令队列(例如，命令队列可以是使用环形缓冲RingBuffer构建的无锁的队列)中，获取模块还可以用于至少一个渲染线程从命令队列中获取渲染命令。

作为一个比较优的实施例，上述装置还可以包括：判断模块，用于判断是否具有多核处理器。第二建立模块，用于在判断结果为是的情况下，建立主线程和至少一个渲染线程；在判断结果为否的情况下，建立同时执行渲染和应用的逻辑的一个线程。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本发明所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，RandomAccessMemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (14)

1.一种渲染方法，其特征在于，包括：

主线程将渲染命令发送给至少一个渲染线程，其中，所述主线程用于处理应用的逻辑，所述渲染命令为不依赖于所述应用的逻辑的渲染命令；

至少一个所述渲染线程获取所述渲染命令，并根据所述渲染命令更新所述应用的画面。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

加载线程进行输出输入IO读取操作。

3.根据权利要求1或2所述的方法，其特征在于，

至少一个所述渲染线程中的每个渲染线程均对应一个上下文，其中，所述上下文用于保存渲染对应的信息，每个所述渲染线程对应的上下文共享一个资源组，所述资源组中包括渲染资源。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

建立至少一个上下文为所述主线程、和/或所述加载线程创建资源，其中，创建资源的所述至少一个上下文与每个所述渲染线程对应的上下文共享所述资源组。

5.根据权利要求4所述的方法，其特征在于，

所述主线程将所述渲染命令发送给至少一个所述渲染线程包括：所述主线程将所述渲染命令发送到命令队列中；

至少一个所述渲染线程获取所述渲染命令包括：至少一个所述渲染线程从所述命令队列中获取所述渲染命令。

6.根据权利要求5所述的方法，其特征在于，所述命令队列是使用环形缓冲RingBuffer构建的无锁的队列。

7.根据权利要求1至6中任一项所述的方法，其特征在于，所述方法还包括：

判断是否具有多核处理器；

在判断结果为是的情况下，建立所述主线程和至少一个所述渲染线程；

在判断结果为否的情况下，建立同时执行渲染和所述应用的逻辑的一个线程。

8.一种渲染装置，其特征在于，包括：

发送模块，位于主线程中，用于将渲染命令发送给至少一个渲染线程，其中，所述主线程用于处理应用的逻辑，所述渲染命令为不依赖于所述应用的逻辑的渲染命令；

获取模块，位于至少一个所述渲染线程中，用于获取所述渲染命令，并根据所述渲染命令更新所述应用的画面。

9.根据权利要求8所述的装置，其特征在于，所述装置还包括：

IO模块，位于加载线程中，用于进行输出输入IO读取操作。

10.根据权利要求8或9所述的装置，其特征在于，所述装置还包括：

第一建立模块，用于为至少一个所述渲染线程中的每个渲染线程建立对应的上下文，其中，所述上下文用于保存渲染对应的信息，每个所述渲染线程对应的上下文共享一个资源组，所述资源组中包括渲染资源。

11.根据权利要求10所述的装置，其特征在于，所述装置还包括：

所述第一建立模块，还用于建立至少一个上下文为所述主线程、和/或所述加载线程创建资源，其中，创建资源的所述至少一个上下文与每个所述渲染线程对应的上下文共享所述资源组。

12.根据权利要求11所述的装置，其特征在于，

所述发送模块，用于将所述渲染命令发送给至少一个所述渲染线程包括：所述主线程将所述渲染命令发送到命令队列中；

所述获取模块，用于获取所述渲染命令包括：至少一个所述渲染线程从所述命令队列中获取所述渲染命令。

13.根据权利要求12所述的装置，其特征在于，所述命令队列是使用环形缓冲RingBuffer来构建无锁的队列。

14.根据权利要求8至13中任一项所述的装置，其特征在于，所述装置还包括：

判断模块，用于判断是否具有多核处理器；

第二建立模块，用于在判断结果为是的情况下，建立所述主线程和至少一个所述渲染线程；在判断结果为否的情况下，建立同时执行渲染和所述应用的逻辑的一个线程。