CN117710183A - 渲染指令的传输方法、操作系统、电子设备、存储介质 - Google Patents
渲染指令的传输方法、操作系统、电子设备、存储介质 Download PDFInfo
- Publication number
- CN117710183A CN117710183A CN202311724077.9A CN202311724077A CN117710183A CN 117710183 A CN117710183 A CN 117710183A CN 202311724077 A CN202311724077 A CN 202311724077A CN 117710183 A CN117710183 A CN 117710183A
- Authority
- CN
- China
- Prior art keywords
- rendering
- rendering instructions
- instructions
- driver
- groups
- Prior art date
- Legal status (The legal status 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 status listed.)
- Pending
Links
- 238000009877 rendering Methods 0.000 title claims abstract description 482
- 238000000034 method Methods 0.000 title claims abstract description 72
- 230000005540 biological transmission Effects 0.000 title abstract description 22
- 238000012545 processing Methods 0.000 claims description 31
- 238000004590 computer program Methods 0.000 claims description 13
- 238000004806 packaging method and process Methods 0.000 claims description 10
- 230000002452 interceptive effect Effects 0.000 abstract description 11
- 238000010586 diagram Methods 0.000 description 17
- 239000000872 buffer Substances 0.000 description 10
- 230000006870 function Effects 0.000 description 9
- 230000008569 process Effects 0.000 description 4
- 238000003491 array Methods 0.000 description 2
- 239000000835 fiber Substances 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000001902 propagating effect Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 101150098958 CMD1 gene Proteins 0.000 description 1
- 101100382321 Caenorhabditis elegans cal-1 gene Proteins 0.000 description 1
- RYGMFSIKBFXOCR-UHFFFAOYSA-N Copper Chemical compound [Cu] RYGMFSIKBFXOCR-UHFFFAOYSA-N 0.000 description 1
- 230000003139 buffering effect Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 229910052802 copper Inorganic materials 0.000 description 1
- 239000010949 copper Substances 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012856 packing Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000005070 sampling Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Classifications
-
- 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
Landscapes
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Image Generation (AREA)
Abstract
本公开涉及渲染技术领域,提出一种渲染指令的传输方法、操作系统、电子设备、存储介质。渲染指令的传输方法应用于电子设备的操作系统,操作系统包括第一驱动、图形子系统以及第二驱动,所述方法包括:第一驱动缓存来自应用程序的渲染指令,得到多组渲染指令,每组渲染指令中对同一渲染资源的操作包括读操作或者写操作中的一种;第一驱动响应于应用程序对渲染资源的访问请求,将多组渲染指令打包后提交至图形子系统;图形子系统将打包的多组渲染指令提交至第二驱动;第二驱动将多组渲染指令发送至图形处理器处执行。本公开实施例的渲染指令的传输方法可以减少驱动与图形子系统的交互调用次数,从而降低单帧图像的渲染耗时,提升渲染性能。
Description
技术领域
本公开涉及渲染技术领域,尤其涉及一种渲染指令的传输方法、操作系统、电子设备、存储介质。
背景技术
电子设备渲染图像时使用图形处理器(graphics processing unit,GPU)。在渲染图像时,电子设备的用户模式驱动(user mode driver,UMD)需要根据硬件要求完成所有渲染指令配置,并将渲染指令提交给电子设备的图形子系统。图形子系统会把渲染指令提交给电子设备的内核模式驱动(kernel mode driver,KMD),内核模式驱动KMD再将渲染指令发送至图形处理器GPU,图形处理器GPU执行渲染指令完成渲染操作。图形处理器GPU完成渲染后,再通过内核模式驱动KMD通知图形子系统此次渲染完成,接着图形子系统再发送后续的渲染命令至图形处理器GPU。
现有技术中,每一帧图像的渲染都需要驱动与图形子系统进行大量的交互调用,导致单帧图像的渲染耗时较长。
发明内容
有鉴于此,本公开提出了一种渲染指令的传输方法、操作系统、电子设备、存储介质,本公开实施例的渲染指令的传输方法可以减少驱动与图形子系统的交互调用次数,从而降低单帧图像的渲染耗时,提升渲染性能。
根据本公开的一方面,提供了一种渲染指令的传输方法,所述方法应用于电子设备的操作系统,所述操作系统包括第一驱动、图形子系统以及第二驱动,所述电子设备还包括图形处理器,所述图形处理器具备依赖关系处理能力,所述方法包括:
所述第一驱动缓存来自应用程序的渲染指令,得到多组渲染指令,所述多组渲染指令之间存在依赖关系,每组渲染指令中对同一渲染资源的操作包括读操作或者写操作中的一种;所述第一驱动响应于所述应用程序对渲染资源的访问请求,将所述多组渲染指令打包后提交至所述图形子系统,所述访问请求的执行依赖于所述多组渲染指令的执行结果;所述图形子系统将打包的所述多组渲染指令提交至所述第二驱动;所述第二驱动将所述多组渲染指令发送至所述图形处理器处执行。
在一种可能的实现方式中,所述第一驱动将所述多组渲染指令打包后提交至所述图形子系统后,所述方法还包括:在所述多组渲染指令未全部执行的情况下,所述图形子系统更新提交标识的状态为第一状态;所述第一驱动查询到所述提交标识的状态为所述第一状态时,继续缓存来自所述应用程序的渲染指令。
在一种可能的实现方式中,所述第一驱动将所述多组渲染指令打包后提交至所述图形子系统后,所述方法还包括:在所述多组渲染指令全部已执行的情况下,所述图形子系统更新提交标识的状态为第二状态;所述第一驱动查询到所述提交标识的状态为所述第二状态时,将前次提交缓存指令起缓存的多组渲染指令打包后提交至所述图形子系统。
在一种可能的实现方式中,所述图形处理器包括前端和后端,所述第二驱动将所述多组渲染指令发送至所述图形处理器处执行,包括:所述第二驱动将所述多组渲染指令发送至所述前端;所述第二驱动将所述多组渲染指令发送至所述图形处理器处执行后,所述方法还包括:所述前端根据所述多组渲染指令的依赖关系,将所述多组渲染指令发送至所述后端处执行。
在一种可能的实现方式中,同一组渲染指令中的各渲染指令不存在依赖关系时,所述前端每次发送一组渲染指令;同一组渲染指令中的各渲染指令存在依赖关系时,所述前端按照各渲染指令的依赖关系发送渲染指令,每次发送至少一条渲染指令,每次发送的渲染指令之间不存在依赖关系。
在一种可能的实现方式中,所述第二驱动将所述多组渲染指令发送至所述图形处理器处执行后,所述方法还包括:所述后端每执行完一组渲染指令后,将该组渲染指令已执行的信息通知所述前端;所述前端接收到与所述多组渲染指令分别对应的渲染指令已执行的信息时,确定所述多组渲染指令全部已执行,将所述多组渲染指令全部已执行的信息通知所述图形子系统。
在一种可能的实现方式中,所述第一驱动为用户模式驱动,所述第二驱动为内核模式驱动。
根据本公开的另一方面,提供了一种操作系统,设置在电子设备上,所述操作系统包括第一驱动、图形子系统以及第二驱动,所述电子设备还包括图形处理器,所述图形处理器具备依赖关系处理能力,所述第一驱动用于缓存来自应用程序的渲染指令,得到多组渲染指令,所述多组渲染指令之间存在依赖关系,每组渲染指令中对同一渲染资源的操作包括读操作或者写操作中的一种;所述第一驱动用于响应于所述应用程序对渲染资源的访问请求,将所述多组渲染指令打包后提交至所述图形子系统,所述访问请求的执行依赖于所述多组渲染指令的执行结果;所述图形子系统用于将打包的所述多组渲染指令提交至所述第二驱动;所述第二驱动用于将所述多组渲染指令发送至所述图形处理器处执行。
在一种可能的实现方式中,所述图形子系统还用于在所述多组渲染指令未全部执行的情况下,更新提交标识的状态为第一状态;所述第一驱动还用于在查询到所述提交标识的状态为所述第一状态时,继续缓存来自所述应用程序的渲染指令。
在一种可能的实现方式中,所述图形子系统还用于在所述多组渲染指令全部已执行的情况下,更新提交标识的状态为第二状态;所述第一驱动还用于在查询到所述提交标识的状态为所述第二状态时,将前次提交缓存指令起缓存的多组渲染指令打包后提交至所述图形子系统。
在一种可能的实现方式中,所述图形处理器包括前端和后端,所述第二驱动将所述多组渲染指令发送至所述图形处理器处执行,包括:所述第二驱动将所述多组渲染指令发送至所述前端;所述前端用于根据所述多组渲染指令的依赖关系,将所述多组渲染指令发送至所述后端处执行。
在一种可能的实现方式中,同一组渲染指令中的各渲染指令不存在依赖关系时,所述前端每次发送一组渲染指令;同一组渲染指令中的各渲染指令存在依赖关系时,所述前端按照各渲染指令的依赖关系发送渲染指令,每次发送至少一条渲染指令,每次发送的渲染指令之间不存在依赖关系。
在一种可能的实现方式中,所述后端用于在每执行完一组渲染指令后,将该组渲染指令已执行的信息通知所述前端;所述前端还用于在接收到与所述多组渲染指令分别对应的渲染指令已执行的信息时,确定所述多组渲染指令全部已执行,将所述多组渲染指令全部已执行的信息通知所述图形子系统。
在一种可能的实现方式中,所述第一驱动为用户模式驱动,所述第二驱动为内核模式驱动。
根据本公开的另一方面,提供了一种电子设备,包括:处理器;用于存储处理器可执行指令的存储器;其中,所述处理器被配置为在执行所述存储器存储的指令时,实现上述方法。
根据本公开的另一方面,提供了一种非易失性计算机可读存储介质,其上存储有计算机程序指令,其中,所述计算机程序指令被处理器执行时实现上述方法。
根据本公开的另一方面,提供了一种计算机程序产品,包括计算机可读代码,或者承载有计算机可读代码的非易失性计算机可读存储介质,当所述计算机可读代码在电子设备的处理器中运行时,所述电子设备中的处理器执行上述方法。
根据本公开实施例的渲染指令的传输方法,在应用于电子设备的操作系统时,通过第一驱动缓存来自应用程序的渲染指令可得到多组渲染指令,每组渲染指令中对同一渲染资源的操作包括读操作或者写操作中的一种,从而相比现有技术缓存更多的渲染指令;第一驱动响应于应用程序对渲染资源的访问请求,将多组渲染指令打包后提交至图形子系统,使得可批量提交多组渲染指令,大大提升第一驱动与图形子系统之间的渲染指令提交效率,并减少第一驱动与图形子系统之间的渲染指令提交次数;图形子系统将打包的多组渲染指令提交至第二驱动,大大提升图形子系统与第二驱动之间的渲染指令提交效率,并减少图形子系统与第二驱动之间的渲染指令提交次数。第二驱动将多组渲染指令发送至图形处理器处执行,从而完成渲染指令从应用程序到图形处理器的传输。由于第一驱动与图形子系统之间、图形子系统与第二驱动之间的渲染指令提交次数都减少,因此驱动与图形子系统的交互调用次数得以减少,从而降低单帧图像的渲染耗时,提升渲染性能。
本公开实施例的图形处理器具备依赖关系处理能力,因此支持第一驱动每次向图形子系统发送存在依赖关系的多组渲染指令,使得可同时发送的渲染指令数量大大提升,进一步减少了驱动与图形子系统的交互调用次数。
根据下面参考附图对示例性实施例的详细说明,本公开的其它特征及方面将变得清楚。
附图说明
包含在说明书中并且构成说明书的一部分的附图与说明书一起示出了本公开的示例性实施例、特征和方面,并且用于解释本公开的原理。
图1示出现有技术中电子设备上的操作系统在渲染图像时的工作流程。
图2示出根据本公开实施例的渲染指令的传输方法的示例性应用场景。
图3a示出根据本公开实施例的渲染指令的传输方法的流程的示意图。
图3b示出根据本公开实施例的第一驱动缓存多组渲染指令的一个示例。
图4示出根据本公开实施例的图形处理器的结构的示意图。
图5示出根据本公开实施例的装置1900的框图。
具体实施方式
以下将参考附图详细说明本公开的各种示例性实施例、特征和方面。附图中相同的附图标记表示功能相同或相似的元件。尽管在附图中示出了实施例的各种方面,但是除非特别指出,不必按比例绘制附图。
在这里专用的词“示例性”意为“用作例子、实施例或说明性”。这里作为“示例性”所说明的任何实施例不必解释为优于或好于其它实施例。
另外,为了更好的说明本公开,在下文的具体实施方式中给出了众多的具体细节。本领域技术人员应当理解,没有某些具体细节,本公开同样可以实施。在一些实例中,对于本领域技术人员熟知的方法、手段、元件和电路未作详细描述,以便于凸显本公开的主旨。
电子设备渲染图像时使用图形处理器(graphics processing unit,GPU)。对于传统的GPU来说,其渲染过程一般可分为两个阶段:几何处理阶段和图元渲染阶段。几何处理阶段主要完成顶点操作、视口转换等;图元渲染阶段主要完成光栅化、纹理采样和图元渲染等。
在渲染图像时,需要电子设备的操作系统与GPU配合。图1示出现有技术中电子设备上的操作系统在渲染图像时的工作流程。
如图1所示,电子设备的用户模式驱动(user mode driver,UMD)将渲染指令存储在图形命令缓冲区(graphics command buffer)中,再将图形命令缓冲区的地址提交给电子设备的图形子系统,图形子系统再将图形命令缓冲区的地址提交给电子设备的内核模式驱动(kernel mode driver,KMD),内核模式驱动KMD就可以根据地址获取存储的渲染指令。内核模式驱动KMD再将渲染指令发送至图形处理器GPU(未示出),图形处理器GPU执行渲染指令完成渲染操作。图形处理器GPU完成渲染后,再通过内核模式驱动KMD通知图形子系统此次渲染指令执行完成,接着用户模式驱动UMD再提交下一次渲染命令至图形子系统。
图形处理器通常不具备依赖关系处理能力,接收到渲染指令之后就开始执行渲染指令。根据图1可知,对于图形子系统而言,每一次渲染指令的发送都需要等待上一次渲染指令执行完成。而某些渲染指令(如指令A)的执行可能要依赖于其他渲染指令(如指令B)的执行结果,如果指令A在指令B之前输出给图形处理器,那么指令A将无法执行,图形处理器的渲染线程可能会卡死。
因此,现有技术通常在用户模式驱动输出渲染指令前就先确认好渲染指令的依赖关系,使得用户模式驱动输出的渲染指令是图形处理器能够直接执行的渲染指令,并且同一次传输多个渲染指令时,多个渲染指令之间不存在依赖关系。同时,一次传输的多个渲染指令对同一渲染资源只存在读操作或者写操作。这一机制虽然可以保证图形处理器不会在执行渲染指令时因尚未得到执行渲染指令所需要的数据导致卡死,但限制了用户模式驱动每次能够传输的渲染指令的数量。
根据图1可知,提交一次指令需要驱动与图形子系统进行多次交互调用(包括用户模式驱动和图形子系统的交互调用以及图形子系统和内核模式驱动的交互调用),在图像较大时,每一帧图像的渲染都需要驱动与图形子系统进行大量的交互调用,导致单帧图像的渲染耗时较长。
有鉴于此,本公开提出了一种渲染指令的传输方法、操作系统、电子设备、存储介质,本公开实施例的渲染指令的传输方法可以减少驱动与图形子系统的交互调用次数,从而降低单帧图像的渲染耗时,提升渲染性能。
图2示出根据本公开实施例的渲染指令的传输方法的示例性应用场景。
如图2所示,本公开实施例的渲染指令的传输方法可以由电子设备的操作系统执行。电子设备可以是具备图像渲染能力的设备,包括图形处理器GPU、操作系统,并运行应用程序。应用程序可例如是游戏应用等,在运行过程中产生渲染指令。
操作系统包括第一驱动、第二驱动以及图形子系统。其中第一驱动可以是用户模式驱动,第二驱动可以是内核模式驱动。操作系统执行本公开实施例的渲染指令的传输方法,第一驱动可将渲染指令批量提交给图形子系统,图形子系统也将渲染指令批量提交给第二驱动,再由第二驱动将渲染指令发送至图形处理器GPU处,完成渲染指令从应用程序到图形处理器的传输。
图形处理器GPU执行渲染指令,在渲染指令执行完成后,通知第二驱动渲染指令已执行。第二驱动在批量提交的渲染指令都已执行时,通知图形子系统渲染指令已执行。
本领域技术人员应理解,操作系统还可以包括更多的装置、模块和子系统,在此不再一一列举。
图3a示出根据本公开实施例的渲染指令的传输方法的流程的示意图。
如图3a所示,在一种可能的实现方式中,本公开提出一种渲染指令的传输方法,所述方法应用于电子设备的操作系统,操作系统包括第一驱动、图形子系统以及第二驱动,操作系统的结构可以参见图2的示例。电子设备还包括图形处理器(未示出),图形处理器具备依赖关系处理能力。
所述方法包括:
步骤S31,第一驱动缓存来自应用程序的渲染指令,得到多组渲染指令,多组渲染指令之间存在依赖关系,每组渲染指令中对同一渲染资源的操作包括读操作或者写操作中的一种。
应用程序可例如是游戏应用等,该应用程序存在图像渲染需求,产生渲染指令。渲染指令可以是由图形处理器来执行的。在一帧图像的渲染过程中,因资源依赖产生的渲染指令可以被第一驱动缓存。示例性地,渲染指令可以被缓存在图形命令缓冲区(未示出)上。
第一驱动对渲染指令进行缓存时可以是分组缓存,得到多组渲染指令,每组渲染指令中对同一渲染资源的操作包括读操作或者写操作中的一种。也就是说,本公开实施例中,第一驱动缓存的任意一组渲染指令都可以是现有技术中用户模式驱动一次性最多可提交给图形子系统的渲染指令。并且由于图形处理器具备依赖关系处理能力,因此本公开实施例的多组渲染指令之间可存在依赖关系。
渲染资源可以指用于渲染和显示的资源(包括图元等等)。渲染资源可以被图形处理器访问,也可以被应用程序访问。渲染资源可以存储在电子设备的存储器中、寄存器中、缓冲区中等等,本公开实施例对于可访问渲染资源的对象和渲染资源的存储位置不作限制。
图3b示出根据本公开实施例的第一驱动缓存多组渲染指令的一个示例。
在图3b的示例中,第一驱动上可缓存N组渲染指令(cmd1-cmdN)。缓存时可按照N组渲染指令之间的依赖关系缓存N组渲染指令,也可以按照其他方式如按照渲染指令的产生时间缓存。本公开实施例对此不作限制。
例如在图3b的示例中,根据依赖关系确定第1组渲染指令未依赖于其他渲染指令,可以首先被执行,因此第1组渲染指令cmd1的缓存顺序可以是1。假设之后的每组指令都依赖于前一组指令,那么根据依赖关系可确定第N组渲染指令cmdN依赖于第N-1组渲染指令,则第N组渲染指令可以在第N-1组渲染指令执行后再执行,第N组渲染指令cmdN的缓存顺序可以是N。
本领域技术人员应理解,由于同一组渲染指令中对同一渲染资源的操作包括读操作或者写操作中的一种,因此也可能出现两组渲染指令依赖于同一组渲染指令的情况,此时对于两组渲染指令的缓存顺序的先后不作限制。
步骤S32,第一驱动响应于应用程序对渲染资源的访问请求,将多组渲染指令打包后提交至图形子系统,访问请求的执行依赖于多组渲染指令的执行结果。
应用程序在显示一帧图像之前需要先对渲染资源进行访问。此时应用程序会产生对渲染资源的访问请求。该访问请求可以由应用程序执行。访问请求的执行依赖于第一驱动已缓存的多组渲染指令的执行结果,因此访问请求可以触发第一驱动将已缓存的多组渲染指令打包后提交给图形子系统(即上文所述的第一驱动可将渲染指令批量提交给图形子系统),多组渲染指令是一起传输至图形子系统。其中在打包多组渲染指令时,如图3b所示,可以保持多组渲染指令的缓存顺序。
步骤S33,图形子系统将打包的多组渲染指令提交至第二驱动。
图形子系统在本公开实施例中的功能是为第一驱动和第二驱动提供交互的媒介。例如图形子系统上可设置有分别与第一驱动和第二驱动交互的接口。图形子系统通过与第一驱动交互的接口接收打包好的多组渲染指令,通过与第二驱动交互的接口将打包好的多组渲染指令提交至第二驱动(即上文所述的图形子系统也将渲染指令批量提交给第二驱动)。
步骤S34,第二驱动将多组渲染指令发送至图形处理器处执行。
第二驱动向图形处理器发送渲染指令时可以以分组为单位,每次发送一组渲染指令到图形处理器。第二驱动也可以直接将打包的多组渲染指令一起发送给图形处理器。图形处理器可以根据接收到的渲染指令间的依赖关系完成渲染指令的有序执行。渲染指令的示例性执行方式可以参见后文对步骤S34的进一步描述。
根据本公开实施例的渲染指令的传输方法,在应用于电子设备的操作系统时,通过第一驱动缓存来自应用程序的渲染指令可得到多组渲染指令,每组渲染指令中对同一渲染资源的操作包括读操作或者写操作中的一种,从而相比现有技术缓存更多的渲染指令;第一驱动响应于应用程序对渲染资源的访问请求,将多组渲染指令打包后提交至图形子系统,使得可批量提交多组渲染指令,大大提升第一驱动与图形子系统之间的渲染指令提交效率,并减少第一驱动与图形子系统之间的渲染指令提交次数;图形子系统将打包的多组渲染指令提交至第二驱动,大大提升图形子系统与第二驱动之间的渲染指令提交效率,并减少图形子系统与第二驱动之间的渲染指令提交次数。第二驱动将多组渲染指令发送至图形处理器处执行,从而完成渲染指令从应用程序到图形处理器的传输。由于第一驱动与图形子系统之间、图形子系统与第二驱动之间的渲染指令提交次数都减少,因此驱动与图形子系统的交互调用次数得以减少,从而降低单帧图像的渲染耗时,提升渲染性能。
本公开实施例的图形处理器具备依赖关系处理能力,因此支持第一驱动每次向图形子系统发送存在依赖关系的多组渲染指令,使得可同时发送的渲染指令数量大大提升,进一步减少了驱动与图形子系统的交互调用次数。
在实际应用场景中,对于特定的游戏应用程序,一帧图像存在多次渲染目标与着色器资源的切换,按照现有技术方案需要驱动与操作系统进行几十次的交互调用才能完成一帧图像的渲染,而本公开实施例的渲染指令的传输方法可以减少到6次。
在一种可能的实现方式中,第一驱动为用户模式驱动,第二驱动为内核模式驱动。本领域技术人员应理解,第一驱动也可以是能够与应用程序进行交互的其他驱动程序,第二驱动也可以是能够与图形处理器GPU进行交互的其他驱动程序,本公开实施例对于第一驱动和第二驱动的具体类型不作限制。
下面介绍第二驱动将打包的多组渲染指令一起发送给图形处理器后,图形处理器对渲染指令的处理方式。图4示出根据本公开实施例的图形处理器的结构的示意图。
如图4所示,在一种可能的实现方式中,图形处理器包括前端和后端,
步骤S34包括:
第二驱动将多组渲染指令发送至前端;
执行步骤S34后,所述方法还包括:
前端根据多组渲染指令的依赖关系,将多组渲染指令发送至后端处执行。
举例来说,图形处理器GPU可包括前端和后端,前端可以包括图形处理器GPU的固件(firmware),后端可以包括图形处理器GPU的渲染单元(render unit)。在执行步骤S34时,第二驱动可以将打包好的多组渲染指令发送给图形处理器的前端。
参见上文及图3b的相关描述,在一个示例中,打包之前第一驱动已经确定了多组渲染指令的依赖关系,并通过缓存顺序体现该依赖关系,由于在打包多组渲染指令时,保持了多组渲染指令的缓存顺序,因此前端可以直接基于接收到的数据包中的多组渲染指令的顺序确定多组渲染指令的依赖关系,根据依赖关系确定多组渲染指令的执行顺序,再将多组渲染指令依次发送至后端处执行。
通过这种方式,使得图形处理器确定各组渲染指令的依赖关系的方式更简单,降低图形处理器的数据处理成本。
在另一个示例中,如果打包之前尚未确定多组渲染指令的依赖关系,那么可以由前端分析多组渲染指令确定多组渲染指令的依赖关系。前端根据依赖关系可确定多组渲染指令的执行顺序,再将多组渲染指令依次发送至后端处执行。
通过这种方式,使得第一驱动无需确定各组渲染指令的依赖关系,降低第一驱动的数据处理成本。
在一种可能的实现方式中,同一组渲染指令中的各渲染指令不存在依赖关系时,前端每次发送一组渲染指令;
同一组渲染指令中的各渲染指令存在依赖关系时,前端按照各渲染指令的依赖关系发送渲染指令,每次发送至少一条渲染指令,每次发送的渲染指令之间不存在依赖关系。
举例来说,一组渲染指令可以是现有技术中的用户模式驱动一次发送的渲染指令,此时同一组渲染指令中的各指令之间不存在依赖关系。前端每次可以发送一组渲染指令给后端,例如缓存顺序如图3b所示时,可以是按照缓存顺序1~N的顺序对N组渲染指令(cmd1-cmdN)依次发送(参见图4)。通过这种方式可以保证依次发送至后端处执行的渲染指令的顺序与渲染指令产生的顺序一致,保证渲染指令的执行效率,同时图形处理器传输一组渲染指令时也无需使用依赖关系处理能力,进一步降低图形处理器的数据处理成本。
由于图形处理器具备依赖关系处理能力,因此可使得同一组渲染指令包括存在依赖关系的渲染指令。此时前端开始发送一组渲染指令时,可以是将未依赖于该组渲染指令中的其他渲染指令的渲染指令先发送,再发送该组渲染指令中依赖于已发送的渲染指令的渲染指令,以此类推,直到完成该组渲染指令中的所有渲染指令的发送。因此前端每次发送至少一条渲染指令,每次发送的渲染指令之间不存在依赖关系。
通过这种方式,使得第一驱动对渲染指令的分组方式更灵活,降低第一驱动的数据处理成本。
在一种可能的实现方式中,执行步骤S34后,所述方法还包括:
后端每执行完一组渲染指令后,将该组渲染指令已执行的信息通知前端;
前端接收到与多组渲染指令分别对应的渲染指令已执行的信息时,确定多组渲染指令全部已执行,将多组渲染指令全部已执行的信息通知图形子系统。
举例来说,后端每次接收一组渲染指令并执行。每执行完一组渲染指令后,会将该组渲染指令已执行的信息通知给前端(即上文所述的通知第二驱动渲染指令已执行)。在一次打包中包括的多组渲染指令都被后端执行完毕后,前端就会收到与多组渲染指令分别对应的渲染指令已执行的信息。例如按照缓存顺序1~N的顺序发送N组渲染指令(cmd1-cmdN)时,如图4所示,前端可以按照缓存顺序1~N的顺序依次接收到N组渲染指令(cmd1-cmdN)已执行的信息。
此时前端可以确定前次打包的多组渲染指令全部已执行,认为后端已经做好执行新的渲染指令的准备。因此前端可以将多组渲染指令全部已执行的信息通知图形子系统(即上文所述的通知图形子系统渲染指令已执行)。
通过这种方式,使得图形子系统可以及时获知一次打包的多组渲染指令是否全部已执行的信息。
在一种可能的实现方式中,第一驱动将多组渲染指令打包后提交至图形子系统后,所述方法还包括:
在多组渲染指令未全部执行的情况下,图形子系统更新提交标识的状态为第一状态;
第一驱动查询到提交标识的状态为第一状态时,继续缓存来自应用程序的渲染指令。
举例来说,参见上文所述,在多组渲染指令全部已执行时,第二驱动可以通知图形子系统多组渲染指令全部已执行的信息。为使得第一驱动也可以及时获知多组渲染指令全部已执行的信息,本公开实施例设置了提交标识。提交标识的状态可以指示多组渲染指令是否全部已执行。提交标识可以被图形子系统和第一驱动访问,提交标识的状态可以被图形子系统更改。
对于图形子系统来说,在提交一次打包的多组渲染指令之后、未接收到多组渲染指令全部已执行的信息时,可以认为多组渲染指令未全部执行。在多组渲染指令未全部执行的情况下,图形子系统可以更新提交标识的状态为第一状态。第一状态可以是指示多组渲染指令未全部执行的状态。
对于第一驱动来说,查询到提交标识的状态为第一状态时,可以认为前次打包提交的多组渲染指令尚未全部执行,图形处理器此时尚不能执行更多的渲染指令。因此第一驱动可以继续缓存来自应用程序的渲染指令。
在一种可能的实现方式中,第一驱动将多组渲染指令打包后提交至图形子系统后,所述方法还包括:
在多组渲染指令全部已执行的情况下,图形子系统更新提交标识的状态为第二状态;
第一驱动查询到提交标识的状态为第二状态时,将前次提交缓存指令起缓存的多组渲染指令打包后提交至图形子系统。
举例来说,第一驱动接收到应用程序对渲染资源的访问请求时,访问请求所依赖的渲染指令可能尚未缓存完毕,也即,已缓存的多组渲染指令是访问请求所依赖的渲染指令中的一部分。在此情况下,第一驱动响应于访问请求,将多组渲染指令打包后提交至图形子系统之后,会有新的渲染指令缓存到第一驱动。
对于图形子系统来说,一旦接收到多组渲染指令全部已执行的信息,就可以认为多组渲染指令全部已执行。在多组渲染指令全部已执行的情况下,图形子系统可以更新提交标识的状态为第二状态。第二状态可以是指示多组渲染指令全部已执行的状态。
对于第一驱动来说,查询到提交标识的状态为第二状态时,可以认为前次打包提交的多组渲染指令全部已执行,图形处理器此时可以执行更多的渲染指令。因此第一驱动可以将前次提交缓存指令起缓存的多组渲染指令打包后提交至图形子系统。之后可继续执行步骤S33和步骤S34。
在此情况下,应用程序对渲染资源的访问请求和提交标识的状态为第二状态可以作为两个独立的触发条件。满足两个触发条件中的任意一个时,第一驱动可以将缓存的多组渲染指令打包后提交至图形子系统。
通过这种方式,使得图形子系统不通知第一驱动时,第一驱动也可以及时获知多组渲染指令全部已执行的信息,减少两次打包提交的时间差。
在一种可能的实现方式中,本公开还提供一种操作系统,设置在电子设备上,操作系统的结构示意图可以参见图2。
所述操作系统包括第一驱动、图形子系统以及第二驱动,所述电子设备还包括图形处理器,所述图形处理器具备依赖关系处理能力,
所述第一驱动用于缓存来自应用程序的渲染指令,得到多组渲染指令,所述多组渲染指令之间存在依赖关系,每组渲染指令中对同一渲染资源的操作包括读操作或者写操作中的一种;
所述第一驱动用于响应于所述应用程序对渲染资源的访问请求,将所述多组渲染指令打包后提交至所述图形子系统,所述访问请求的执行依赖于所述多组渲染指令的执行结果;
所述图形子系统用于将打包的所述多组渲染指令提交至所述第二驱动;
所述第二驱动用于将所述多组渲染指令发送至所述图形处理器处执行。
在一种可能的实现方式中,所述图形子系统还用于在所述多组渲染指令未全部执行的情况下,更新提交标识的状态为第一状态;
所述第一驱动还用于在查询到所述提交标识的状态为所述第一状态时,继续缓存来自所述应用程序的渲染指令。
在一种可能的实现方式中,
所述图形子系统还用于在所述多组渲染指令全部已执行的情况下,更新提交标识的状态为第二状态;
所述第一驱动还用于在查询到所述提交标识的状态为所述第二状态时,将前次提交缓存指令起缓存的多组渲染指令打包后提交至所述图形子系统。
在一种可能的实现方式中,所述图形处理器包括前端和后端,
所述第二驱动将所述多组渲染指令发送至所述图形处理器处执行,包括:
所述第二驱动将所述多组渲染指令发送至所述前端;
所述前端用于根据所述多组渲染指令的依赖关系,将所述多组渲染指令发送至所述后端处执行。
在一种可能的实现方式中,同一组渲染指令中的各渲染指令不存在依赖关系时,所述前端每次发送一组渲染指令;同一组渲染指令中的各渲染指令存在依赖关系时,所述前端按照各渲染指令的依赖关系发送渲染指令,每次发送至少一条渲染指令,每次发送的渲染指令之间不存在依赖关系。
在一种可能的实现方式中,所述后端用于在每执行完一组渲染指令后,将该组渲染指令已执行的信息通知所述前端;
所述前端还用于在接收到与所述多组渲染指令分别对应的渲染指令已执行的信息时,确定所述多组渲染指令全部已执行,将所述多组渲染指令全部已执行的信息通知所述图形子系统。
在一种可能的实现方式中,所述第一驱动为用户模式驱动,所述第二驱动为内核模式驱动。
在一些实施例中,本公开实施例提供的装置具有的功能或包含的模块可以用于执行上文方法实施例描述的方法,其具体实现可以参照上文方法实施例的描述,为了简洁,这里不再赘述。
本公开实施例还提出一种计算机可读存储介质,其上存储有计算机程序指令,所述计算机程序指令被处理器执行时实现上述方法。计算机可读存储介质可以是易失性或非易失性计算机可读存储介质。
本公开实施例还提出一种电子设备,包括:处理器;用于存储处理器可执行指令的存储器;其中,所述处理器被配置为在执行所述存储器存储的指令时,实现上述方法。
本公开实施例还提供了一种计算机程序产品,包括计算机可读代码,或者承载有计算机可读代码的非易失性计算机可读存储介质,当所述计算机可读代码在电子设备的处理器中运行时,所述电子设备中的处理器执行上述方法。
图5示出根据本公开实施例的装置1900的框图。例如,装置1900可以被提供为一电子设备。参照图5,装置1900包括处理组件1922,其进一步包括一个或多个处理器,以及由存储器1932所代表的存储器资源,用于存储可由处理组件1922的执行的指令,例如应用程序。存储器1932中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外,处理组件1922被配置为执行指令,以执行上述方法。
装置1900还可以包括一个电源组件1926被配置为执行装置1900的电源管理,一个有线或无线网络接口1950被配置为将装置1900连接到网络,和一个输入输出接口1958(I/O接口)。装置1900可以操作基于存储在存储器1932的操作系统,例如Windows ServerTM,MacOS XTM,UnixTM,LinuxTM,FreeBSDTM或类似。
在示例性实施例中,还提供了一种非易失性计算机可读存储介质,例如包括计算机程序指令的存储器1932,上述计算机程序指令可由装置1900的处理组件1922执行以完成上述方法。
本公开可以是系统、方法和/或计算机程序产品。计算机程序产品可以包括计算机可读存储介质,其上载有用于使处理器实现本公开的各个方面的计算机可读程序指令。
计算机可读存储介质可以是可以保持和存储由指令执行设备使用的指令的有形设备。计算机可读存储介质例如可以是――但不限于――电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意合适的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括:便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、静态随机存取存储器(SRAM)、便携式压缩盘只读存储器(CD-ROM)、数字多功能盘(DVD)、记忆棒、软盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及上述的任意合适的组合。这里所使用的计算机可读存储介质不被解释为瞬时信号本身,诸如无线电波或者其他自由传播的电磁波、通过波导或其他传输媒介传播的电磁波(例如,通过光纤电缆的光脉冲)、或者通过电线传输的电信号。
这里所描述的计算机可读程序指令可以从计算机可读存储介质下载到各个计算/处理设备,或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令,并转发该计算机可读程序指令,以供存储在各个计算/处理设备中的计算机可读存储介质中。
用于执行本公开操作的计算机程序指令可以是汇编指令、指令集架构(ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码,所述编程语言包括面向对象的编程语言—诸如Smalltalk、C++等,以及常规的过程式编程语言—诸如“C”语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中,远程计算机可以通过任意种类的网络—包括局域网(LAN)或广域网(WAN)—连接到用户计算机,或者,可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中,通过利用计算机可读程序指令的状态信息来个性化定制电子电路,例如可编程逻辑电路、现场可编程门阵列(FPGA)或可编程逻辑阵列(PLA),该电子电路可以执行计算机可读程序指令,从而实现本公开的各个方面。
这里参照根据本公开实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本公开的各个方面。应当理解,流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合,都可以由计算机可读程序指令实现。
这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器,从而生产出一种机器,使得这些指令在通过计算机或其它可编程数据处理装置的处理器执行时,产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中,这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作,从而,存储有指令的计算机可读介质则包括一个制造品,其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。
也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装置、或其它设备上,使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤,以产生计算机实现的过程,从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。
附图中的流程图和框图显示了根据本公开的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分,所述模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个连续的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或动作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
以上已经描述了本公开的各实施例,上述说明是示例性的,并非穷尽性的,并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下,对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择,旨在最好地解释各实施例的原理、实际应用或对市场中的技术改进,或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。
Claims (11)
1.一种渲染指令的传输方法,其特征在于,所述方法应用于电子设备的操作系统,所述操作系统包括第一驱动、图形子系统以及第二驱动,所述电子设备还包括图形处理器,所述图形处理器具备依赖关系处理能力,所述方法包括:
所述第一驱动缓存来自应用程序的渲染指令,得到多组渲染指令,所述多组渲染指令之间存在依赖关系,每组渲染指令中对同一渲染资源的操作包括读操作或者写操作中的一种;
所述第一驱动响应于所述应用程序对渲染资源的访问请求,将所述多组渲染指令打包后提交至所述图形子系统,所述访问请求的执行依赖于所述多组渲染指令的执行结果;
所述图形子系统将打包的所述多组渲染指令提交至所述第二驱动;
所述第二驱动将所述多组渲染指令发送至所述图形处理器处执行。
2.根据权利要求1所述的方法,其特征在于,所述第一驱动将所述多组渲染指令打包后提交至所述图形子系统后,所述方法还包括:
在所述多组渲染指令未全部执行的情况下,所述图形子系统更新提交标识的状态为第一状态;
所述第一驱动查询到所述提交标识的状态为所述第一状态时,继续缓存来自所述应用程序的渲染指令。
3.根据权利要求1或2所述的方法,其特征在于,所述第一驱动将所述多组渲染指令打包后提交至所述图形子系统后,所述方法还包括:
在所述多组渲染指令全部已执行的情况下,所述图形子系统更新提交标识的状态为第二状态;
所述第一驱动查询到所述提交标识的状态为所述第二状态时,将前次提交缓存指令起缓存的多组渲染指令打包后提交至所述图形子系统。
4.根据权利要求1所述的方法,其特征在于,所述图形处理器包括前端和后端,
所述第二驱动将所述多组渲染指令发送至所述图形处理器处执行,包括:
所述第二驱动将所述多组渲染指令发送至所述前端;
所述第二驱动将所述多组渲染指令发送至所述图形处理器处执行后,所述方法还包括:
所述前端根据所述多组渲染指令的依赖关系,将所述多组渲染指令发送至所述后端处执行。
5.根据权利要求4所述的方法,其特征在于,同一组渲染指令中的各渲染指令不存在依赖关系时,所述前端每次发送一组渲染指令;
同一组渲染指令中的各渲染指令存在依赖关系时,所述前端按照各渲染指令的依赖关系发送渲染指令,每次发送至少一条渲染指令,每次发送的渲染指令之间不存在依赖关系。
6.根据权利要求4所述的方法,其特征在于,所述第二驱动将所述多组渲染指令发送至所述图形处理器处执行后,所述方法还包括:
所述后端每执行完一组渲染指令后,将该组渲染指令已执行的信息通知所述前端;
所述前端接收到与所述多组渲染指令分别对应的渲染指令已执行的信息时,确定所述多组渲染指令全部已执行,将所述多组渲染指令全部已执行的信息通知所述图形子系统。
7.根据权利要求1所述的方法,其特征在于,所述第一驱动为用户模式驱动,所述第二驱动为内核模式驱动。
8.一种操作系统,其特征在于,设置在电子设备上,所述操作系统包括第一驱动、图形子系统以及第二驱动,所述电子设备还包括图形处理器,所述图形处理器具备依赖关系处理能力,
所述第一驱动用于缓存来自应用程序的渲染指令,得到多组渲染指令,所述多组渲染指令之间存在依赖关系,每组渲染指令中对同一渲染资源的操作包括读操作或者写操作中的一种;
所述第一驱动用于响应于所述应用程序对渲染资源的访问请求,将所述多组渲染指令打包后提交至所述图形子系统,所述访问请求的执行依赖于所述多组渲染指令的执行结果;
所述图形子系统用于将打包的所述多组渲染指令提交至所述第二驱动;
所述第二驱动用于将所述多组渲染指令发送至所述图形处理器处执行。
9.一种电子设备,其特征在于,包括:
处理器;
用于存储处理器可执行指令的存储器;
其中,所述处理器被配置为在执行所述存储器存储的指令时,实现权利要求1至7中任意一项所述的方法。
10.一种非易失性计算机可读存储介质,其上存储有计算机程序指令,其特征在于,所述计算机程序指令被处理器执行时实现权利要求1至7中任意一项所述的方法。
11.一种计算机程序产品,包括计算机可读代码,或者承载有计算机可读代码的非易失性计算机可读存储介质,其特征在于,当所述计算机可读代码在电子设备中运行时,所述电子设备中的处理器执行权利要求1至7中任意一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202311724077.9A CN117710183A (zh) | 2023-12-14 | 2023-12-14 | 渲染指令的传输方法、操作系统、电子设备、存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202311724077.9A CN117710183A (zh) | 2023-12-14 | 2023-12-14 | 渲染指令的传输方法、操作系统、电子设备、存储介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN117710183A true CN117710183A (zh) | 2024-03-15 |
Family
ID=90160112
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202311724077.9A Pending CN117710183A (zh) | 2023-12-14 | 2023-12-14 | 渲染指令的传输方法、操作系统、电子设备、存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN117710183A (zh) |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111768330A (zh) * | 2019-03-30 | 2020-10-13 | 华为技术有限公司 | 图像处理方法及计算机系统 |
CN111861854A (zh) * | 2019-04-30 | 2020-10-30 | 华为技术有限公司 | 用于图形渲染的方法及装置 |
CN112381918A (zh) * | 2020-12-03 | 2021-02-19 | 腾讯科技(深圳)有限公司 | 图像渲染方法、装置、计算机设备和存储介质 |
CN113538207A (zh) * | 2021-09-17 | 2021-10-22 | 北京鲸鲮信息系统技术有限公司 | 跨进程调用的图形渲染方法、装置、电子设备与存储介质 |
CN115222869A (zh) * | 2021-04-21 | 2022-10-21 | 华为技术有限公司 | 分布式渲染方法及装置 |
CN116360928A (zh) * | 2023-05-15 | 2023-06-30 | 摩尔线程智能科技(北京)有限责任公司 | 一种安卓容器显示系统的优化方法及装置、电子设备 |
CN116719523A (zh) * | 2023-05-18 | 2023-09-08 | 浙江天猫技术有限公司 | 页面渲染方法及电子设备 |
CN117036566A (zh) * | 2023-08-28 | 2023-11-10 | 北京趋动智能科技有限公司 | 远程图像渲染方法、系统、电子设备及可读存储介质 |
-
2023
- 2023-12-14 CN CN202311724077.9A patent/CN117710183A/zh active Pending
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111768330A (zh) * | 2019-03-30 | 2020-10-13 | 华为技术有限公司 | 图像处理方法及计算机系统 |
CN111861854A (zh) * | 2019-04-30 | 2020-10-30 | 华为技术有限公司 | 用于图形渲染的方法及装置 |
CN112381918A (zh) * | 2020-12-03 | 2021-02-19 | 腾讯科技(深圳)有限公司 | 图像渲染方法、装置、计算机设备和存储介质 |
CN115222869A (zh) * | 2021-04-21 | 2022-10-21 | 华为技术有限公司 | 分布式渲染方法及装置 |
CN113538207A (zh) * | 2021-09-17 | 2021-10-22 | 北京鲸鲮信息系统技术有限公司 | 跨进程调用的图形渲染方法、装置、电子设备与存储介质 |
CN116360928A (zh) * | 2023-05-15 | 2023-06-30 | 摩尔线程智能科技(北京)有限责任公司 | 一种安卓容器显示系统的优化方法及装置、电子设备 |
CN116719523A (zh) * | 2023-05-18 | 2023-09-08 | 浙江天猫技术有限公司 | 页面渲染方法及电子设备 |
CN117036566A (zh) * | 2023-08-28 | 2023-11-10 | 北京趋动智能科技有限公司 | 远程图像渲染方法、系统、电子设备及可读存储介质 |
Non-Patent Citations (1)
Title |
---|
陈智勇, 雷航: "运用多线程RTI服务改善3D图形性能", 福建电脑, no. 05, 25 May 2005 (2005-05-25), pages 1 - 4 * |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8736625B2 (en) | Asynchronous notifications for concurrent graphics operations | |
US8350864B2 (en) | Serializing command streams for graphics processors | |
US8525841B2 (en) | Batching graphics operations with time stamp tracking | |
KR102605313B1 (ko) | 가상화된 가속 처리 디바이스를 위한 조기 가상화 컨텍스트 전환 | |
US8085280B2 (en) | Asymmetric two-pass graphics scaling | |
US7876328B2 (en) | Managing multiple contexts in a decentralized graphics processing unit | |
US9563466B2 (en) | Method and apparatus for supporting programmable software context state execution during hardware context restore flow | |
US9355428B2 (en) | Method and apparatus for data processing using graphic processing unit | |
US8531470B2 (en) | Deferred deletion and cleanup for graphics resources | |
CN113515396A (zh) | 图形渲染方法、装置、电子设备与存储介质 | |
US11263064B2 (en) | Methods and apparatus to facilitate improving processing of machine learning primitives | |
US20210240524A1 (en) | Methods and apparatus to facilitate tile-based gpu machine learning acceleration | |
US10453243B2 (en) | Primitive level preemption using discrete non-real-time and real time pipelines | |
KR20230073222A (ko) | 깊이 버퍼 프리-패스 | |
KR102605312B1 (ko) | 가상화 디바이스에 대한 펌웨어 변경 | |
CN108460718B (zh) | 基于低功耗飞腾的三维图形显示系统优化方法及装置 | |
EP4203487A1 (en) | Method and apparatus for processing multimedia resource | |
CN117710183A (zh) | 渲染指令的传输方法、操作系统、电子设备、存储介质 | |
US20140176577A1 (en) | Method and mechanism for preempting control of a graphics pipeline | |
US12056787B2 (en) | Inline suspension of an accelerated processing unit | |
US20240311199A1 (en) | Software-defined compute unit resource allocation mode | |
CN115826898A (zh) | 一种跨屏显示方法、系统、装置、设备及存储介质 | |
GB2624466A (en) | Graphics processing systems | |
TW202123165A (zh) | 用於減少繪製命令資訊的方法和裝置 | |
CN115033286A (zh) | 数据处理方法、装置、芯片、设备及介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |