Compressed visibility states for GPUs compatible with hardware instancing

By generating instances and primitive visibility buffers and using single bits to represent the visibility state, the problem of high memory and bandwidth requirements in graphics processing is solved, and more efficient hardware instantiation and culling is achieved.

CN111989715BActive Publication Date: 2025-04-25MICROSOFT TECHNOLOGY LICENSING LLC
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN201980026550.1
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2018-04-19
Filing Date
2019-04-06
Publication Date
2025-04-25
Estimated Expiration
2039-04-06

AI Technical Summary

Technical Problem

When prior art is used in graphics processing to determine the visibility of grid instances and primitives, there are problems with high memory cost and bandwidth requirements, especially when using 16-bit vertex indexes, complexity and the use of atomic operations increase the system burden.

Method used

By generating instance visibility buffers and primitive visibility buffers that describe each instance and primitive visibility state, using a single bit to represent the visibility state, simplifying hardware instantiation and culling processing, reducing memory and bandwidth requirements.

Benefits of technology

The memory and bandwidth requirements for primitive pre-catch and hardware instantiation are significantly reduced, the complexity of primitive culling is simplified, the small draw call problem is solved, and the rendering efficiency is improved.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN111989715B_ABST
    Figure CN111989715B_ABST
Patent Text Reader

Abstract

A method and apparatus for rendering a visible primitive in a scene of an application may include: loading a primitive visibility buffer, the primitive visibility buffer including a plurality of primitives, the plurality of primitives representing at least one instance in the scene of the application. The primitive visibility buffer may include a visibility bit for each of the plurality of primitives, the visibility bit describing a visibility state for each of the plurality of primitives as visible or invisible. The method and apparatus may include: determining whether each of the plurality of primitives is visible in the scene based on the visibility bit; rendering the primitive when the visibility bit for the primitive indicates that the primitive is visible; and skipping rendering of the primitive when the visibility bit indicates that the primitive is not visible. The method and apparatus may also include combining a pre-computed visibility state with a runtime visibility test when rendering the visibility bit.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present disclosure relates to computer devices and graphics processing. Background Art

[0002] Currently, in graphics, before rendering geometric primitives for computer games, a list is built that indicates which mesh instances and primitives are visible. As such, computer games increasingly pre-process mesh instances and primitives to determine their visibility as a pre-processing before executing a conventional graphics processing unit (GPU) rendering pipeline. To do this, computer games must write out per-frame lists of mesh instance data and primitives for processing.

[0003] Visibility testing and compression of per-instance data is typically done on the central processing unit (CPU). Typically, a compute shader on the GPU can determine if a primitive is visible, typically a triangle. Each GPU thread processes a single triangle, testing to ensure that the triangle is front-facing toward the viewer, is not off-screen, is not zero-area, and / or is not occluded. If the triangle is visible, each thread writes out the three vertex indices for the triangle. It also increments the total number of triangles to be rendered.

[0004] The rendering pipeline of this GPU requires either 32-bit or 16-bit vertex indices. When triangle pre-culling is not used, 16-bit is most commonly used due to the compressed storage. However, during the culling stage, the compute shader is usually unable to write only 16-bit memory. Therefore, if 16-bit indices are to be used, the implementation will pre-clear the output index buffer (which has a cost) and then atomically OR the high 16 bits or low 16 bits of the vertex index, which will share a 32-bit word with the triangle index written by a different GPU thread. The thread can pack the other two vertex indices into a single 32-bit write. Therefore, each thread must calculate which of the first or last vertex index requires atomic OR, and then pack the three indices into the correct 16 bits. Due to this complexity and the use of atomic operations, many implementations choose to use 32-bit indices, but this increases memory cost and bandwidth requirements.

[0005] Once the culling process is complete, the GPU can enter the traditional rendering phase. Due to GPU non-determinism, different thread groups process different triangles at different times. This results in a reordering of the original triangle list, which may adversely affect vertex cache hits during subsequent GPU rendering phases.

[0006] Therefore, there is a need in the art for improved visibility determination. Summary of the invention

[0007] A simplified overview of one or more embodiments of the present disclosure is given below to provide a basic understanding of such embodiments. This overview is not an extensive overview of all contemplated embodiments, and is neither intended to identify the key or important elements of all embodiments, nor to describe the scope of any or all embodiments. Its sole purpose is to present some concepts of one or more embodiments of the present disclosure in a simplified form as a prelude to a more detailed description presented later.

[0008] An example implementation relates to a computer device. The computer device may include a memory for storing data and instructions, a processor in communication with the memory, a graphics processing unit, and an operating system in communication with the memory, the processor, and the graphics processing unit. The graphics processing unit may be operable to: load a primitive visibility buffer including a plurality of primitives, the plurality of primitives representing at least one instance in a scene of an application, wherein the primitive visibility buffer includes a visibility bit for each of the plurality of primitives, the visibility bit describing a visibility state for each of the plurality of primitives as visible or invisible; determine whether each of the plurality of primitives is visible in the scene based on the visibility bit; render the primitive when the visibility bit for the primitive indicates that the primitive is visible; and skip rendering of the primitive when the visibility bit indicates that the primitive is not visible.

[0009] Another example implementation relates to a method for rendering a visible primitive in a scene of an application. The method may include, at a graphics processing unit executing on a computer device, loading a primitive visibility buffer, the primitive visibility buffer including a plurality of primitives, the primitive representing at least one instance in a scene of the application, wherein the primitive visibility buffer includes a visibility bit for each of the plurality of primitives, the visibility bit describing a visibility state for each of the plurality of primitives as visible or invisible. The method may also include determining whether each of the plurality of primitives is visible in the scene based on the visibility bit. The method may also include rendering the primitive when the visibility bit for the primitive indicates that the primitive is visible. The method may also include skipping rendering of the primitive when the visibility bit indicates that the primitive is not visible.

[0010] Another example embodiment relates to a computer-readable medium storing instructions executable by a computer device. The computer-readable medium may include at least one instruction for causing the computer device to load a primitive visibility buffer, the primitive visibility buffer including a plurality of primitives, the primitives representing at least one instance in a scene of an application, wherein the primitive visibility buffer includes a visibility bit for each of the plurality of primitives, the visibility bit describing a visibility state for each of the plurality of primitives as visible or invisible. The computer-readable medium may include at least one instruction for causing the computer device to determine whether each of the plurality of primitives is visible in the scene based on the visibility bit. The computer-readable medium may include at least one instruction for causing the computer device to render the primitive when the visibility bit for the primitive indicates that the primitive is visible. The computer-readable medium may include at least one instruction for causing the computer device to skip rendering of the primitive when the visibility bit indicates that the primitive is not visible.

[0011] Additional advantages and novel features associated with embodiments of the present disclosure will be set forth in part in the following description and will in part become more apparent to those skilled in the art upon examination of the following or through practice and study. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In the figure:

[0013] Figure 1 is a schematic block diagram of an example computer device according to one embodiment of the present disclosure;

[0014] Figure 2 is an example of an instance visibility buffer according to one embodiment of the present disclosure;

[0015] Figure 3 is an example of a primitive visibility buffer according to one embodiment of the present disclosure;

[0016] Figure 4 is an example method flow for predetermining visibility states of primitives in a scene of an application;

[0017] Figure 5 is an example method flow for rendering visible primitives in a scene of an application; and

[0018] Figure 6 is a schematic block diagram of an example device according to one embodiment of the present disclosure. DETAILED DESCRIPTION

[0019] The present disclosure relates to an apparatus and method for determining the visibility state of instances and / or primitives in a scene and / or image of a graphics-based application (such as, but not limited to, a game). Computer games increasingly pre-process triangles to determine the visibility of triangles by writing out a list of triangles per frame for processing as a pre-processing prior to executing a conventional graphics processing unit (GPU) rendering pipeline. Since each instance of a mesh has a unique set of visible triangles, existing triangle pre-culling solutions cannot be used for hardware instantiation. Games must issue draw call requests based on instances, some of which may have only a few or no triangles. As such, games that employ triangle pre-culling may end up with draw call limits on the GPU and / or central processing unit (CPU). Alternatively, games that employ triangle pre-culling may write out the transformed position of each vertex to create a single large draw call for all instances, which requires a large amount of bandwidth and memory for temporary storage. In addition, in a GPU rendering pipeline, the same vertex referenced by two different instances is not shared. Therefore, bandwidth requirements are further increased.

[0020] Instead of writing out a new triangle list, the apparatus and method described herein can generate an instance visibility buffer that describes the visibility state of each instance. In addition, the apparatus and method can generate a primitive visibility buffer that describes the visibility state of the primitives that make up the instance. Primitives can include, but are not limited to, blocks in triangles, quadrilaterals, polygons, lines, points, surfaces, or tessellation schemes, and / or bounding volumes, which can in turn include additional primitives. The apparatus and method can be used for any topological shape (e.g., individual triangles, triangle strips, and triangle fans). In addition, the apparatus and method can maintain the order of primitive submissions so that the primitive order remains optimal for vertex cache hits.

[0021] The apparatus and method may record a single bit for each primitive per instance, which may be used to determine whether to render the primitive. Previous solutions recorded three indices for each triangle, and therefore typically used 6 bytes or 12 bytes to indicate whether a triangle is visible or not. Therefore, by recording a single bit per primitive per instance, the apparatus and method may be used for hardware instancing, save memory and / or bandwidth, and may be significantly more efficient for primitive culling processing.

[0022] The apparatus and method may also record a single bit for each instance that indicates whether the instance is rendered. Recording a single bit for each instance may eliminate per-frame compression of per-instance data, such as transforms, which almost all current games perform on the CPU. The apparatus and method may also render the bit for each instance to identify whether the instance is visible. Additionally, when rendering visibility bits for instances and / or individual primitives, the apparatus and method may combine pre-computed visibility states with runtime visibility tests.

[0023] By using a single bit to identify visibility state, the apparatus and method can significantly reduce the memory and bandwidth requirements of both primitive pre-culling and hardware instantiation. In addition, by removing all atomic memory operations, the apparatus and method can simplify the complexity of primitive culling implementations. In hardware instantiation implementations currently used by almost all AAA video game engines, the apparatus and method can also remove the data compression step for each instance. The apparatus and method can also be used for hardware instantiation (which current primitive culling implementations cannot), thereby solving the 'small draw call problem'.

[0024] Reference now Figure 1 , an example computer device 102 for use in conjunction with determining the visibility state of a primitive 16 may include a graphics-based application 10, such as, but not limited to, a game, which may include one or more scenes 12 and / or images that may be presented on a display 38. The display 38 may be integrated into the computer device 102. For example, the display 38 may be the screen of a mobile phone. Alternatively, the display 38 may be a standalone device coupled to the computer device 102 via a wired or wireless communication link. For example, the display 38 may be a computer monitor or flat panel display connected to a personal computer via a cable or wireless link. In another example, the display 38 (and the computer device 102) may be part of a head-mounted display such as a virtual reality (VR), mixed reality (MR), or augmented reality (AR) device.

[0025] In each scene 12 and / or image of the application 10, there may be multiple instances 14 (up to n, where n is an integer) representing various objects in the scene 12. Each instance 14 may be a logical grid composed of multiple primitives 16 (up to m, where m is an integer) that describe the objects in the scene 12 and / or image. Primitives may include, but are not limited to, triangles, quadrilaterals, polygons, lines, points, blocks in a surface scheme, and / or bounding volumes, which may in turn include additional primitives. For example, there may be multiple instances 14 in a scene 12 that represent books, while other instances 14 in the scene 12 may represent candles.

[0026] Each primitive 16 may include description information 18, including, for example, three points of a triangle and / or other coordinate information identifying the shape of the primitive 16. In addition, each primitive 16 may include position information 20 indicating the position of the primitive 16. The description information 18 and / or the position information 20 may be used to identify the position of the primitive 16 in the scene 12 and / or the image.

[0027] When rendering a scene 12 and / or an image of the application 10 , the visibility state 23 of each primitive 16 may be used so that only primitives 16 that are visible in the scene 12 may be rendered.

[0028] The computer device 102 may include an operating system 110 executed by a CPU 44 and / or a system memory 46 of the computer device 102. The system memory 46 may be configured to store data and / or computer executable instructions that define and / or are associated with the operating system 110, and the CPU 44 may execute the operating system 110. Examples of the system memory 46 may include, but are not limited to, types of memory that may be used by a computer, such as random access memory (RAM), read-only memory (ROM), tape, magnetic disk, optical disk, volatile memory, non-volatile memory, and any combination thereof. Examples of the CPU 44 may include, but are not limited to, any processor that is specially programmed as described herein, including a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a system on a chip (SoC), or other programmable logic or state machine. The computer device 102 may include any removable or fixed computer device that may be connected to a network. For example, computer device 102 may be a computer device such as a desktop or laptop or tablet computer, a server computer, a cellular phone, a gaming device, a mixed reality or virtual reality device, a music device, a television, a navigation system, a camera, a personal digital assistant (PDA), or a handheld device, or any other computer device having wired and / or wireless connection capabilities to one or more other devices.

[0029] Operating system 110 may also include visibility component 22 that may predetermine visibility states of one or more instances 14 and / or primitives 16 depicted in scene 12 and / or images of application 10. Visibility component may be executed by GPU 35 and / or CPU of computer device 102.

[0030] In one embodiment, an offline and / or pre-computed visibility determination may be performed to determine a potentially visible set (PVS) of instances 14 and / or primitives 16 of a scene 12 and / or image. For example, the visibility component 22 may perform occlusion culling to estimate whether an instance 14 and / or primitive 16 is visible in the scene 12 and / or image. The potential visibility set may be stored as a bit per instance and / or a bit per primitive. For example, the potential visibility set may be stored as a PVS instance buffer 27 and / or a PVS primitive buffer 31. The PVS instance buffer 27 may include a PVS bit 29 for each instance, which describes the potential visibility of each instance 14 in the scene 12 and / or image. Additionally, the PVS primitive buffer 31 may include a PVS bit 33 for each primitive 16, which describes the potential visibility of each primitive 16 in the scene 12 and / or image.

[0031] Visibility component 22 may generate instance visibility buffer 24 having instance visibility bits 28 describing visibility of instance 14 in application 10. For each instance that visibility component 22 determines may be potentially visible, as represented by potential visibility setting bit 29, visibility component 22 may set instance visibility bit 28 for that instance 14 to “1”. If visibility component 22 determines that instance 14 may not be visible, visibility component 22 may set instance visibility bit 28 for instance 14 to “0”.

[0032] The visibility component 22 may also generate a primitive visibility buffer 30 having visibility bits 32 describing the visibility of the primitives 16 for each instance 14. For each primitive 16 that the visibility component 22 determines may be potentially visible, as indicated by a potential visibility setting bit 33, the visibility component 22 may set the visibility bit 32 for the primitive 16 to “1”. If the visibility component 22 determines that the primitive 16 may not be visible, the visibility component 22 may set the visibility bit 32 for the primitive 16 to “0”.

[0033] In addition, the visibility component 22 can perform one or more culling operations at runtime to determine the visibility state 23 of one or more primitives 16 in the scene 12 and / or image of the application 10. The visibility state 23 can identify whether the primitive 16 is visible to the camera in the scene 12 and / or image. In one embodiment, when performing a runtime visibility determination of the primitive 16, the visibility component 22 can use any predetermined and / or pre-calculated visibility state of the primitive 16. If the corresponding visibility bit 32 for the primitive 16 is "0", the visibility component 22 can skip the runtime visibility determination of the primitive 16. However, if the corresponding visibility bit 32 of the primitive 16 is "1", the visibility component 22 can perform a runtime visibility determination on the primitive 16 to verify that the primitive 16 is visible in the scene 12 and / or image.

[0034] For example, visibility component 22 may perform a back-face culling operation to determine whether primitive 16 is facing away from the camera. For primitives 16 facing away from the camera, visibility component 22 may determine visibility state 23 to be invisible. For primitives 16 facing the camera, visibility component 22 may determine visibility state 23 to be visible.

[0035] Visibility component 22 may also perform a frustum culling operation to determine whether primitive 16 is within the field of view of the camera. If primitive 16 is within the field of view of the camera, visibility component 22 may determine that visibility state 23 of primitive 16 is visible. If primitive 16 is outside the field of view of the camera, visibility component 22 may determine that visibility state 23 of primitive 16 is not visible.

[0036] The visibility component 22 may also perform a zero area culling operation to determine whether the size of the primitive 16 may be too small to contribute to the scene 12 and / or the image. For example, the visibility component 22 may compare the coverage of the primitives 16 to determine whether any pixels or samples are covered. When no pixels or samples are covered by the primitive 16, the visibility component 22 may determine that the visibility state 23 for the primitive 16 is not visible. However, if any pixels or samples of the primitive 16 are covered, the visibility component 22 may determine that the visibility state 23 for the primitive 16 is visible.

[0037] Visibility component 22 may also perform occlusion culling to determine whether primitive 16 is behind another object and therefore potentially obscured from view. For example, if primitive 16 is obscured from view by another object in scene 12, visibility component 22 may determine that visibility state 23 for primitive 16 is not visible. If primitive 16 is not obscured from view by another object in scene 12, visibility component 22 may determine that visibility state 23 for primitive 16 is visible.

[0038] The visibility component 22 may generate a primitive visibility buffer 30 having visibility bits 32 describing the visibility of the primitive 16 in the application 10. The visibility bits 32 may correspond to the visibility states 23 previously determined by the visibility component 22. For example, if the visibility state 23 for the primitive 16 is visible, the visibility bit 32 may be assigned a value of "1". If the visibility state 23 for the primitive 16 is not visible, the visibility bit 32 may be assigned a value of "0". In this way, a single bit may be used to describe the visibility state of each primitive 16 in the application 10. For example, if each instance has 60 triangles and there are 100 instances in the application 10, the primitive visibility buffer may include 6000 bits describing the visibility state 23 of each primitive 16 for each instance 14.

[0039] Visibility component 22 may also perform one or more culling operations to determine visibility of one or more instances 14. In one embodiment, when performing runtime visibility determination of instance 14, visibility component 22 may use any predetermined and / or pre-computed visibility states of instance 14. If the corresponding instance visibility bit 28 for instance 14 is "0", visibility component 22 may skip runtime visibility determination for instance 14. However, if the corresponding instance visibility bit 28 for instance 14 is "1", visibility component 22 may perform runtime visibility determination for instance 14 to verify that instance 14 is visible in scene 12 and / or image.

[0040] For example, the visibility component 22 may process a bounding volume 15 of a mesh associated with the instance 14 and compare the bounding volume 15 to the view cone and / or occlusion data to determine whether the instance 14 is visible. The volume may also be culled based on distance or screen space area. The bounding volume 15 may completely contain a logical mesh of the primitives 16 of the instance 14. For example, the bounding volume 15 may include, but is not limited to, a sphere and / or a box surrounding the instance 14. When the comparison indicates that the instance 14 is visible, the visibility state 25 of the instance 14 may be set to visible. When the comparison indicates that the instance 14 is not visible, the visibility state 25 of the instance 14 may be set to not visible. In one embodiment, before processing all meshes for different objects (e.g., books) in the scene 12 and / or image, the visibility component 22 may perform one or more culling operations on its meshes for a specific object (e.g., all candles) in the scene 12 and / or image.

[0041] The visibility component 22 may generate an instance visibility buffer 24 having an instance visibility bit 28 that describes the visibility of the instance 14 in the application 10. For example, if the visibility state 25 of the instance 14 is visible, the instance visibility bit 28 may be set to "1". Additionally, if the visibility state 25 of the instance 14 is not visible, the instance visibility bit 28 may be set to "0". In this way, the instance visibility bit 28 may be used to describe the visibility of each instance 14, rather than duplicating and / or compressing instance data (e.g., transformation matrices) based on the visibility results.

[0042] For example, the scene 12 may have multiple candles on a table, each with 100 triangles. The visibility component 22 may make a visibility determination for each candle on the table to determine whether the candle is visible, and if the candle is visible, the visibility component 22 may determine which triangles of the candle are visible. If the candle is visible, the visibility component 22 may write a "1" bit for the instance visibility bit 28 in the instance visibility buffer 24. If the candle is not visible, the visibility component 22 may write a "0" bit for the instance visibility bit 28 in the instance visibility buffer 24. For example, a candle may have 50 visible triangles. Thus, the visibility component 22 may write a "1" bit for the visibility bit 32 of each of the 50 primitives 16 that are visible for the candle, and write a "0" bit for the visibility bit 32 of each of the 50 primitives 16 that are not visible.

[0043] In one embodiment, visibility component 22 may perform culling operations only on primitives 16 of visible instances 14 (e.g., instances 14 where instance visibility bit 28 is set to “1”). Visibility component 22 may skip culling operations on primitives 16 of invisible instances 14 (e.g., instances 14 where instance visibility bit 28 is set to “0”).

[0044] In one embodiment, a graphics shader 36, such as a compute shader, may execute a visibility component 22 to process primitive pre-culling operations and / or instance pre-culling operations and generate a primitive visibility buffer 30 and / or an instance visibility buffer 24. For example, each thread in a compute shader may process a single primitive (e.g., a triangle) or an instance. However, instead of writing out a new index buffer, each thread records the visibility state in a single visibility bit 32. Visibility bits 32 may be packed into a single memory operation using a 'wave-wide' operation such as a bitwise OR. For each memory operation, each wave may effectively write visibility states for multiple primitives, typically 32 or 64-bit writes. In this way, no atomic operations are required and there is no counting of the number of visible primitives. In addition, storage may be significantly reduced because a single visibility bit for each primitive is stored in the primitive visibility buffer, rather than existing solutions that store 48 bits or often 96 bits for three vertex indices for each visible primitive and 48 bytes or more for each visible instance.

[0045] In another embodiment, an input assembler or a primitive-by-primitive programmable shader stage 34 (such as, but not limited to, a hull shader, a geometry shader, and / or a mesh shader) may execute the visibility component 22 to process primitive pre-culling operations and / or instance pre-culling operations and generate a primitive visibility buffer 30 and / or an instance visibility buffer 24.

[0046] In another embodiment, hardware may generate primitive visibility buffer 30 and / or instance visibility buffer 24 when hardware performs a depth pre-pass to render scene 12 .

[0047] Offline visibility determination results may be stored at instance and / or primitive level. For example, instance visibility buffer 24 and / or primitive visibility buffer 30 may be stored in memory 46.

[0048] At runtime of application 10, GPU 35 may copy offline visibility results for instance visibility buffer 24 and / or primitive visibility buffer 30 into the bitstream of the frame. GPU 35 may execute a runtime culling process 37 that performs a runtime instance culling and / or primitive culling pass. The runtime culling and / or primitive culling process may read instance visibility buffer 24 and / or primitive visibility buffer 30 and perform a runtime check only when instance visibility bit 28 and / or visibility bit 32 is "1".

[0049] In one embodiment, GPU 35 may skip runtime culling process 37 and may use instance visibility bits 28 and / or visibility bits 32 of instance visibility buffer 24 and / or primitive visibility buffer 30 without any runtime culling.

[0050] After the runtime culling process 37, the GPU rendering pipeline may be called with one or both of the instance visibility buffer 24 and / or the primitive visibility buffer 30 bound to the GPU 35. When the buffers are not bound, the contents of the buffers may be assumed to be all "1" bits.

[0051] The input assembler or per-primitive programmable shader stage 34 may load the instance visibility buffer 24 and / or the primitive visibility buffer 30. The input assembler or per-primitive programmable shader stage 34 may identify the instances 14 that are visible in the scene 12 based at least on the instance visibility bits 28 in the instance visibility buffer 24. Additionally, the input assembler or per-primitive programmable shader stage 34 may identify the primitives 16 that are visible in the scene based at least on the visibility bits 32 in the primitive visibility buffer 30.

[0052] When the instance visibility bit 28 and / or the visibility bit 32 indicate that the instance 14 and / or the primitive 16 is not visible, the input assembler or the primitive-by-primitive programmable shader stage 34 may skip processing of the entire instance 14 and / or the individual primitives 16. In this way, the input assembler or the primitive-by-primitive programmable shader stage 34 may not process all content in the scene, but may only process the visible primitives 16 and / or instances 14. For example, when the instance visibility bit 28 is “1”, the input assembler or the primitive-by-primitive programmable shader stage 34 may further process the primitives 16 of the visible instances 14. However, when the instance visibility bit is “0”, the input assembler or the primitive-by-primitive programmable shader stage 34 may skip further processing of the primitives 16 associated with the invisible instances 14.

[0053] Once the input assembler or per-primitive programmable shader stage 34 identifies the visible instances 14 and / or primitives 16 in the scene 12, a graphics shader 36 (such as a pixel shader) may render the visible primitives 16 in the scene 12. In this way, the pixel shader may shade only the pixels of the primitives 16 that are visible in the scene 12.

[0054] The rendered primitives 42 may be transmitted for presentation on the display 38. The display 38 may present the scene 12 of the application 10 with the rendered primitives 42 that depict the visible instances 40 in the scene 12.

[0055] The pixel pipeline may be kept busy by rendering only visible primitives 16 and / or instances 14. In this way, the pixel pipeline may not stop to try to find out whether a primitive 16 and / or instance 14 is visible in the scene 12, and efficiency may be improved.

[0056] For example, if the camera is in one room, objects in the next room are not visible. Thus, the input assembler or per-primitive programmable shader stage 34 can use this information to process only the primitives 16 and / or instances 14 that are visible in the current room. Additionally, a particular light source may be used in the room, and the pre-computed visibility determination may identify primitives 16 that are not visible to that light source. Thus, when rendering the shadow map for the light, the input assembler or per-primitive programmable shader stage 34 may skip processing of primitives 16 that are not visible to that particular light source.

[0057] In one embodiment, primitive visibility buffer 30 and / or instance visibility buffer 24 may instead be read by programmable graphics shader 36. For example, in DirectX, a geometry shader or a hull shader, both operating at the primitive level, may read and / or write primitive visibility buffer 30.

[0058] Therefore, by using a single bit to identify the visibility state of instances and / or primitives, a significant reduction in memory and bandwidth requirements for both primitive pre-culling and hardware instantiation can occur. In addition, all atomic memory operations can be removed, thereby simplifying the complexity of primitive culling. Furthermore, since the GPU can load transform data only for instances whose instance visibility bit 28 indicates visible, there may be no need to copy transforms and obtain final counts. In this way, the compression step of each instance data in a hardware instantiation implementation can be eliminated, and the count of the total number of visible instances for the frame can also be eliminated.

[0059] Reference now Figure 2 , the example instance visibility buffer 24 may include a scene 12 ( Figure 1) and / or multiple instances 14 in the image, and instance visibility bits 28 indicating whether instance 14 is visible. For example, in this case, row 202 of instance visibility buffer 24 may indicate that "book 1" is visible (e.g., instance visibility bit 28 is set to "1"). Row 204 of instance visibility buffer 24 may indicate that "book 2" is not visible (e.g., instance visibility bit 28 is set to "0"). Row 206 may indicate that "book 3" is visible (e.g., instance visibility bit 28 is set to "1"). Row 208 may indicate that "book 4" is not visible (e.g., instance visibility bit 28 is set to "0").

[0060] As such, instance visibility buffer 24 may store visibility descriptions that describe the visibility state of each instance 14 in scene 12. The visibility states of the instances may be used to improve the rendering process by rendering only the instances 14 that are visible in scene 12.

[0061] Reference now Figure 3 , an exemplary primitive visibility buffer 30 may include multiple instances 14, and may include multiple visibility bits 32 for each of the triangles that make up the instances 14. For example, in this case, the primitive visibility buffer 30 may include two instances (e.g., "book 1" and "book 3") having eight triangles 306, 308, 310, 312, 314, 316, 318, and 320. In addition, the visibility buffer may include eight visibility bits 32 for each of the triangles 306, 308, 310, 312, 314, 316, 318, and 320.

[0062] Primitive visibility buffer 30 may store visibility descriptions that describe the visibility state of each of the eight triangles that make up “Book 1” and “Book 2.” For example, row 302 may indicate that for “Book 1,” triangle 306 is visible (e.g., visibility bit 32 is set to “1”), triangles 308 and 310 are not visible (e.g., visibility bits 32 are set to “0”), triangle 312 is visible (e.g., visibility bit 32 is set to “1”), triangle 314 is not visible (e.g., visibility bit 32 is set to “0”), triangles 316 and 318 are visible (e.g., visibility bit 32 is set to “1”), and triangle 320 is not visible (visibility bit 32 is set to “0”). Row 304 may indicate that for “Book 2,” triangles 306 and 308 are visible (e.g., visibility bit 32 is set to “1”), triangles 310 and 312 are not visible (e.g., visibility bit 32 is set to “0”), and triangles 314, 316, 318, and 320 are visible (e.g., visibility bit 32 is set to “1”).

[0063] Thus, when the number of instances is greater than one, there may be a visibility bit per triangle for each instance.The visibility descriptions in the primitive visibility buffer 30 may be used to improve the rendering process by rendering only visible triangles.

[0064] Reference now Figure 4 , the example method 400 may be performed by the computer device 102 ( Figure 1 ) is used to predetermine in application 10 ( Figure 1 ) Scene 12( Figure 1 ) in primitive 16 ( Figure 1 ) visibility state 23 ( Figure 1 ). You can refer to the following Figure 1 The architecture of the method 400 is used to illustrate the action method.

[0065] At 402, method 400 may determine a bounding volume for each of a plurality of instances in a scene and / or an image of an application. For example, visibility component 22 may determine a bounding volume 15 for each instance 14 in scene 12 and / or an image of application 10. Each instance 14 may be a logical grid of a plurality of primitives 16 that depict objects in scene 12 and / or an image. Bounding volume 15 may completely contain a logical grid of primitives 16 of instance 14. For example, bounding volume 15 may include, but is not limited to, a sphere and / or a box surrounding instance 14. In this manner, instance 14 may be represented using bounding volume 15.

[0066] At 404, method 400 may optionally include: for each instance in the plurality of instances, determining whether the potentially visible set includes a "1" bit. An offline and / or pre-computed visibility determination may be performed by, for example, computer device 102 for primitives 16 of instance 14 and / or for corresponding bounding volumes 15 of instance 14 to determine a potentially visible set of instance 14 and / or primitives 16. For example, occlusion culling may be applied to instance 14 to estimate whether instance 14 may be visible in scene 12 and / or image, or whether any of its primitives 16 may be visible in scene 12 and / or image. The potentially visible set may be stored as a bit for each instance and / or a bit for each primitive. For example, the potentially visible set may be stored as a PVS instance buffer 27 and / or a PVS primitive buffer 31. PVS instance buffer 27 may include a PVS bit 29 for each instance, which describes the potential visibility of each instance 14 in scene 12 and / or image. Additionally, the PVS primitive buffer 31 may include a PVS bit 33 for each primitive 16 that describes the potential visibility of each primitive 16 in the scene 12 and / or image. The visibility component 22 may read the PVS instance buffer 27 to determine whether the PVS bit 29 for each instance 14 is set to "1".

[0067] At 408, method 400 may include assigning a "0" bit to the instance visibility buffer. Instance visibility buffer 24 may include instance visibility bits 28 for each of instances 14 in scene 12 and / or image. If visibility state 25 of instance 14 is determined to be not visible, instance visibility bit 28 may be set to "0".

[0068] At 406, method 400 may include determining whether a bounding volume for each of a plurality of instances is visible. Visibility component 22 may perform one or more culling operations at runtime to determine visibility of one or more instances 14 in scene 12 and / or image. In one embodiment, if the instance visibility bit 28 for buffer instance 14 is already set to "0" in instance visibility buffer 24 due to any predetermined visibility state, visibility component 22 may skip runtime visibility determination for instance 14. However, if the instance visibility bit 28 for the instance is set to "1" at least based on the predetermined visibility state, visibility component 22 may perform runtime visibility determination for instance 14 to verify that instance 14 is visible in scene 12 and / or image. For example, visibility component 22 may process bounding volume 15 of a mesh associated with instance 14 and compare bounding volume 15 to view frustum and / or occlusion data to determine whether instance 14 is visible, and it may also perform culling based on distance or screen space area. When the comparison indicates that instance 14 is visible, visibility state 25 of instance 14 may be set to visible. When the comparison indicates that instance 14 is not visible, visibility state 25 of instance 14 may be set to not visible. In one embodiment, visibility component 22 may perform one or more culling operations on bounding volumes 15 of specific objects (e.g., all candles) in scene 12 and / or image before processing all meshes for different objects (e.g., books) in image.

[0069] At 408, method 400 may include assigning a "0" bit to the instance visibility buffer. When the visibility state 25 of the instance 14 is set to invisible, visibility component 22 may generate an instance visibility buffer 24 having an instance visibility bit 28 describing visibility of the instance 14 in application 10. If the visibility state 25 of the instance 14 is invisible, the instance visibility bit 28 may be set to "0".

[0070] At 410, method 400 may include assigning a '1' bit to the instance visibility buffer. When the visibility state 25 of the instance 14 is set to visible, the visibility component 22 may set the instance visibility bit 28 to '1'. In this way, the instance visibility bit 28 may be used to describe the visibility of each instance 14, rather than duplicating and / or compressing instance data (e.g., transformation matrices) based on the visibility results.

[0071] At 412, method 400 may optionally include determining, for each primitive in the plurality of primitives, whether the potentially visible set includes a "1" bit. For example, visibility component 22 may read PVS primitive buffer 31 to determine whether PVS bit 33 for each primitive 16 is set to "1". If instance visibility bit 28 for instance 14 is "0", primitive 16 of that instance 14 may be skipped during pre-computed visibility determination.

[0072] At 414, method 400 may include assigning a "0" bit to the primitive visibility buffer. Primitive visibility buffer 30 may include visibility bits 32 that describe the visibility of each primitive in primitives 16 in instance 14. If the visibility state 23 of the primitive is determined to be invisible, visibility bit 32 may be set to "0".

[0073] At 416, method 400 may optionally include determining whether each primitive in a plurality of primitives is visible. The visibility component 22 may perform one or more culling operations at runtime to determine a visibility state 23 of one or more primitives 16 of an instance 14 in a scene 12 and / or an image. In one embodiment, if the visibility bit 32 for a primitive 16 is already set to "0" due to any predetermined visibility state, the visibility component 22 may skip a runtime visibility determination for the primitive 16. Additionally, if the visibility bit 32 for a primitive 16 is set to "1" due to any predetermined visibility state, the visibility component 22 may skip a runtime visibility determination for the primitive 16 and may use a predetermined visibility state for the primitive 16. In this manner, the visibility component 22 may perform runtime culling only at a per-instance level. In another embodiment, if visibility bit 32 for a primitive is set to “1” based at least on a predetermined visibility state, visibility component 22 may perform a runtime visibility determination for primitive 16 to verify that primitive 16 is visible in scene 12 and / or image.

[0074] The visibility state 23 may identify whether the primitive 16 is visible to the camera in the scene 12 and / or the image. For example, the visibility component 22 may perform a backface culling operation to determine whether the primitive 16 is facing away from the camera. The visibility component 22 may also perform a frustum culling operation to determine whether the primitive 16 is within the field of view of the camera. The visibility component 22 may also perform a zero area culling operation to determine whether the size of the primitive 16 may be too small to contribute to the scene 12 and / or the image. The visibility component 22 may also perform an occlusion culling operation to determine whether the primitive 16 is behind another object and, therefore, may be obscured from view.

[0075] At 414, method 400 may include assigning a "0" bit to a primitive visibility buffer. Visibility component 22 may generate primitive visibility buffer 30 having visibility bits 32 describing visibility of primitive 16 for each of instances 14. Visibility bits 32 may correspond to visibility states 23 previously determined by visibility component 22. If visibility state 23 for primitive 16 is not visible, visibility bits 32 may be assigned a value of "0".

[0076] At 418, method 400 may optionally include determining whether any primitives are visible in the instance. For example, visibility component 22 may determine that all visibility bits 32 in primitive visibility buffer 30 for corresponding instance 14 may be "0". Thus, if no primitives 16 are visible in instance 14 (e.g., all visibility bits are assigned a value of "0"), but instance bounding volume 15 is visible (e.g., instance visibility bit 28 for instance 14 is assigned a value of "1"), method 400 may set instance visibility bit 28 for instance 14 in instance visibility buffer 24 to "0". However, if at least one primitive 16 is visible, the visibility state 25 of the instance may remain unchanged (e.g., instance visibility bit 28 for instance 14 may remain at "1").

[0077] At 420, method 400 may include assigning a "1" bit to the primitive visibility buffer. If the visibility state 23 for the primitive 16 is visible, the visibility component 22 may set the visibility bit 32 to "1". In this way, a single bit may be used to describe the visibility state of each primitive 16 in the application 10. For example, if there are 60 triangles per instance and there are 100 instances in the application 10, the primitive visibility buffer may include 6000 bits that describe the visibility state 23 of each primitive 16 for each instance. In this way, when the number of instances 14 is greater than one, the primitive visibility buffer 30 may include a per-primitive visibility bit 32 for each instance 14.

[0078] In one embodiment, a graphics shader 36, such as a compute shader, may execute the visibility component 22 to process primitive pre-culling operations and / or instance pre-culling operations and generate the primitive visibility buffer 30 and / or instance visibility buffer 24. In another embodiment, an input assembler or a per-primitive programmable shader stage 34 may execute the visibility component 22 to process primitive pre-culling operations and / or instance pre-culling operations and generate the primitive visibility buffer 30 and / or instance visibility buffer 24.

[0079] By using a single bit to identify the visibility state of an instance and / or primitive, a significant reduction in memory and bandwidth requirements for both primitive pre-culling and hardware instantiation may occur.

[0080] Reference now Figure 5 , the example method 500 may be performed by the computer device 102 ( Figure 1 ) is used for rendering application 10( Figure 1 ) Scene 12( Figure 1 ) in the visible primitive 16 ( Figure 1 ). You can refer to the following Figure 1 The action method 500 is discussed in the architecture.

[0081] At 502, method 500 may include loading an instance visibility buffer. Instance visibility buffer 24 and / or primitive visibility buffer 30 may be stored in memory 46. During runtime of application 10, GPU 35 may copy offline visibility results of primitive visibility buffer 30 and / or instance visibility buffer 24 into a bitstream of a frame.

[0082] The GPU 35 may execute a runtime culling process 37 that performs a runtime instance culling and / or primitive culling pass. The runtime culling and / or primitive culling pass may read the instance visibility buffer 24 and / or the primitive visibility buffer 30 and perform a runtime check only if the instance visibility bit 28 and / or the visibility bit 32 is “1”. If a finer-grained runtime check concludes that the instance 14 and / or the primitive 16 is not visible, the GPU 35 may switch the “1” to “0”. In this way, the offline pre-computed visibility state may be effectively combined with the runtime visibility calculation. In one embodiment, the GPU 35 may skip the runtime culling process 37 and may use the instance visibility bit 28 of the instance visibility buffer 24 without any runtime culling.

[0083] An input assembler or per-primitive programmable shader stage 34 (such as, but not limited to, a hull shader, a geometry shader, and / or a mesh shader) may load the instance visibility buffer 24 and / or the primitive visibility buffer 30. The visibility buffer 24 may include instance visibility bits 28 for each instance 14 that describe the visibility state 25 for each instance 14. The primitive visibility buffer 30 may include a visibility bit 32 for each primitive 16 that describes the visibility state 23 of the primitive 16 as visible or not visible.

[0084] At 504, the method 500 may include determining whether the instance is visible. The input assembler or the per-primitive programmable shader stage 34 may determine whether the instance 14 is visible in the scene 12 based at least on the instance visibility bit 28 in the instance visibility buffer 24. For example, if the instance visibility bit 28 is set to "1", the input assembler or the per-primitive programmable shader stage 34 may determine that the instance 14 associated with the instance visibility bit 28 is visible. If the instance visibility bit 28 is set to "0", the input assembler or the per-primitive programmable shader stage 34 may determine that the instance 14 associated with the instance visibility bit 28 is not visible.

[0085] At 506, the method 500 may include skipping processing of the instance. When the instance visibility bit 28 indicates that the instance 14 is not visible, the input assembler or the per-primitive programmable shader stage 34 may skip the entire instance 14. In this way, the input assembler or the per-primitive programmable shader stage 34 may not process all content in the scene, but may only process visible instances 14. For example, when the instance visibility bit is "0", the input assembler or the per-primitive programmable shader stage 34 may skip further processing of primitives 16 associated with the invisible instance 14.

[0086] At 508 , method 500 may include reading visibility bits for multiple primitives of the instance. For example, when instance visibility bit 28 is “1,” the input assembler or per-primitive programmable shader stage 34 may further process primitives 16 associated with visible instances 14 .

[0087] At 510, the method 500 may include determining whether each primitive is visible. The input assembler or the primitive-by-primitive programmable shader stage 34 may determine whether the primitive 16 is visible in the scene based at least on the visibility bit 32 of the primitive 16. For example, if the visibility bit 32 is set to "1", the input assembler or the primitive-by-primitive programmable shader stage 34 may determine that the primitive 16 is visible. If the visibility bit 32 is set to "0", the input assembler or the primitive-by-primitive programmable shader stage 34 may determine that the primitive 16 is not visible.

[0088] At 512, method 500 may include rendering the primitive normally. Once the input assembler or per-primitive programmable shader stage 34 identifies visible instances 14 and / or primitives 16 in the scene 12 (e.g., the visibility states 23, 25 of the primitives 16 and / or instances 14 are visible), a graphics shader 36 such as a pixel shader may render the primitives 16.

[0089] At 514, method 500 may include skipping rendering primitives. When visibility bits 32 indicate that a primitive 16 is not visible in scene 12, a graphics shader 36, such as a pixel shader, may skip rendering individual primitives 16. In this way, the pixel shader may only shade pixels of primitives 16 that are visible in scene 12.

[0090] The pixel pipeline can be kept busy by rendering only visible primitives 16. In this way, the pixel pipeline can not stop to try to find out whether primitives 16 and / or instances 14 can be visible in the scene 12, and efficiency can be improved.

[0091] Therefore, by using a single bit to identify the visibility state of instances and / or primitives, a significant reduction in memory and bandwidth requirements for both primitive pre-culling and hardware instantiation can occur. In addition, all atomic memory operations can be removed, thereby simplifying the complexity of primitive culling. Furthermore, since the GPU can only load transform data for instances whose instance visibility bit 28 indicates visible, there may be no need to copy transforms and obtain final counts. In this way, the compression step of each instance data in a hardware instantiation implementation can be eliminated, and the count of the total number of visible instances for the frame can also be eliminated.

[0092] Reference now Figure 6 , illustrated is an example computer device 102 according to one embodiment, which includes a Figure 1 Additional component details. In one example, the computer device 102 may include a CPU 44 for performing processing functions associated with one or more of the components and functions described herein. The CPU 44 may include a single or multiple processors or a multi-core processor. In addition, the CPU 44 may be implemented as an integrated processing system and / or a distributed processing system.

[0093] The computer device 102 may also include a memory 46, such as for storing local versions of applications executed by the CPU 44. The memory 46 may include any type of memory usable by a computer, such as random access memory (RAM), read-only memory (ROM), tape, magnetic disk, optical disk, volatile memory, non-volatile memory, and any combination thereof. In addition, the CPU 44 and the memory 46 may include and execute an operating system 110 ( Figure 1 ).

[0094] In addition, the computer device 102 may include a communication component 48 that provides for establishing and maintaining communications with one or more parties utilizing the hardware, software, and services described herein. The communication component 48 may host communications between components on the computer device 102 and between the computer device 102 and external devices, such as devices located across a communication network and / or devices serially or locally connected to the computer device 102. For example, the communication component 48 may include one or more buses and may also include a transmit chain component and a receive chain component associated with a transmitter and a receiver, respectively, operable to interface with external devices.

[0095] In addition, computer device 102 may include data storage device 50, which may be any suitable combination of hardware and / or software that provides mass storage of information, databases, and programs employed in conjunction with the embodiments described herein. For example, data storage device 50 may be a computer program for application 10 ( Figure 1 ), visibility component 22( Figure 1 )、GPU 35( Figure 1 ) and / or display 38( Figure 1 ) data repository.

[0096] The computer device 102 may also include a user interface component 52, which is operable to receive input from a user of the computer device 102 and is also operable to generate output for presentation to the user. The user interface component 52 may include one or more input devices, including but not limited to a keyboard, a numeric keypad, a mouse, a touch display, a navigation key, a function key, a microphone, a voice recognition component, any other mechanism capable of receiving input from a user, or any combination thereof. In addition, the user interface component 52 may include one or more output devices, including but not limited to a display, a speaker, a tactile feedback mechanism, a printer, any other mechanism capable of presenting output to a user, or any combination thereof.

[0097] In one embodiment, user interface component 52 may transmit and / or receive messages corresponding to the operation of application 10, visibility component 22, GPU 35, and / or display 38. In addition, CPU 44 executes application 10, visibility component 22, GPU 35, and / or display 38, and memory 46 or data storage device 50 may store them.

[0098] As used in this application, the terms "component", "system", etc. are intended to include computer-related entities, such as but not limited to hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component can be but not limited to a process, a processor, a target, an executable file, an execution thread, a program, and / or a computer running on a processor. By way of illustration, both applications running on a computer device and a computer device can be components. One or more components can reside in an executed process or thread, and components can be localized on a computer and / or distributed between two or more computers. In addition, these components can be executed from various computer-readable media with various data structures stored thereon. Components can communicate through local and / or remote processes, such as according to signals with one or more data packets, such as data from a component that interfaces with another component in a local system, in a distributed system, and / or across a network, such as the Internet with other systems via signals.

[0099] Furthermore, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or." That is, unless specified otherwise, or clear from the context, the phrase "X employs A or B" is intended to mean any of the natural inclusive permutations. That is, the phrase "X employs A or B" is satisfied by any of the following instances: X employs A; X employs B; or X employs both A and B. Additionally, the articles "a" and "an" used in this application and the appended claims should generally be construed to mean "one or more" unless specified otherwise or clear from the context to be directed to the singular.

[0100] Various embodiments or features may have been presented in terms of systems that may include multiple devices, components, modules, etc. It should be understood and appreciated that the various systems may include additional devices, components, modules, etc., and / or may not include all of the devices, components, modules, etc. discussed in conjunction with the figures. Combinations of these methods may also be used.

[0101] The various illustrative logics, logic blocks, and method actions described in conjunction with the embodiments disclosed herein may be implemented or performed using one of the following items of special programming: a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in an alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computer devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. In addition, at least one processor may include one or more components that are operable to perform one or more of the steps or actions described above.

[0102] In addition, the steps and / or actions of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly in hardware, in a software module executed by a processor, or in a combination of the two. The software module may reside in a RAM memory, a flash memory, a ROM memory, an EPROM memory, an EEPROM memory, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium may be coupled to a processor so that the processor can read information from the storage medium and write information to its storage medium. In an alternative, the storage medium may be integral with the processor. In addition, in some embodiments, the processor and the storage medium may reside in an ASIC. In addition, the ASIC may reside in a user terminal. In an alternative, the processor and the storage medium may reside in a user terminal as discrete components. In addition, in some embodiments, the steps and / or actions of the method or algorithm may reside as one or any combination or a set of codes and / or instructions on a machine-readable medium and / or a computer-readable medium that may be incorporated into a computer program product.

[0103] In one or more embodiments, the functions described can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions can be stored or transferred to a computer-readable medium as one or more instructions or codes. Computer-readable media include both computer storage media and communication media, and communication media include media that facilitate the transfer of computer programs from one location to another. Storage media can be any available media that can be accessed by a computer. By way of example and not limitation, such computer-readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, disk storage or other magnetic storage devices, or any other media that can be used to store desired program codes in the form of instructions or data structures and can be accessed by a computer. The disk and dish used herein include compact disk (CD), laser disk, optical disk, digital versatile disk (DVD), floppy disk and blue-ray disk, wherein the disk usually copies data magnetically, but the dish usually uses lasers to optically copy data. The above combination should also be included in the scope of computer-readable media.

[0104] Although the embodiments of the present disclosure have been described in conjunction with the above examples, it will be understood by those skilled in the art that changes and modifications may be made to the embodiments described above without departing from the scope of this document. Other embodiments will be apparent to those skilled in the art from consideration of the specification or from practice, based on the examples disclosed herein.

Claims

1. A computer device comprising: Memory, used to store data and instructions; a processor in communication with the memory; Graphics processing unit; an operating system in communication with the memory, the processor, and the graphics processing unit, wherein the graphics processing unit is operable to: loading an instance visibility buffer, the instance visibility buffer comprising a plurality of instances, wherein the instance visibility buffer comprises, for each instance of the plurality of instances, an instance visibility bit describing a visibility state for each instance of the plurality of instances; Using the instance visibility bit, determining whether at least one instance of the plurality of instances is visible in a scene of the application; In response to the instance visibility bit indicating that the at least one instance is visible, loading a primitive visibility buffer including a plurality of primitives, the plurality of primitives representing the at least one instance in the scene, wherein the primitive visibility buffer includes a visibility bit for each primitive in the plurality of primitives, the visibility bit describing a visibility state for each primitive in the plurality of primitives as visible or not visible; determining, based on the visibility bit, whether each primitive of the plurality of primitives is visible in the scene; rendering the primitive when the visibility bit for a primitive indicates that the primitive is visible; as well as The rendering of the primitive is skipped when the visibility bit for the primitive indicates that the primitive is not visible.

2. The computer device of claim 1 , wherein the visibility bit for each primitive in the plurality of primitives is determined by performing one or more culling operations on the plurality of primitives to determine pre-computed visibility states of the plurality of primitives prior to runtime of the application in which the graphics processing unit renders the plurality of primitives.

3. The computer device of claim 1 , wherein the visibility state for each of the plurality of primitives is determined at runtime of the application by performing one or more culling operations on the plurality of primitives based at least on a current camera position.

4. The computer device of claim 1 , wherein the graphics processing unit is further operable to: The bit of the primitive for each of the plurality of instances for which the instance visibility bit indicates visible is read.

5. The computer device of claim 1 , wherein the graphics processing unit is further operable to: Processing of the primitive for each of the plurality of instances for which the instance visibility bit indicates not visible is skipped.

6. The computer device of claim 1, wherein the graphics processing unit is further operable to: Further processing of each of the plurality of instances for which the instance visibility bit indicates not visible is skipped. 7 . The computer device of claim 1 , wherein the instance visibility bit for each instance in the plurality of instances is determined by performing one or more culling operations on the plurality of instances to determine the visibility states of the plurality of instances. 8 . The computer device of claim 1 , wherein the instance visibility bit for each instance of the plurality of instances is determined based at least on a pre-computed visibility of each instance of the plurality of instances.

9. The computer device of claim 1 , wherein the graphics processing unit is further operable to: The rendered primitives are transmitted for presentation on a display.

10. The computer device of claim 1, wherein the graphics processing unit is further operable to: A bounding volume is determined for each of the plurality of instances in the scene, wherein each instance uses a primitive to describe an object in the scene.

11. A method for rendering a visible primitive in a scene of an application, comprising: At a graphics processing unit executing on a computer device, loading an instance visibility buffer, the instance visibility buffer comprising a plurality of instances, wherein the instance visibility buffer comprises an instance visibility bit for each instance of the plurality of instances, the instance visibility bit describing a visibility state for each instance of the plurality of instances; Using the instance visibility bit, determining whether at least one instance of the plurality of instances is visible in a scene of the application; In response to the instance visibility bit indicating that the at least one instance is visible, at the graphics processing unit, loading a primitive visibility buffer, the primitive visibility buffer comprising a plurality of primitives, the plurality of primitives representing the at least one instance in the scene, wherein the primitive visibility buffer comprises a visibility bit for each primitive in the plurality of primitives, the visibility bit describing a visibility state for each primitive in the plurality of primitives as visible or not visible; determining, based on the visibility bit, whether each primitive in the plurality of primitives is visible in the scene; When the visibility bit for a primitive indicates that the primitive is visible, rendering the primitive; and When the visibility bit indicates that the primitive is not visible, the rendering of the primitive is skipped.

12. The method of claim 11, wherein the visibility bit for each primitive in the plurality of primitives is determined by performing one or more culling operations on the plurality of primitives to determine pre-computed visibility states of the plurality of primitives prior to runtime of the application rendering the plurality of primitives.

13. The method of claim 11, wherein the visibility bit for each of the plurality of primitives is determined by performing one or more culling operations on the plurality of primitives based at least on a current camera position during runtime of the application.

14. The method according to claim 11, further comprising: The bit of the primitive for each of the plurality of instances for which the instance visibility bit indicates visible is read.

15. The method according to claim 11, further comprising: Further processing of the primitive for each of the plurality of instances for which the instance visibility bit indicates not visible is skipped.

16. The method according to claim 11, further comprising: Further processing of each of the plurality of instances for which the instance visibility bit indicates not visible is skipped.

17. The method of claim 11, wherein the instance visibility bit for each of the plurality of instances is determined prior to runtime of the application by performing one or more culling operations on the plurality of instances to determine visibility states of the plurality of instances.

18. The method according to claim 11, further comprising: The rendered primitives are transmitted for presentation on a display.

19. A non-transitory computer-readable medium storing instructions executable by a computer device, the instructions comprising: at least one instruction for causing the computer device to load an instance visibility buffer, the instance visibility buffer comprising a plurality of instances, wherein the instance visibility buffer comprises, for each instance of the plurality of instances, an instance visibility bit describing a visibility state for each instance of the plurality of instances; at least one instruction for causing the computer device to use the instance visibility bit to determine whether at least one instance of the plurality of instances is visible in a context of an application; at least one instruction for causing the computer device to load a primitive visibility buffer in response to the instance visibility bit indicating that the at least one instance is visible, the primitive visibility buffer comprising a plurality of primitives, the plurality of primitives representing the at least one instance in the scene, wherein the primitive visibility buffer comprises a visibility bit for each primitive in the plurality of primitives, the visibility bit describing a visibility state for each primitive in the plurality of primitives as visible or not visible; at least one instruction for causing the computer device to determine, based on the visibility bit, whether each primitive in the plurality of primitives is visible in the scene; at least one instruction for causing the computer device to render a primitive when the visibility bit for a primitive indicates that the primitive is visible; as well as At least one instruction for causing the computer device to skip the rendering of the primitive when the visibility bit for the primitive indicates that the primitive is not visible.

Citation Information

Patent Citations

  • Tessellation in tile-based rendering

    CN103946895A

  • Rendering graphics data using visibility information

    CN104919494A