Multi-viewport transform module for use in 3D rendering system

Abstract

The invention relates to a multi-viewport transformation module for use in a 3D rendering system. The viewport transformation module includes an extraction module configured to read from the vertex buffer: untransformed coordinate data for vertices in the stripe; identifying information of a viewport associated with the vertex; and information identifying viewports associated with one or more other vertices in the stripe. One or more other vertices in the slice are selected based on the initiation vertices of the primitive formed by the vertices in the slice and the number of vertices in the primitive. The viewport transformation module further includes a processing module that performs a viewport transformation on the untransformed coordinate data based on each identified viewport to generate transformed coordinate data for each identified viewport; and a write module that writes the transformed coordinate data for each identified viewport to the vertex buffer.

Description

[0001] Description of the case

[0002] This application is a divisional application of an invention patent application with an application date of June 29, 2018, application number 201810716112.5, and titled “Multi-viewport transformation module for use in a 3D rendering system”. Technical Field

[0003] The present disclosure relates to a multi-viewport transformation module for use in a 3D rendering system. Background Art

[0004] A three-dimensional (3D) graphics system (which may also be referred to herein as a rendering system) is designed to render an image of a 3D scene on a two-dimensional (2D) screen. Specifically, an application (e.g., a video game) generates a 3D model of a scene and outputs geometric data representing objects in the scene. Specifically, the application divides each object into a plurality of primitives (i.e., simple geometric shapes, such as triangles, lines, and points) defined by the positions of one or more vertices. The geometric data output by the application includes information identifying each vertex (e.g., the coordinates of the vertex) and information indicating the primitives formed by the vertices. The graphics system then transforms the received geometric data into an image displayed on the screen.

[0005] 3D graphics systems typically have two main stages - the geometry processing stage and the rasterization stage. During the geometry processing stage, vertices received from the application are processed from Figure 1A The world window 102 (i.e., world space coordinates) is shown transformed into the viewport 104 (i.e., screen space coordinates), which is referred to herein as a viewport transformation. The world window 102 is the area of ​​the scene 106 in application-specific coordinates (e.g., kilometers or centimeters) that the user wants to visualize. In contrast, the viewport 104 is the area of ​​the screen 108 in rendering device-specific coordinates (e.g., pixels or sampling locations) used to display an image of the scene. The viewport 104 can be the entire screen 108 or a portion thereof. Thus, the viewport transformation converts the input world space coordinates in the world window 102 into screen space coordinates in the viewport 104.

[0006] In many cases (e.g. Figure 1A), the geometry processing stage uses a single viewport at a time (typically of a size that covers the entire screen), and the coordinates of all vertices are transformed to that viewport. However, some applications (such as, but not limited to, geometry shaders) may use multiple viewports to implement one or more visual effects. For example, in some cases, it may be desirable to render to a smaller window within the screen and / or to multiple windows within the screen. In other examples, some applications may implement layered rendering, where specific primitives may be sent to different layers of a layered framebuffer (each layer associated with a different viewport), such as for implementing cube-based shadow mapping. For example, as Figure 1B As shown, there may be two viewports 110 and 112 in screen 108, and a first primitive 114 and a second primitive 116 are rendered in first viewport 110, and a third primitive 118 is rendered in second viewport 112. In these cases, the geometry data output by the application may include information indicating the viewport associated with each primitive, which allows the coordinates of the vertices of different primitives to be mapped to different viewports. The geometry processing stage typically also includes forming primitives from the received vertices before or after viewport transformation.

[0007] During the rasterization phase, primitives are mapped to pixels and the color of each pixel is determined. This may include identifying which primitive is visible at each pixel. The color of each pixel may then be determined by the texture of the (one or more) visible primitives at that pixel and / or the pixel shader program running on that pixel. The pixel shader program describes the operations performed for a given pixel. Once a color value has been identified for each pixel, the color value is written to a frame buffer in memory and then displayed on the screen.

[0008] The embodiments described below are provided by way of example only and are not intended to limit implementations that address any or all of the shortcomings of known viewport transformation systems. Summary of the invention

[0009] This Summary is provided to introduce a selection of concepts that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0010] Described herein is a viewport transformation module and method for use in a three-dimensional rendering system that supports the use of multiple viewports. The viewport transformation module includes an extraction module configured to read from a vertex buffer: untransformed coordinate data for vertices in a strip; information identifying a viewport associated with the vertex; and information identifying a viewport associated with one or more other vertices in the strip. The one or more other vertices in the strip are selected based on the provoking vertex of the primitive formed by the vertices in the strip and the number of vertices in the primitive. The viewport transformation module also includes a processing module that performs a viewport transformation on the untransformed coordinate data based on each identified viewport to generate transformed coordinate data for each identified viewport; and a writing module that writes the transformed coordinate data for each identified viewport to the vertex buffer.

[0011] A first aspect provides a viewport transformation module for use in a three-dimensional rendering system, the viewport transformation module comprising: an extraction module configured to read from a vertex buffer: untransformed coordinate data for vertices in a strip; information identifying a viewport associated with the vertex; and information identifying a viewport associated with one or more other vertices in the strip, the one or more other vertices in the strip being selected based on a triggering vertex of a primitive formed by the vertices in the strip and the number of vertices in the primitive; a processing module configured to perform viewport transformation on the untransformed coordinate data based on each identified viewport to generate transformed coordinate data for each identified viewport; and a writing module configured to write the transformed coordinate data for each identified viewport into the vertex buffer.

[0012] A second aspect provides a method for performing multi-viewport transformation on vertices in a vertex strip, the method comprising: extracting untransformed coordinate data for the vertex from a vertex buffer at a viewport transformation module; extracting information identifying a viewport associated with the vertex at the viewport transformation module; extracting information identifying a viewport associated with at least one other vertex in the strip at the viewport transformation module, the at least one other vertex being selected based on a triggering vertex of a primitive formed by the vertices in the strip and the number of vertices in the primitive; performing a viewport transformation on the untransformed coordinate data based on each identified viewport at the viewport transformation module to generate transformed coordinate data for each identified viewport; and writing the transformed coordinate data for each identified viewport to the vertex buffer.

[0013] A third aspect provides a viewport transformation module used in a three-dimensional rendering system, the viewport transformation module comprising: a processing module configured to perform viewport transformation on untransformed coordinate data of vertices in a strip for each of a plurality of viewports to generate transformed coordinate data for each of the plurality of viewports, the plurality of viewports comprising a viewport associated with the vertex and a viewport associated with at least one other vertex in the strip, the at least one other vertex being selected based on a triggering vertex of a primitive formed by the vertices in the strip and the number of vertices in the primitive; and a writing module configured to write the transformed coordinate data into a vertex buffer so that the transformed coordinate data is stored in the vertex buffer in an order corresponding to the order of the plurality of vertices in the strips associated with the plurality of viewports.

[0014] A fourth aspect provides a method for performing multi-viewport transformation on vertices in a strip, comprising: performing viewport transformation on untransformed coordinate data of the vertices in the strip for each of a plurality of viewports to generate transformed coordinate data for each of a plurality of viewports, the plurality of viewports including a viewport associated with the vertex and a viewport associated with at least one other vertex in the strip, the at least one other vertex being selected based on a triggering vertex of a primitive formed by the plurality of vertices in the strip and the number of vertices in the primitive; and writing the transformed coordinate data to a vertex buffer so that the transformed coordinate data is stored in the vertex buffer in an order corresponding to the order of the plurality of vertices in the strip associated with the plurality of viewports.

[0015] The viewport transformation module may be embodied in hardware form on an integrated circuit. A method of manufacturing a viewport transformation module in an integrated circuit manufacturing system may be provided. An integrated circuit definition data set may be provided, which, when processed in the integrated circuit manufacturing system, configures the system to manufacture the viewport transformation module. A non-transitory computer-readable storage medium may be provided, on which a computer-readable description of the viewport transformation module is stored, which, when processed in the integrated circuit manufacturing system, causes the integrated circuit manufacturing system to manufacture an integrated circuit embodying the viewport transformation module.

[0016] An integrated circuit manufacturing system can be provided, comprising: a non-transitory computer-readable storage medium having stored thereon a computer-readable description of a viewport transformation module; a layout processing system configured to process the computer-readable description to generate a circuit layout description of an integrated circuit embodying the viewport transformation module; and an integrated circuit generation system configured to manufacture the viewport transformation module based on the circuit layout description.

[0017] A computer program code for performing the method described herein may be provided. A non-transitory computer readable storage medium may be provided on which computer readable instructions are stored, which when executed at a computer system, cause the computer system to perform the method described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The present invention will now be described by way of example with reference to the accompanying drawings, in which:

[0019] Figure 1A is a schematic diagram of windows and viewports;

[0020] Figure 1B It is a schematic diagram of multiple viewports;

[0021] Figure 2 is a block diagram of an example 3D rendering system including a primitive processing module;

[0022] Figure 3 is a schematic diagram of a first example triangle strip;

[0023] Figure 4 yes Figure 2 A block diagram of an example primitive processing module;

[0024] Figure 5 is a schematic diagram of a second example triangle strip having different initiating vertices;

[0025] Figure 6 is a flow chart of an example method for performing multiple viewport transformations on untransformed coordinate data of vertices in a strip;

[0026] Figure 7 is a flow chart of an example method for selecting other vertices from which to obtain viewport information.

[0027] Figure 8 is a block diagram of an example viewport transformation module.

[0028] Fig. 9 is a diagram of an example structure of a vertex buffer.

[0029] Fig.10 is used to store transformed coordinate data for multiple vertices at once Fig. 9 A schematic diagram of an example vertex block of a vertex buffer;

[0030] Fig.11 is used to store the transformed coordinate data for a single vertex at a time Fig. 9 A schematic diagram of an example vertex block of a vertex buffer;

[0031] Fig.12is a diagram showing an example of storing transformed coordinate data in viewport vertex order.

[0032] Fig.13 is a flow chart of an example method for writing transformed coordinate data to a data store.

[0033] Fig.14 is a block diagram of an example computer system in which the viewport transformation module described herein is implemented; and

[0034] Fig.15 is a block diagram of an example integrated circuit manufacturing system for producing an integrated circuit embodying a system for implementing the viewport transformation module described herein. DETAILED DESCRIPTION

[0035] The following description is presented by way of example to enable those skilled in the art to make and use the invention. The invention is not limited to the embodiments described herein, and various modifications to the disclosed embodiments will be apparent to those skilled in the art. The embodiments are described only by way of example.

[0036] Described herein are methods, systems, and viewport transformation modules for predictively performing multiple viewport transformations on untransformed coordinate data for vertices in a strip in an efficient manner. The method includes extracting from a vertex buffer: untransformed coordinate data for vertices in the strip; information identifying a viewport associated with the vertex; and information identifying a viewport associated with at least one other vertex in the strip. The at least one other vertex in the strip is selected based on a triggering vertex of a primitive formed by the vertices in the strip and the number of vertices in the primitive. A transformation is then performed on the untransformed coordinate data for each identified viewport to generate transformed coordinate data for each identified viewport. The transformed coordinate data is then written to the vertex buffer.

[0037] As described in more detail below, the vertex transformation performed on the vertex is based on the primitive of which the vertex forms a part. Specifically, each primitive is associated with the viewport to which the vertex forming the primitive is transformed. Because the vertices of the strip can each form a part of multiple primitives, it may be necessary to perform multiple different viewport transformations for each vertex. Specifically, if the viewports associated with different primitives of which the vertex forms a part are different, multiple viewport transformations must be performed on the vertex. However, the viewports associated with different primitives can be the same, so only one transformation may need to be performed. Therefore, the 3D rendering system can be configured to assemble primitives, determine the viewport associated with the primitive, and then perform the minimum number of transformations for each vertex. However, this requires that the primitives be formed before the viewport transformation. The method, system and viewport transformation module described herein provide an effective way to generate transformed vertex data for the vertices in the strip when the primitives are formed after the viewport transformation by predicting the primitives of which each vertex will form a part, and performing transformations for each primitive of which the vertex is predicted to form a part (regardless of whether the viewport transformation is the same for different primitives). In other words, the methods, systems, and viewport transformation modules described herein assume that the viewport is different for each primitive that a vertex is predicted to form a part of.

[0038] First reference Figure 2 , Figure 2 An example 3D rendering system 200 is shown in which the viewport transformation module described herein may be implemented. The 3D rendering system is designed to render images of a 3D scene. It should be understood that Figure 2 Only some elements of the 3D rendering system are shown, and there may be many elements within the 3D rendering system that are not described. Figure 2 3D rendering system 200 includes a geometry processing block 202 and a rasterization block 204 .

[0039] The geometry processing block 202 receives geometry data from the application 206 and outputs a set of screen primitives (e.g., simple geometric shapes, such as triangles on the screen 208). The geometry data includes information identifying a plurality of vertices (e.g., coordinates of each vertex in world space coordinates), information identifying primitives formed by the vertices, and information identifying a viewport associated with each primitive (e.g., a viewport ID). The geometry processing block 202 includes a primitive processing (PP) block 210 configured to transform the received vertices from a world window (i.e., world space coordinates) to a viewport (i.e., screen space coordinates) using a viewport transformation module (VTM) 212, which is referred to herein as a viewport transformation. The world window is an area that a user wants to visualize in application-specific coordinates (e.g., kilometers or centimeters). In contrast, a viewport is an area of ​​the screen in rendering device-specific coordinates (e.g., pixels) used to display an image of the scene. The viewport may include the entire screen or a portion thereof.

[0040] Viewport transformation is typically performed on a per-primitive basis (i.e., all vertices forming a particular primitive are viewport transformed in the same manner (e.g., transformed to the same viewport)). Many viewport transformation modules in known PP blocks are configured to support a single viewport, and perform a single viewport transformation on each primitive (and each vertex forming the primitive) based on the viewport. However, the viewport transformation module described herein supports multiple viewports to achieve certain visual effects, such as reflections. Therefore, in the viewport transformation module described herein, different viewports can be distributed or assigned to different primitives, whereby multiple viewport transformations based on different viewports can be performed on vertices of different primitives. The number of different viewports supported is device-specific. In some cases, 16 different viewports are supported, but it will be apparent to those skilled in the art that this is merely an example. In the case where a vertex may form part of multiple primitives, this may result in multiple viewport transformations being performed on the same vertex. This is particularly likely to occur if the application 206 sends the vertices as strips to the geometry processing block 202.

[0041] A primitive strip is a series of primitives that share vertices. For example, Figure 3 An example triangle strip 300 is shown that includes a series of primitives (triangles) 302 that share vertices 304. Primitive strips are often used to reduce the amount of data used to define a group of primitives, instead of sending vertex data for each primitive separately. For example, a triangle strip reduces the number of vertices to be sent from 3X to X+2, where X is the number of triangles to be drawn.

[0042] The viewport target for a vertex, and the viewport transformation to be performed, is defined by the primitive(s) to which it belongs. Because the vertices of a strip can form part of multiple primitives, a single vertex can have multiple different viewport targets. For example, in Figure 3, vertex 2 (V-2) forms part of primitive A (PA), primitive B (PB), and primitive C (PC), so vertex 2 (V-2) can have three different viewport targets.

[0043] Thus, the viewport transformation module 212 described herein is configured to perform N viewport transformations on received vertices for each vertex in a strip in an efficient manner, where N is the number of vertices in a primitive.

[0044] Back to Figure 2 The PP block 210 is also configured to form screen space primitives (ie, primitives defined by vertices in screen space coordinates) from the transformed coordinate data, which are forwarded to the rasterization block 204 for processing. Figure 4 To describe an example primitive processing block.

[0045] The rasterization block 204 is configured to receive the screen space primitives generated by the geometry processing block 202 and determine which (or which) primitives are visible at each pixel and then determine the color of each pixel. Because more than one primitive can overlap the same pixel, a depth comparison (e.g., a z-buffer or depth buffer) is performed for each pixel to determine which primitive is visible. For example, a z-buffer (which may also be referred to as a depth buffer) can be used to store the distance of each pixel to the nearest primitive in the scene. Then, if a subsequent primitive of the scene overlaps the same pixel, the depth of the new primitive is compared to the stored depth, and if the new primitive has a depth indicating that it is closer to the pixel, the z-buffer is updated with the new depth value.

[0046] Once the depth values ​​for a set of geometries have been compared to the depth values ​​in the z-buffer, the color value associated with the closest primitive is identified for each pixel. The color of each pixel may be determined by the texture covering the pixel and / or the pixel shader program running on the pixel. The pixel shader program describes the operations to be applied to the pixel. Once the color value has been identified for each pixel, the color value is written to a frame buffer in memory and then displayed on the screen 208.

[0047] Reference now Figure 4 , Figure 4 An example implementation of a primitive processing block 210 in which the viewport transformation module described herein may be implemented is shown. As described above, the primitive processing (PP) block 210 is configured to perform a viewport transformation on vertices generated by the application 206 to transform the vertices from a world window (i.e., world space coordinates) to a viewport (i.e., screen space coordinates); and form screen primitives from the transformed vertices. Figure 4The PP block 210 includes a transaction processing module 402, a viewport transformation module 212, and a primitive construction module 404. In some cases, the PP module 210 may also include a culling module 406.

[0048] Vertex data received from application 206 is stored in vertex buffer 408. For each vertex, vertex data typically includes vertex coordinates in world coordinates (e.g., X, Y, Z, and W), which is referred to as untransformed coordinate data, and other vertex information, such as, but not limited to, information indicating the viewport with which the vertex is associated (e.g., a viewport ID). Vertex data is stored in vertex buffer 408 in vertex tasks that group multiple vertices together. In some examples, a vertex task may include all vertices in a strip (e.g., a triangle strip). Each task and each vertex within a task can be individually addressed in vertex buffer 408. An example structure of vertex buffer 408 will be described below with reference to FIG. Figures 9 and 10 to describe.

[0049] Vertex buffer 408 sends vertex task instructions to transaction module 402 to cause PP block 210 to process vertices associated with a particular task and to keep track of which tasks have been completed (e.g., processed by PP block 210). Vertex task instructions may, for example, specify the base address of the task to be processed in vertex buffer 408, the number of vertices in the task, and a task ID (e.g., task number).

[0050] The transaction processing module 402 is configured to, in response to receiving the vertex task instructions, convert the vertex task instructions into a set of viewport transformation instructions sent to the viewport transformation module 212 and primitive instructions sent to the primitive construction module 404. The viewport transformation instructions cause the viewport transformation module 212 to perform multiple viewport transformations on the vertices in the task.

[0051] Because each vertex may form part of multiple primitives (e.g., triangles) when the application 206 is configured to output vertices as strips, multiple viewport transforms are performed on the vertices in the task. Figure 5A triangle strip 500 is shown having seven vertices (V-0 through V-6) 502 and five primitives (PA through PE) 504 formed by the seven vertices. Three vertices 502 (V-2, V-3, and V-4) in the strip 500 form part of three primitives 504 (e.g., triangles). Specifically, vertex 2 (V-2) forms part of primitives A, B, and C; vertex 3 (V-3) forms part of primitives B, C, and D; and vertex 4 (V-4) forms part of primitives C, D, and E. Because viewport transformations are performed on a per-primitive basis—i.e., all vertices forming a primitive are transformed to the same viewport—vertices forming part of three different primitives may have to be viewport transformed to three different viewports, one for each primitive.

[0052] The viewport transformation performed on the vertices in the task can be determined from the initiating vertex of the primitive. Specifically, in a system where the application 206 is configured to assign each vertex its own viewport (which can be identified by a viewport ID), one of the vertices of the primitive will be the determining vertex or primary vertex for the viewport transformation, which will be referred to herein as the initiating vertex. It is the viewport associated with the initiating vertex of the primitive that controls the viewport transformation of the primitive.

[0053] For example, in the case where the primitives are triangles, each primitive is formed by three vertices - a leading vertex (which can be referred to as vertex 0 of the primitive), a middle vertex (which can be referred to as vertex 1 of the primitive), and a trailing vertex (which can be referred to as vertex 2 of the primitive). Figure 5 For a primitive C (PC), vertex 2 (V-2) is the head vertex, vertex 3 (V-3) is the middle vertex, and vertex 4 (V-4) is the tail vertex. One of the head vertex, the middle vertex, and the tail vertex of the primitive will be the initiating vertex.

[0054] In the case where the head vertex is the initiating vertex (i.e., the initiating vertex is 0), the first vertex of the primitive will determine the viewport transformation for the primitive. For example, as shown in Table 506, when the initiating vertex is the head vertex (i.e., the initiating vertex is 0), the initiating vertices for primitives A, B, C, D, and E will be vertices 0, 1, 2, 3, and 4, respectively. In the case where the middle vertex is the initiating vertex (i.e., the initiating vertex is vertex 1 of the primitive), the second vertex of the primitive will determine the viewport transformation for the primitive. For example, as shown in Table 508, when the initiating vertex is the middle vertex (i.e., the initiating vertex is 1), the initiating vertex for primitives A, B, C, D, and E will be vertices 1, 2, 3, 4, and 5, respectively. Finally, in the case where the tail vertex is the initiating vertex (i.e., the initiating vertex is vertex 2 of the primitive), the third vertex of the primitive will determine the viewport transformation for the primitive. For example, as shown in table 510, when the inciting vertex is the tail vertex (ie, the inciting vertex is 2), the inciting vertices for primitives A, B, C, D, and E will be vertices 2, 3, 4, 5, and 6, respectively.

[0055] When a vertex (e.g., vertex 2 (V-2)) forms part of three different primitives, the vertex will be the head vertex of one primitive, the middle vertex of another primitive, and the tail vertex of yet another primitive. For example, vertex 2 (V-2) is the tail vertex of primitive A (PA), the middle vertex of primitive B (PB), and the head vertex of primitive C (PC). The viewport transformation performed by viewport transformation module 212 is a viewport transformation corresponding to the vertex in each of the different primitive positions. The viewport used when the vertex is in each of these positions will depend on the initiating vertex.

[0056] Specifically, if the triggering vertex is 0 (i.e., the head vertex is the triggering vertex), then when the current vertex is the tail vertex, the relevant viewport will be the viewport associated with the vertex that is the second vertex forward from the current vertex in the triangle strip; when the current vertex is the middle vertex, the relevant viewport is the viewport associated with the vertex immediately before the current vertex in the triangle strip; and when the current vertex is the head vertex, the relevant viewport is the viewport associated with the current vertex. For example, referring to Figure 5 Table 506, when vertex 2 (V-2) is the tail vertex in primitive A (PA), the viewport associated with vertex 0 (V-0) will be used for transformation; when vertex 2 (V-2) is the middle vertex in primitive B (PB), the viewport associated with vertex 1 will be used for transformation; when vertex 2 (V-2) is the head vertex in primitive C (PC), the viewport associated with vertex 2 (V-2) will be used for transformation. Therefore, when the initiating vertex is 0 (i.e., the head vertex is the initiating vertex), the relevant viewports for viewport transformation will be the viewports associated with the current vertex in the strip, and the two previous vertices.

[0057] If the triggering vertex is 1 (i.e., the middle vertex is the triggering vertex), then the relevant viewport will be the viewport associated with the vertex immediately before the current vertex in the triangle strip when the current vertex is the tail vertex; the relevant viewport will be the viewport associated with the current vertex when the current vertex is the middle vertex; and the relevant viewport will be the viewport associated with the vertex immediately after the current vertex in the triangle strip when the current vertex is the head vertex. For example, refer to Figure 5 Table 508, when vertex 2 (V-2) is the tail vertex in primitive A (PA), the viewport associated with vertex 1 (V-1) will be used; when vertex 2 (V-2) is the middle vertex in primitive B (PB), the viewport associated with vertex 2 (V-2) will be used; when vertex 2 (V-2) is the head vertex in primitive C (PC), the viewport associated with vertex 3 (V-3) will be used. Therefore, when the initiating vertex is 1 (i.e., the middle vertex is the initiating vertex), the relevant viewports will be those associated with the current vertex in the strip, and the vertices immediately before and after the current vertex.

[0058] If the triggering vertex is 2 (i.e., the tail vertex is the triggering vertex), then the relevant viewport will be the viewport associated with the current vertex when the current vertex is the tail vertex; the relevant viewport will be the viewport associated with the vertex immediately after the current vertex in the triangle strip when the current vertex is the middle vertex; and the relevant viewport will be the viewport associated with the vertex that is the second vertex after the current vertex in the triangle strip when the current vertex is the head vertex. For example, refer to Figure 5 Table 510, when vertex 2 (V-2) is the tail vertex in primitive A (PA), the viewport associated with the current vertex will be used; when vertex 2 (V-2) is the middle vertex in primitive B (PB), the viewport associated with vertex 3 (V-3) will be used; and when vertex 2 (V-2) is the head vertex in primitive C (PC), the viewport associated with vertex 4 (V-4) will be used. Therefore, when the initiating vertex is 2 (i.e., the tail vertex is the initiating vertex), the relevant viewports will be those associated with the current vertex and the two subsequent vertices in the strip.

[0059] Therefore, in the examples described herein, the viewport transformation module 212 is configured to perform multiple viewport transformations on each vertex in the task based on the initiating vertex. For example, in the case where the primitive is a triangle, the viewport transformation module 212 can be configured to: when the initiating vertex is a head vertex, perform a viewport transformation on the current vertex based on the viewport associated with the current vertex and the two immediately preceding vertices; when the initiating vertex is a middle vertex, perform a viewport transformation on the current vertex based on the viewport associated with the current vertex, the immediately preceding vertex, and the immediately subsequent vertex; and when the initiating vertex is a tail vertex, perform a viewport transformation on the current vertex based on the viewport associated with the current vertex and the two vertices immediately following the current vertex.

[0060] return Figure 4 In some cases, the transaction module 402 may be configured to send a single viewport transformation instruction to the viewport transformation module 212 for each vertex in the task, the single viewport transformation instruction causing the viewport transformation module 212 to perform multiple viewport transformations on the vertex. Such a viewport transformation instruction may include, for example, information indicating the location of the vertex data in the vertex buffer 408 (e.g., the base address of the vertex). In some cases, the transaction module 402 may be configured to determine the associated viewport to be used for the viewport transformation from the initiating vertex. In these cases, the viewport transformation instruction may also include information indicating the associated viewport to be used for the transformation (e.g., the address of the associated viewport). In the event that the viewport transformation instruction does not include information indicating the viewport to be used in the transformation, the viewport transformation module 212 itself may be configured to determine the associated viewport to be used for the transformation from the initiating vertex.

[0061] However, in other cases, the transaction module 402 may be configured to send a viewport transformation instruction to the viewport transformation module 212 for each viewport transformation to be performed. In these cases, the transaction module 402 may be configured to determine the appropriate viewport to be used for the viewport transformation from the initiating vertex information for each vertex in the received task, and send N viewport transformation instructions to the viewport transformation module 212 - one viewport transformation instruction for each viewport transformation to be performed. The viewport transformation instructions in these cases may include information indicating the location of the vertex in the vertex buffer 408 (e.g., the base address of the vertex), and information identifying the viewport to be used for the transformation (e.g., the address of the viewport ID in the vertex buffer 408).

[0062] The viewport transformation module 212 is configured to extract, for each vertex in the task, untransformed coordinate data (e.g., normalized X, Y, Z, and W coordinates in world space) from the vertex buffer 408, extract information identifying the viewport associated with the vertex from the vertex buffer 408, and extract information identifying the viewport associated with at least one other vertex in the strip (based on the initiating vertex information) from the vertex buffer 408. The viewport transformation module 212 then performs a viewport transformation on the untransformed coordinate data for each identified viewport to generate transformed coordinate data (e.g., X, Y, Z, and W in screen space) for each identified viewport. The viewport transformation module 212 then writes the transformed coordinate data (e.g., X, Y, Z, and W in screen space) for each identified viewport to the vertex buffer 408 for subsequent retrieval by the primitive construction module 404 to form primitives therefrom.

[0063] Reference will be made below Figure 12 to Figure 13 In some cases described, the viewport transformation module 212 may be configured to write the transformed coordinate data to the vertex buffer 408 so that the transformed coordinate data for the primitive can be obtained from the same location in the vertex buffer 408 (regardless of the initiating vertex). Figure 6 An example method for generating transformed coordinate data for a vertex is described below. Figure 8 Example implementations of the viewport transformation module 212 are described.

[0064] The primitive construction module 404 is configured to generate primitives based on the transformed coordinate data stored in the vertex buffer 408. The primitive construction module 404 can receive primitive instructions from the transaction processing module 402, which provide details of the next task to be processed by the primitive construction module 404. Once the primitive construction module 404 has received the primitive instructions, the primitive construction module 404 waits for a signal or instruction from the viewport transformation module 212 indicating that the vertices of the task have been transformed; and index data from an external module. The index data includes information indicating how the vertices are related to each other to form a primitive (for example, the index data may indicate the head vertex, middle vertex, and tail vertex of each primitive).

[0065] Once a signal or instruction indicating that the vertices of the task have been transformed is received from the viewport transformation module 212, and the index data has been received, the primitive construction module 404 obtains the transformed coordinate data from the vertex buffer and assembles the transformed coordinate data into primitives according to the index data. Specifically, the primitive construction module 404 identifies the vertices that form each primitive from the index data, and the relationship between these vertices (e.g., the position of the vertices in the primitive - for example, which vertex is the head vertex, which vertex is the middle vertex, and which vertex is the tail vertex). The primitive construction module 404 then obtains the transformed coordinate data for each vertex (corresponding to the vertex in the relevant position of the primitive) from the vertex buffer 408 for each primitive.

[0066] As described above, the viewport transformation module 212 is configured to perform, for each vertex, a viewport transformation for each possible position of the vertex in the primitive. For example, in the case where the primitive is a triangle, a viewport transformation is performed for the vertex as the head vertex of the primitive, a viewport transformation is performed for the vertex as the middle vertex of the primitive, and a viewport transformation is performed for the vertex as the tail vertex of the primitive. The primitive construction module obtains transformed coordinate data (corresponding to the position of the vertex in the primitive) from the vertex buffer 408 for each vertex in the primitive; and then forms the primitive from the transformed coordinate data.

[0067] For example, if the primitive is a triangle and the index data indicates that there is a primitive formed by vertices C, D, and E (where C is a head vertex, D is an intermediate vertex, and E is a tail vertex), the vertex buffer 408 will include three sets of transformed coordinate data for each of the vertices C, D, and E - one set corresponding to the vertex as a head vertex, one set corresponding to the vertex as an intermediate vertex, and one set corresponding to the vertex as a tail vertex. In this example, to form the C, D, E primitive, the primitive construction module obtains (e.g., retrieves): the transformed coordinate data for vertex C in the vertex buffer 408 (corresponding to vertex C as the head vertex), the transformed coordinate data for vertex D in the vertex buffer 408 (corresponding to vertex D as the intermediate vertex), and the transformed coordinate data for vertex E (corresponding to vertex E as the tail vertex).

[0068] The primitive construction module then groups the data together to form primitives. Specifically, the primitive construction module assigns or maps indices in the index data to each set of transformed coordinate data of the primitive (i.e., each vertex), and links these indices together to form primitives. Accordingly, in the case where three different viewport transformations are performed on the vertex, the vertex will be mapped to three different indices. In some cases, the primitive construction module can also be configured to convert the transformed coordinate data from one format to another (e.g., from 32-bit floating point values ​​to 16.8 fixed point values).

[0069] Although primitive construction module 404 has been described above as receiving index data from an external module indicating how vertices are related to each other to form primitives, in other examples, primitive construction module 404 may not receive index data. In these examples, because the vertices are in strips, primitive construction module 404 may be configured to (i) identify primitives based on the order of the vertices in the strips, and (ii) generate (as opposed to map) an index for each set of transformed coordinate data (i.e., each vertex) for the primitive.

[0070] Once the primitives have been assembled, the primitive construction module 404 outputs the primitives for further processing.

[0071] In some cases, the PP block 210 may also include a culling module 406. The culling module 406 is configured to receive primitives generated by the primitive building module 404 and remove any redundant primitives to reduce the workload on the remaining modules of the geometry processing block 202 and the rasterization block 204. Many different methods can be used to identify primitives that are redundant and can thus be removed. The culling module 406 can be configured to identify redundant primitives using any appropriate method or combination of methods. For example, in some cases, the culling module 406 can be configured to remove any of the following primitives: primitives that are far away from the user; primitives that are completely off the screen; primitives that are completely outside the clipping plane; primitives that have a bounding box that does not cover any sample points; and / or primitives that do not cover any sample points.

[0072] Reference now Figure 6 , Figure 6An example method 600 for generating transformed coordinate data for a vertex that may be implemented by the viewport transformation module 212 is shown. The method 600 begins at block 602, where the viewport transformation module 212 extracts untransformed coordinate data for a vertex (i.e., a current vertex) from a data store (e.g., a vertex buffer 408). In some cases, block 602 may be initiated in response to the viewport transformation module 212 receiving a viewport transformation instruction from the transaction module 402. The viewport transformation module may be configured to extract the untransformed coordinate data from the data store (e.g., the vertex buffer 408) by performing a read request of a specific address of the data store. Depending on the size of the untransformed coordinate data, the viewport transformation module 212 may be configured to extract the untransformed coordinate data within a few clock cycles. For example, in some cases, the viewport transformation module 212 may be configured to request a first coordinate (e.g., an X coordinate) in a first clock cycle, and request subsequent coordinates (e.g., Y, Z, and W) in subsequent clock cycles.

[0073] At block 604, the viewport transformation module 212 extracts information indicating the viewport with which the vertex of block 602 (referred to herein as the current vertex) is associated from a data store (e.g., vertex buffer 408). As described above, the application 206 assigns a viewport to each vertex. In some cases, there will be a fixed number (e.g., 16) of viewports, and each of these viewports can be identified by a viewport ID. In these cases, the geometry data received from the application typically includes a vertex ID in addition to untransformed coordinate data for each vertex (e.g., the vertex's X, Y, X, and W coordinates in world space), and the viewport transformation module 212 is configured to extract the viewport ID associated with the current vertex.

[0074] At block 606, the viewport transformation module 212 extracts information indicating a viewport associated with at least one other vertex of the strip from a data store (e.g., vertex buffer 408). Where each vertex is associated with a viewport ID (identifying the viewport associated with the vertex), the viewport transformation module 212 may be configured to extract the viewport ID associated with the at least one other vertex from the data store (e.g., vertex buffer 408).

[0075] The number of other vertices for which viewport information is extracted depends on the number of vertex transformations that the viewport transformation module is to perform on each vertex. As described above, the viewport transformation module is configured to perform a transformation for each possible vertex position in the primitive. Since the number of possible vertex positions (e.g., head vertex, midpoint vertex, tail vertex) in the primitive is equal to the number of vertices in the primitive, if each primitive has N vertices, there will be N-1 other vertices (for which viewport information is extracted). For example, if the primitive is a triangle (N=3), viewport information for two (N-1) other vertices will be extracted. The vertices for which viewport information is obtained are referred to as viewport vertices in this article.

[0076] The specific viewport vertex is determined based on the triggering vertex. As described above, the triggering vertex indicates which vertex in the primitive controls the viewport transformation-that is, the viewport associated with the triggering vertex is used to perform the viewport transformation. When the current vertex is located at one of the primitive positions (for example, when the current vertex is the tail vertex, the middle vertex, or the head vertex), the current vertex will be the triggering vertex. When the current vertex is located at other primitive positions, other viewport vertices are triggering vertices. For example, if the primitive is a triangle and the triggering vertex is 0 (that is, the triggering vertex is the head vertex), then when the current vertex is the head vertex, the current vertex is the triggering vertex of the primitive. Therefore, when the current vertex is the middle vertex of the primitive and the tail vertex of the primitive, the viewport information for the vertex that is the triggering vertex is also obtained. In this example, when the current vertex is the middle vertex of the primitive, the triggering vertex will be the vertex immediately before the current vertex, and when the current vertex is the tail vertex of the primitive, the triggering vertex will be the vertex that is the second vertex from the current vertex forward. Accordingly, in this example, viewport information for the vertex immediately before the current vertex and viewport information for the vertex that is the second vertex from the current vertex will be extracted. Table 1 summarizes the case where the primitive is a triangle.

[0077] Table 1

[0078]

[0079] Reference below Figure 7 An example method for identifying viewport vertices when primitives are triangles is described.

[0080] At block 608, the viewport transformation module 212 performs a viewport transformation on the untransformed coordinate data (e.g., X, Y, Z, and W in world space coordinates) for each identified viewport to generate transformed coordinate data (e.g., X, Y, Z in screen space coordinates) for each identified viewport.

[0081] At block 610, the viewport transformation module 212 writes the transformed coordinate data for each identified viewport to a data store (eg, vertex buffer 408). Figure 12 to Figure 13 To describe in more detail, in some cases, the viewport transformation module 212 may be configured to write the transformed coordinate data for different viewports to a data store (e.g., vertex buffer 408) such that the transformed coordinate data is stored in a particular order so that downstream components (e.g., primitive construction modules) can easily retrieve the relevant transformed coordinate data from the data store (e.g., vertex buffer 408). For example, in some cases, the viewport transformation module 212 may be configured to write the transformed coordinate data for each identified viewport to a data store (e.g., vertex buffer 408) such that the transformed coordinate data is stored in viewport vertex order.

[0082] Although Figure 6 The blocks of method 600 are shown as being executed sequentially, but it is apparent to one skilled in the art that they may be executed in a different order. For example, it is apparent to one skilled in the art that blocks 602, 604, and 606 may be executed in any order and may be executed within a few cycles. Figure 6 An approach is shown in which all viewport transformations are performed on untransformed coordinate data and then all sets of transformed coordinate data are written to a data store (e.g., vertex buffer 408), but in other examples, viewport transformation module 212 may be configured to write transformed coordinate data to a data store (e.g., vertex buffer 408) as transformed coordinate data for a particular viewport transformation becomes available (instead of waiting for all viewport transformations to be completed).

[0083] Reference now Figure 7 , Figure 7 An example method 700 for selecting other viewport vertices (vertices that provide a viewport to be used in a viewport transform) that can be implemented by the transaction module 402 or the viewport transform module 212 when the primitives are triangles is shown. When the primitives are triangles, each primitive has three vertices, and therefore each vertex has three possible primitive positions. As a result, three viewport transforms are performed - one transform based on the viewport associated with the current vertex, and two transforms based on the viewports associated with the other two vertices in the strip. Figure 7 The method 700 is an example method for selecting two other vertices based on an inciting vertex. As described above, the transaction module 402 or the viewport transformation module 212 can be configured to identify other viewport vertices.

[0084] The method 700 begins at block 702, where the transaction module 402 or the viewport transformation module 212 determines whether the initiating vertex is 0 (i.e., whether the initiating vertex is the head vertex of a triangle primitive). If it is determined at block 702 that the initiating vertex is 0, the method 700 proceeds to block 704, where the viewports associated with the two vertices immediately preceding the current vertex in the strip are selected as the other viewport vertices. This is because, as described above with reference to Figure 5 Description, if the triggering vertex is 0 (that is, if the triggering vertex is the head vertex), then when the current vertex is the tail vertex, the triggering vertex is the vertex that is the second vertex forward from the current vertex; when the current vertex is the middle vertex, the triggering vertex is the vertex immediately before the current vertex; and when the current vertex is the head vertex, the current vertex will be the triggering vertex.

[0085] However, if it is determined at block 702 that the inciting vertex is not 0, the method 700 proceeds to block 706, where the transaction module 402 or the viewport transformation module 212 determines whether the inciting vertex is 1 (i.e., whether the inciting vertex is an intermediate vertex of a triangle primitive). If it is determined at block 706 that the inciting vertex is 1, the method 700 proceeds to block 708, where the viewports associated with the vertex immediately before the current vertex in the strip and the vertex immediately after the current vertex in the strip are selected as the other viewport vertices. This is because, as described above with reference to Figure 5 Described, if the triggering vertex is 1 (that is, if the triggering vertex is the middle vertex), then when the current vertex is the tail vertex, the triggering vertex is the vertex immediately before the current vertex in the strip; when the current vertex is the middle vertex, the triggering vertex is the current vertex; and when the current vertex is the head vertex, the triggering vertex is the vertex immediately after the current vertex in the strip.

[0086] However, if it is determined at block 706 that the initiating vertex is not 1, then the method 700 proceeds to block 710, where the transaction module 402 or the viewport transformation module 212 determines whether the initiating vertex is 2 (i.e., whether the initiating vertex is the trailing vertex of the triangle primitive). If it is determined at block 710 that the initiating vertex is 2, then the method 700 proceeds to block 712, where the viewports associated with the two vertices immediately following the current vertex in the strip are selected as the other viewport vertices. This is because, as described above with reference to Figure 5 Described, if the triggering vertex is 2 (i.e., if the triggering vertex is the tail vertex), then when the current vertex is the tail vertex, the triggering vertex is the current vertex; when the current vertex is the middle vertex, the triggering vertex is the vertex immediately after the current vertex in the strip; and when the current vertex is the head vertex, the triggering vertex is the second vertex after the current vertex in the strip.

[0087] Figure 6-7Described is that N viewport transformations are performed on each vertex in a strip based on the viewport associated with the vertex and the viewport associated with one or more vertices before and / or after the vertex in the strip. A vertex near the start or end of a strip (which will be referred to as an edge vertex in this article) may not have the required number of vertices before or after the vertex in the strip. For example, the first vertex in a strip does not have any previous vertices in the strip. Therefore, for edge vertices in a strip, it may not be possible to perform transformations based on the viewports associated with previous and / or subsequent vertices. In some cases, the viewport transformation module can be configured to perform less than N viewport transformations for edge vertices. For example, in the case where the triggering vertex is a head vertex, there are no two vertices before the vertex in the strip, so only one viewport transformation can be performed, which is based on the viewport associated with the vertex. However, in other cases, the viewport transformation module can be configured to still perform N viewport transformation modules on edge vertices, and use a pseudo viewport or a default viewport for any non-existent previous or subsequent vertices. Although such a transformation is performed, the corresponding transformed coordinate data will not be used to form any subsequent vertices, so the actual viewport transformation performed is irrelevant. An alternative approach may include requesting and / or obtaining information identifying the viewport associated with one or more vertices located before and / or after the strip (e.g., where the strip being processed forms part of a larger strip), so that all N viewport transformations can be performed using the correct viewport.

[0088] Reference now Figure 8 , Figure 8 An example implementation of the viewport transformation module 212 is shown. As described above, the viewport transformation module is configured to perform N viewport transformations on the vertices in a strip, where N is the number of vertices in each primitive. Figure 8 The viewport transformation module 212 includes an extraction module 802 , a processing module 804 , and a writing module 806 .

[0089] The extraction module 802 is configured to receive a viewport transformation instruction (e.g., from the transaction processing module 402) identifying a vertex to be transformed, and extract the untransformed coordinate data for the vertex from a data store (e.g., a vertex buffer 408). In some cases, the viewport transformation instruction includes an address (e.g., a vertex base address) identifying the beginning of the vertex data in the data store (e.g., the vertex buffer 408). The vertex data stored for each vertex data store typically includes untransformed coordinate data (e.g., X, Y, X, and W in world space coordinates) and other data (e.g., VPT ID). The extraction module 802 determines the address of the untransformed coordinate data from the information identifying the beginning of the vertex data (e.g., the vertex base address), and sends a read request for the address to the data store (e.g., the vertex buffer 408). Depending on the size of the untransformed coordinate data, the extraction module 802 can be configured to extract each individual untransformed coordinate separately through a separate extraction request. For example, the extraction module 802 can be configured to request an untransformed X coordinate in a first clock cycle, request an untransformed Y coordinate in a second clock cycle, and so on.

[0090] The extraction module 802 is also configured to extract (or obtain) information identifying a viewport associated with the vertex to be transformed (which may be referred to herein as the current vertex) from a data store (e.g., vertex buffer 408), and to extract (or obtain) information identifying a viewport associated with N-1 other vertices in the strip from a data store (e.g., vertex buffer 408), where N is the number of vertices in the primitive. As described above, each vertex may be assigned a viewport (or associated with a viewport identified by a viewport (VPT) ID). The VPT ID is stored in the data store as part of the vertex data for each vertex. In these cases, the extraction module 802 may be configured to obtain the VPT ID associated with the vertex to be transformed, and the VPT IDs of the N-1 vertices in the strip, which may, for example, include sending a read request for each desired VPT ID to the data store (e.g., vertex buffer 408).

[0091] In some cases, the viewport transform instruction will include information identifying the VPT ID to be obtained, and the extraction module 802 simply obtains the identified VPT ID. For example, the viewport transform instruction may include the address / location of a data store (e.g., vertex buffer 408) where the associated VPT ID can be found. However, in other cases, the extraction module 802 or other logic (not shown) in the viewport transform module 212 may be configured to identify the VPT ID to be obtained based on the number of initiating vertices and vertices in each primitive. For example, in the case where the primitives are triangles (i.e., each primitive has 3 vertices), the extraction module 802 or other logic of the viewport transform module 212 may be configured to use the information described above with reference to FIG. Figure 7 Method 700 is described to select additional VPT IDs to obtain.

[0092] In some cases, the VPT IDs extracted (or obtained) from the data store (e.g., vertex buffer 408) may be stored in a cache in association with, for example, the vertices with which they are associated, and / or the addresses of the data stores (e.g., vertex buffer 408) from which they were extracted. In these cases, when the extraction module 802 wants to extract (or obtain) the VPT ID associated with a particular vertex, the extraction module 802 may be configured to first check whether the VPT ID associated with the particular vertex is located in the cache (and thus has already been extracted from the data store (e.g., vertex buffer 408)). Because the VPT IDs associated with most vertices will be used N times, this can significantly reduce the number of reads performed on the data store (e.g., vertex buffer 408).

[0093] In some cases, the untransformed coordinate data, as well as information identifying the viewports associated with the vertex to be transformed and the N-1 other vertices (e.g., VPT IDs), are stored in the vertex data buffer 808 (e.g., a FIFO (first-in, first-out) buffer) in the order in which they will be processed until the processing module 804 is ready to perform a viewport transformation on the data. Figure 8 A single vertex data buffer 808 is shown, but in other examples, there may be multiple data buffers for storing untransformed coordinate data. For example, there may be a data buffer for storing untransformed X, Y, and Z coordinates, and another data buffer for storing untransformed W coordinates.

[0094] The processing module 804 includes a series of ALUs (arithmetic logic units) configured to perform a viewport transformation on untransformed coordinate data (e.g., X, Y, Z, and W in world space coordinates) to generate transformed coordinate data for a particular viewport (e.g., X, Y, Z, and W in screen space coordinates). The processing module 804 receives the untransformed coordinate data (e.g., X, Y, Z, and W in world space coordinates) from the vertex data buffer 808 and receives an indication of the viewport to which the coordinate data is to be transformed.

[0095] In some cases, each possible viewport is associated with a set of coefficients that drives the ALU to transform the untransformed coordinate data to the viewport. In these cases, the viewport transformation module 212 may include a coefficient storage module 810 that stores coefficients for each possible viewport. In some cases, the coefficients and their associated VPT IDs may be received from the application 206 as part of the state information and then stored in the coefficient storage module 810. The coefficients for a specific viewport are then selected from the coefficient storage module 810 by the VPT ID. In other words, the VPT ID serves as an index to the coefficient storage module 810. In these cases, when the untransformed coordinate data (e.g., X, Y, Z, W) is provided to the processing module 804 for processing, the VPT ID associated with the viewport transformation to be performed is provided to the coefficient storage module 810, which enables the coefficient storage module 810 to provide the coefficient set associated with the appropriate viewport to be provided to the processing module 804.

[0096] The processing module 804 is configured to perform one viewport transformation at a time and output the transformed coordinate data (e.g., X, Y, Z, and W in screen space coordinates). Because N transformations will be performed on the same untransformed coordinate data (e.g., X, Y, Z, and W), the processing module 804 will perform N passes or iterations of the untransformed coordinate data. In some cases, the processing module 804 is configured to perform the viewport transformation based on the viewport associated with the current vertex in a first pass or iteration, and to perform the viewport transformation based on the viewport associated with other vertices in the strip in subsequent passes or iterations. As described below, in some cases, the transformed coordinate data for different passes or iterations are stored in a data store (e.g., vertex buffer 408) in a predetermined order (so that downstream components (e.g., primitive construction module 404) can more easily extract the transformed coordinate data from the data store (e.g., vertex buffer 408) later). In these cases, performing the viewport transformation in this order makes it easier for the viewport transformation module 212 (or the transaction module 402) to calculate the address of the data store (e.g., vertex buffer 408) to which the transformed coordinate data will be written. It will be apparent to those skilled in the art that this is merely an example and that the viewport transformation may be performed in a different order. For example, in other cases, the viewport transformation may be performed in viewport vertex order (i.e., the order in which the vertices associated with the identified viewports are in the stripe).

[0097] The write module 806 receives the transformed coordinate data (e.g., X, Y, Z, and W in screen space coordinates) and writes the transformed coordinate data (e.g., X, Y, Z, and W in screen space coordinates) to a data storage (e.g., vertex buffer 408). In some cases, the write module 806 can be configured to write the transformed coordinate data to a data storage (e.g., vertex buffer 408) so that the transformed coordinate data for different viewports are stored in the data storage (e.g., vertex buffer 408) in a specific order so that the downstream module (e.g., primitive construction module 404) can more easily obtain the appropriate transformed coordinate data from the data storage (e.g., vertex buffer 408).

[0098] For example, as shown below Figure 12 to Figure 13As described, write module 806 may be configured such that transformed coordinate data for vertices (e.g., X, Y, Z, and W in screen space coordinates) is stored in a data store (e.g., vertex buffer 408) in an order corresponding to the order of the viewport vertices in a strip. For example, if viewports associated with vertices 1, 2, and 3 are used for viewport transformation, and vertex 1 is located before vertex 2 in the strip and vertex 2 is located before vertex 3 in the strip, then transformed coordinate data based on the viewport associated with vertex 1 (e.g., X, Y, Z, and W in screen space coordinates) may be stored at a first location (e.g., base address + 0) in a data store (e.g., vertex buffer 408), transformed coordinate data based on the viewport associated with vertex 2 (e.g., X, Y, Z, and W in screen space coordinates) may be stored at a next location (e.g., base address + 1) in the data store (e.g., vertex buffer 408), and transformed coordinate data based on the viewport associated with vertex 3 (e.g., X, Y, Z, and W in screen space coordinates) may be stored at the next location (e.g., base address + 2) in the data store (e.g., vertex buffer 408).

[0099] In other words, the transformed coordinate data based on different viewports can be understood as being stored at different offsets from the base address in the data store (e.g., vertex buffer 408), where the offset indicates the order of the transformed coordinate data in the data store. In the case where the transformed coordinate data is stored in the data store (e.g., vertex buffer 408) in an order corresponding to the order of the viewport vertices in the stripe, the transformed coordinate data based on the viewport associated with the first viewport vertex in the stripe can be written to the base address plus offset 0, the transformed coordinate data based on the viewport associated with the second viewport vertex in the stripe can be written to the base address plus offset 1, the transformed coordinate data based on the viewport associated with the third viewport vertex in the stripe can be written to the base address plus offset 2, and so on.

[0100] In some examples, the transaction module 402 may be configured to determine the appropriate offset for each viewport transformation based on the order of the viewport vertices in the strip, and send the determined offset(s) to the viewport transformation module 212 as part of the viewport transformation instruction(s). In other examples, the viewport transformation module 212 itself may be configured to determine the offset for each viewport transformation based on the order of the viewport vertices in the strip. In other examples, the transaction module 402 may be configured to provide information to the viewport transformation module 212 that allows the viewport transformation module 212 to determine the appropriate offset without determining the order of the viewport vertices in the strip.

[0101] For example, in some cases, the transaction module 402 may be configured to cause the viewport transformation module 212 to perform viewport transformations in a predetermined order and provide information indicating which is the first viewport transformation, which is the second viewport transformation, and so on as part of the viewport transformation instruction(s). For example, the transaction module 402 may be configured to cause the viewport transformation module 212 to first perform the viewport transformation corresponding to the viewport of the current vertex and then perform the viewport transformations corresponding to the viewports of the other vertices in sequence. The transaction module 402 may then include information associating each viewport transformation with an iteration or pass number in the viewport transformation instruction(s). The viewport transformation module 212 may then use the pass or iteration information in conjunction with the initiating vertex to identify the offset to be used to store the transformed coordinate data for each viewport transformation.

[0102] For example, if the primitive is a triangle and the initiating vertex is a head vertex, the viewport vertices will be the current vertex and the two vertices immediately preceding the current vertex. If during a first pass or iteration, the viewport transformation module 212 is configured to perform a viewport transformation based on the viewport associated with the current vertex, then the viewport transformation is associated with the third viewport vertex in the strip, and thus the associated transformed coordinate data should be stored in the third position (i.e., offset 2). If during a second pass or iteration, and a third pass or iteration, the viewport transformation module 212 is configured to perform a viewport transformation based on the viewport associated with the vertex that is the second vertex forward from the current vertex, and based on the viewport associated with the vertex preceding the current vertex, respectively, then these viewport transformations are associated with the first viewport vertex and the second viewport vertex in the strip, and thus the associated transformed coordinate data should be stored in the first position and the second position (i.e., offsets 0 and 1), respectively. Therefore, if the initiating vertex is a head vertex, the viewport transformation module 212 can be configured to use offset 2 during the first iteration, offset 0 during the second iteration, and offset 1 during the third iteration.

[0103] Similarly, if the primitive is a triangle and the inciting vertex is an intermediate vertex, the viewport vertices will be the current vertex, the vertex immediately before the current vertex, and the vertex immediately after the current vertex in the strip. If during the first pass or iteration, the viewport transformation module 212 is configured to perform viewport transformations based on the viewport associated with the current vertex, then the viewport transformation is associated with the second viewport vertex in the strip, and thus the associated transformed coordinate data should be stored in the second location (i.e., offset 1). If during the second pass or iteration, and the third pass or iteration, the viewport transformation module 212 is configured to perform viewport transformations based on the viewport associated with the vertex before the current vertex, and based on the viewport associated with the vertex after the current vertex, then these viewport transformations are associated with the first viewport vertex and the third viewport vertex in the strip, and thus the associated transformed coordinate data should be stored in the first location and the third location (i.e., offset 0 and 2), respectively. Thus, if the inciting vertex is an intermediate vertex, the viewport transformation module 212 may be configured to use an offset of 1 during a first iteration, an offset of 0 during a second iteration, and an offset of 2 during a third iteration.

[0104] This is summarized in Table 2.

[0105] Table 2

[0106]

[0107]

[0108] Reference now Fig. 9 , Fig. 9 is a block diagram showing an example structure of vertex buffer 408. Fig. 9 , the vertex buffer 408 is divided into a plurality of vertex blocks 902, wherein each vertex block 902 is configured to store vertex data (including transformed coordinate data and untransformed coordinate data) for a plurality of vertices. Each vertex block 902 is divided into a transformed coordinate data portion 904, an untransformed coordinate data portion 906, and an “other” vertex data portion 908. The transformed coordinate data portion 904 is used to store the transformed coordinate data for the associated vertex, the untransformed coordinate data portion 906 is used to store the untransformed coordinate data for the associated vertex, and the “other” vertex data portion 908 is configured to store other data related to the vertex, for example, a VPT ID associated with each vertex, and other status information. Therefore, the extraction module 802 of the viewport transformation module 212 is configured to read from the untransformed coordinate data portion 906, and the writing module 806 of the viewport transformation module 212 is configured to write to the transformed coordinate data portion 904.

[0109] Reference now Fig.10, Fig.10 An example structure of a vertex block 902 known to an application (which does not necessarily mean that the structure is known) configured to store untransformed coordinate data and transformed coordinate data for multiple vertices (transformed by the viewport in parallel) is shown. Each portion 904, 906, 908 of the vertex block 902 includes a plurality of rows and columns for holding data associated with four vertices (numbered 0 to 3 in this example). In some examples, each column is 32 bits wide, however, it will be apparent to those skilled in the art that this is merely an example and another number of bits may be used for the columns.

[0110] In this example, the untransformed coordinate data is written to the vertex buffer 408 in column order, while the transformed coordinate data is written to the vertex buffer 408 in row order. For example, the untransformed coordinates (X0, Y0, Z0, and W0) associated with the first vertex (e.g., vertex 0) are written in column 0 rows 5-8, and the untransformed coordinates (X1, Y1, Z1, and W1) for the second vertex (e.g., vertex 1) are written in column 1 rows 5-8; while the transformed coordinates (TX0, TY0, TZ0, and TW0) for the first vertex (e.g., vertex 0) are written in row 0 columns 3 to 0, respectively, and the transformed coordinates (TX1, TY1, TZ1, and TW1) for the second vertex (e.g., vertex 1) are written in row 1 columns 3 to 0, respectively. Testing has shown that in some PP blocks, performance can be improved by storing the transformed coordinates in row order (opposite to column order).

[0111] Fig.10 The transformed coordinate data portion 904 includes four rows, so four sets of transformed coordinate data can be stored at a time. This allows the transformed coordinate data for each vertex transformed for one viewport to be stored. For example, the transformed coordinate data (TX0, TY0, TZ0, TW0) for the first vertex (vertex 0) can be stored in the first row (row 0); the transformed coordinate data (TX1, TY1, TZ1, TW1) for the second vertex (vertex 1) can be stored in the second row (row 1); the transformed coordinate data (TX2, TY2, TZ2, TW2) for the third vertex (vertex 2) can be stored in the third row (row 2); and the transformed coordinate data (TX3, TY3, TZ3, TW3) for the fourth vertex (vertex 3) can be stored in the fourth row (row 3).

[0112] Accordingly, Fig.10The vertex block 902 structure shown in is particularly useful in situations where a single viewport transformation is performed on each vertex and these transformations can be performed in parallel. However, in the embodiments described herein, multiple (i.e., N) transformations are performed on the vertices, thereby requiring the storage of N times the transformed coordinate data. Therefore, in the embodiments described herein, the same vertex block 902 structure will be used in different ways. Specifically, instead of the transformed coordinate data portion 904 being used to store the transformed coordinate data for multiple vertices at one time, the transformed coordinate data portion 904 is used to store multiple sets of transformed coordinate data for a single vertex at one time.

[0113] Reference now Fig.11 , Fig.11 shows how to use the embodiments described herein Fig.10 Specifically, instead of the rows of the transformed coordinate data portion 904 (e.g., rows 0 to 3) being used to store a set of transformed coordinate data for multiple different vertices, the rows of the transformed coordinate data portion 904 (e.g., rows 0 to 3) are used to store multiple sets of transformed coordinate data for the same vertex. For example, the transformed coordinate data (TX0.A, TY0.A, TZ0.A, TW0.A) for the first vertex (e.g., vertex 0) corresponding to the first viewport transformation (A) can be stored in the first row (e.g., row 0); the transformed coordinate data (TX0.B, TY0.B, TZ0.B, TW0.B) for the first vertex (e.g., vertex 0) corresponding to the second viewport transformation (B) can be stored in the second row (e.g., row 1); and the transformed coordinate data (TX0.C, TY0.C, TZ0.C, TW0.C) for the first vertex (e.g., vertex 0) corresponding to the third viewport transformation (C) can be stored in the third row (row 2).

[0114] Using the transformed coordinate data portion 904 of the vertex block 902 in this manner causes the transformed coordinate data portion 904 to be reused or overwritten for each vertex in the vertex block 902. For example, in the vertex block 902, the transformed coordinate data portion 904 is first written with the transformed coordinate data for the first vertex (e.g., Vertex 0), then written with the transformed coordinate data for the second vertex (e.g., Vertex 1), then written with the transformed coordinate data for the third vertex (e.g., Vertex 2), and finally written with the transformed coordinate data for the fourth vertex (e.g., Vertex 3). However, using the transformed coordinate data portion 904 of the vertex block 902 in this manner allows the same amount of storage of the vertex buffer 408 to be used in the multi-viewport transformation case as compared to the parallel single viewport transformation case.

[0115] As described above, in some cases, the write module 806 is configured to store the transformed coordinate data corresponding to different viewports in a data store (e.g., vertex buffer 408) in a particular order to make it easier for downstream components (e.g., primitive building blocks) to obtain the appropriate transformed coordinate data. Specifically, in some cases, the write module 806 is configured to store the transformed coordinate data for the identified viewport in the order (or reverse order) of the vertices in a strip (e.g., a triangle strip) associated with the identified viewport. For example, if (e.g., according to Figure 7 If the viewport identified by method 700 is associated with vertices 1, 2, and 3, where vertex 1 is located before vertex 2 in the strip and vertex 2 is located before vertex 3 in the strip, the transformed coordinate data based on the viewport associated with vertex 1 can be stored at a first offset (e.g., in row 2), the transformed coordinate data based on the viewport associated with vertex 2 can be stored at a second offset (e.g., in row 1), and the transformed coordinate data based on the viewport associated with vertex 3 can be stored at a third offset (e.g., in row 0).

[0116] Storing the transformed coordinate data in this order ensures that the transformed coordinate data corresponding to the vertex in a particular primitive position will always be at the same location (e.g., offset) of the data store (e.g., vertex buffer 408) regardless of the initiating vertex. For example, this can ensure that when the vertex is a head vertex, the transformed coordinate data of the vertex will always be at offset 0; when the vertex is a middle vertex, the transformed coordinate data of the vertex will always be at offset 1; and when the vertex is a tail vertex, the transformed coordinate data of the vertex will always be at offset 2. This means that, regardless of the initiating vertex, components downstream of the viewport transformation module 212 (e.g., primitive construction module 404) will always be able to find the transformed coordinate data for the vertex in a particular primitive position at the same location in the data store (e.g., vertex buffer 408).

[0117] This will refer to Fig.12 To explain, Fig.12 An example triangle strip 1200 is shown that includes five vertices 1202 (V-0 to V-4) and three primitives 1204 (PA to PC) formed by the five vertices. If the initiating vertex is 0 (i.e., the initiating vertex is the head vertex), then according to Figure 7In the method 700, the viewports associated with the current vertex (i.e., the vertex to be transformed) and the two previous vertices will be used for the viewport transformation. For example, if vertex 2 (V-2) is the current vertex, the viewports associated with vertices 0 (V-0), 1 (V-1), and 2 (V-2) are used for the viewport transformation of the untransformed coordinate data of vertex 2 (V-2). If the transformed coordinate data for vertex 2 (V-2) is stored in the order of viewport vertices, as shown in Table 1206, the transformed coordinate data based on the viewport associated with vertex 0 (TX2.0, TY2.0, TZ2.0, and TW2.0) is stored in row 0, the transformed coordinate data based on the viewport associated with vertex 1 (TX2.1, TY2.1, TZ2.1, and TW2.1) is stored in row 1, and the transformed coordinate data based on the viewport associated with vertex 2 (TX2.2, TY2.2, TZ2.2, and TW2.2) is stored in row 2. This means that the transformed coordinate data corresponding to Vertex 2 as a tail vertex (e.g., when it is part of primitive A) is in row 0, the transformed coordinate data corresponding to Vertex 2 as a middle vertex (e.g., when it is part of primitive B) is in row 1, and the transformed coordinate data corresponding to Vertex 2 as a head vertex (e.g., when it is part of primitive C) is in row 2.

[0118] If the triggering vertex is 1 (i.e., the triggering vertex is an intermediate vertex), then according to Figure 7In the method 700, the viewports associated with the current vertex (i.e., the vertex to be transformed), the vertex before the current vertex, and the vertex after the current vertex will be used for viewport transformation. For example, if vertex 2 (V-2) is the current vertex, the viewports associated with vertices 1 (V-1), 2 (V-2), and 3 (V-3) are used for viewport transformation for the untransformed coordinate data of vertex 2 (V-2). If the transformed coordinate data for vertex 2 (V-2) is stored in the order of viewport vertices, as shown in Table 1208, the transformed coordinate data based on the viewport associated with vertex 1 (TX2.1, TY2.1, TZ2.1, and TW2.1) is stored in row 0, the transformed coordinate data based on the viewport associated with vertex 2 (TX2.2, TY2.2, TZ2.2, and TW2.2) is stored in row 1, and the transformed coordinate data based on the viewport associated with vertex 3 (TX2.3, TY2.3, TZ2.3, and TW2.3) is stored in row 2. This means that the transformed coordinate data corresponding to Vertex 2 as a tail vertex (e.g., when it is part of primitive A) is in row 0, the transformed coordinate data corresponding to Vertex 2 as a middle vertex (e.g., when it is part of primitive B) is in row 1, and the transformed coordinate data corresponding to Vertex 2 as a head vertex (e.g., when it is part of primitive C) is in row 2.

[0119] If the triggering vertex is 2 (i.e., the triggering vertex is the tail vertex), then according to Figure 7In the method 700, the viewports associated with the current vertex (i.e., the vertex to be transformed) and the two vertices after the current vertex will be used for viewport transformation. For example, if vertex 2 (V-2) is the current vertex, the viewports associated with vertices 2 (V-2), 3 (V-3), and 4 (V-4) are used for viewport transformation for the untransformed coordinate data of vertex 2 (V-2). If the transformed coordinate data for vertex 2 (V-2) are stored in the order of viewport vertices, as shown in Table 1210, the transformed coordinate data based on the viewport associated with vertex 2 (TX2.2, TY2.2, TZ2.2, and TW2.2) are stored in row 0, the transformed coordinate data based on the viewport associated with vertex 3 (TX2.3, TY2.3, TZ2.3, and TW2.3) are stored in row 1, and the transformed coordinate data based on the viewport associated with vertex 4 (TX2.4, TY2.4, TZ2.4, and TW2.4) are stored in row 2. This means that the transformed coordinate data corresponding to Vertex 2 as a tail vertex (e.g., when it is part of primitive A) is in row 0, the transformed coordinate data corresponding to Vertex 2 as a middle vertex (e.g., when it is part of primitive B) is in row 1, and the transformed coordinate data corresponding to Vertex 2 as a head vertex (e.g., when it is part of primitive C) is in row 2.

[0120] Thus, by storing the transformed coordinate data for the vertices in the order of the viewport vertices, the transformed coordinate data for the vertices (corresponding to the vertices in a particular primitive position) will be found in the same location (e.g., row) of the data store (e.g., vertex buffer 408) (regardless of, or independent of, the initiating vertex). This allows downstream components (e.g., basic building blocks) to always obtain the transformed coordinate data for the vertices in a particular primitive position from the same location (e.g., row) of the data store (e.g., vertex buffer 408), thereby simplifying the read logic in (one or more) downstream components. Because there are typically more reads of the transformed coordinate data than writes of the transformed coordinate data, performance benefits can be gained by adding complexity on the write side rather than the read side.

[0121] Reference now Fig.13 , Fig.13 An example method 1300 is shown for writing transformed coordinate data to a data store (e.g., vertex buffer 308) such that the transformed coordinate data is stored in an order corresponding to the order of viewport vertices in a strip (i.e., an order corresponding to the order of vertices in strips associated with multiple viewports).

[0122] The method begins at block 1302 (after the viewport transformation module 212 (e.g., the processing module 804) performs a viewport transformation on the untransformed coordinate data for the vertices in a strip for each of a plurality of viewports to generate transformed coordinate data for each of the plurality of viewports, as described above), where the viewport transformation module 212 (e.g., the writing module 806) associates each viewport transformation with a different offset representing the order (of the vertices in the strip associated with the corresponding viewport). For example, as described above, if the identified viewports are associated with vertices 1, 2, and 3 (where vertex 1 is located before vertex 2 in the strip, and vertex 2 is located before vertex 3 in the strip), then the viewport transform (and transformed coordinate data) based on the viewport associated with vertex 1 can be associated with a first offset (e.g., offset 0); the viewport transform (and transformed coordinate data) based on the viewport associated with vertex 2 can be associated with a second offset (e.g., offset 1); and the viewport transform (and transformed coordinate data) based on the viewport associated with vertex 3 can be associated with a third offset (e.g., offset 2). Once the offsets have been associated with the viewport transforms, method 1300 proceeds to block 1304.

[0123] At block 1304, based on the offset associated with the viewport transformation, the transformed coordinate data for each viewport transformation is stored in a separate location in a data store (e.g., vertex buffer 408). In some examples, writing the transformed coordinate data for each viewport transformation to a separate location in the vertex buffer may include, at block 1306, determining an address of the vertex buffer for each viewport transformation based on a base address associated with the vertex and an offset associated with the viewport transformation. For example, the address may be the base address plus the offset. Then, at block 1308, the transformed coordinate data for each viewport transformation is written to the address of the vertex buffer determined for the viewport transformation.

[0124] As described above, in some cases, the offset may correspond to a particular row in a data store (e.g., vertex buffer 408), such that writing the transformed coordinate data to the vertex buffer includes writing the transformed coordinate data for each viewport transform to a different row of the vertex buffer (see, e.g., Fig.11 and Fig.12 and the descriptions associated with them above). Similarly, as referenced above Fig.11 and Fig.12 As described, where the transformed coordinate data includes transformed data for each of a plurality of coordinates (eg, X, Y, Z, and W), each coordinate may be written to a different column of a data store (eg, a vertex buffer).

[0125] In some cases, the viewport transforms may be performed in a predetermined order. For example, the viewport transform corresponding to the viewport of the current vertex may be performed first, and then the viewport transforms corresponding to the viewports of other vertices may be performed in the order of those vertices in the strip. In these cases, each viewport transform for a vertex is associated with an iteration number / identifier that indicates the order of the viewport transform compared to the other viewport transforms for that vertex. For example, the first viewport transform performed may be associated with a first iteration number, the second viewport transform performed may be associated with a second iteration number, and so on. The iteration number may then be used in conjunction with the initiating vertex to determine which offset is associated with each viewport transform.

[0126] For example, where the primitive is a triangle formed by a head vertex, a middle vertex, and a tail vertex, and the viewport transformation is performed in the order described above, the viewport transformation may be associated with an offset (given in Table 2 based on the iteration number and the inciting vertex). For example, when the inciting vertex is the head vertex, the viewport transformation performed in the first iteration may be associated with the third offset; when the inciting vertex is the middle vertex, the viewport transformation performed in the first iteration may be associated with the second offset; and when the inciting vertex is the tail vertex, the viewport transformation performed in the first iteration may be associated with the first offset.

[0127] As described above, storing the transformed coordinate data in the vertex buffer in an order corresponding to the order (of the vertices associated with the viewport in the strip) ensures that the viewport transformation corresponding to the vertex in each primitive position is respectively stored in the same position in the data store (e.g., vertex buffer 408) (regardless of the initiating vertex). For example, the transformed coordinate data corresponding to the viewport transformation for the current vertex as a tail vertex can always be stored in row 0 of the data store (e.g., vertex buffer 408); the transformed coordinate data corresponding to the viewport transformation for the current vertex as an intermediate vertex can be stored in row 1 of the data store (e.g., vertex buffer 408); and the transformed coordinate data corresponding to the viewport transformation for the current vertex as a head vertex can be stored in row 2 of the data store (e.g., vertex buffer 408).

[0128] Although Fig.13 An approach is shown in which all viewport transformations are performed on untransformed coordinate data and then all sets of transformed coordinate data are written to a data store (e.g., vertex buffer 408), but in other examples, viewport transformation module 212 may be configured to write transformed coordinate data to a data store (e.g., vertex buffer 408) as soon as transformed coordinate data for a particular viewport transformation is available (instead of waiting for all viewport transformations to be completed).

[0129] Fig.14A computer system is shown in which the viewport transformation module described herein can be implemented. The computer system includes a CPU 1402, a GPU 1404, a memory 1406, and other devices 1414, such as a display 1416, a speaker 1418, and a camera 1420. A viewport transformation module 1410 (corresponding to the viewport transformation module 212 described herein) is shown as being implemented within the GPU 1404. In other examples, the viewport transformation module 1410 can be implemented within the CPU 1402. The components of the computer system can communicate with each other via a communication bus 1422.

[0130] Figure 4 and Figure 8 The PP block 210 and the viewport transformation module 212 are shown as including multiple functional blocks. This is merely schematic and is not intended to define a strict division between the different logical elements of these entities. Each functional block may be provided in any suitable manner. It should be understood that the intermediate values ​​described herein as being formed by the PP block 210 or the viewport transformation module 212 need not be physically generated by the PP block 210 or the viewport transformation module 212 at any point, and may merely represent logical values ​​(which facilitate the description of the processing performed by the PP block 210 or the viewport transformation module 212 between its input and output).

[0131] The viewport transformation module 212 or PP block 210 described herein may be embodied in hardware on an integrated circuit. The viewport transformation module and PP block 210 described herein may be configured to perform any of the methods described herein. Generally, any of the functions, methods, techniques, or components described above may be implemented in software, firmware, hardware (e.g., fixed logic circuits), or any combination thereof. The terms "module," "function," "component," "element," "unit," "block," and "logic" may be used herein to generally represent software, firmware, hardware, or any combination thereof. In the case of software implementation, a module, function, component, element, unit, block, or logic represents a program code that performs a specified task when executed on a processor. The algorithms and methods described herein may be performed by one or more processors that execute (so that (one or more) processors perform) code. Examples of computer-readable storage media include random access memory (RAM), read-only memory (ROM), optical disks, flash memory, hard disk storage, and any other memory device that can use magnetic, optical, and other technologies to store instructions or other data and can be accessed by a machine.

[0132] The terms computer program code and computer readable instructions used herein refer to any type of executable code for a processor, including code expressed in machine language, interpreted language, or scripting language. Executable code includes binary code, machine code, byte code, code defining an integrated circuit (e.g., hardware description language or netlist), and code expressed in programming language code (e.g., C, Java, or OpenCL). Executable code can be, for example, any type of software, firmware, script, module, or library that, when properly executed, processed, interpreted, compiled, executed at a virtual machine or other software environment, causes a processor of a computer system supporting the executable code to perform the tasks specified by the code.

[0133] A processor, computer, or computer system may be any type of device, machine, or special purpose circuit (having processing capabilities so that it can execute instructions), or a collection or part thereof. A processor may be any type of general or special purpose processor, for example, a CPU, a GPU, a system on a chip, a state machine, a media processor, an application specific integrated circuit (ASIC), a programmable logic array, a field programmable gate array, a programmable gate array (FPGA), etc. A computer or computer system may include one or more processors.

[0134] It is also intended to include software that defines a hardware configuration as described herein, for example, HDL (Hardware Description Language) software, such as for designing an integrated circuit or for configuring a programmable chip to perform a desired function. That is, a computer readable storage medium may be provided on which is encoded a computer readable program code in the form of an integrated circuit definition data set, which, when processed in an integrated circuit manufacturing system, configures the system to manufacture a processor configured to perform the method described herein, or to manufacture a processor including any of the apparatus described herein. The integrated circuit definition data set may be, for example, an integrated circuit description.

[0135] A method of manufacturing a viewport transformation module 212 or PP block 210 as described herein at an integrated circuit manufacturing system may be provided. An integrated circuit definition data set may be provided that, when processed in an integrated circuit manufacturing system, causes the method of manufacturing a viewport transformation module 212 or PP block 210 to be performed.

[0136] An integrated circuit definition data set may be in the form of computer code, such as a netlist, code for configuring a programmable chip, a hardware description language (defining hardware suitable for fabrication in an integrated circuit at any level), including register transfer level (RTL) code, high-level circuit representations (e.g., Verilog, or VHDL), and low-level circuit representations (e.g., OASIS (RTM), and GDSII). A higher-level representation (e.g., RTL) that logically defines hardware suitable for fabrication in an integrated circuit may be executed at a computer system (configured to generate a manufacturing definition of an integrated circuit in the context of a software environment (including definitions of circuit elements and rules for combining such elements)) to generate a manufacturing definition of the integrated circuit defined by the representation. Similar to the case where software is typically executed at a computer system to define a machine, one or more intermediate user steps (e.g., providing commands, variables, etc.) may be required to cause the computer system (configured to generate a manufacturing definition of an integrated circuit) to execute the code defining the integrated circuit, thereby generating a manufacturing definition of the integrated circuit.

[0137] Now refer to Fig.15 An example of processing an integrated circuit definition data set at an integrated circuit manufacturing system to configure the system to manufacture the viewport transformation module 212 is described.

[0138] Fig.15 An example of an integrated circuit (IC) manufacturing system 1502 (configured to manufacture the viewport transformation module described in any of the examples herein) is shown. Specifically, the IC manufacturing system 1502 includes a layout processing system 1504, and an integrated circuit generation system 1506. The IC manufacturing system 1502 is configured to receive an IC definition data set (e.g., defining the viewport transformation module 212 described in any of the examples herein), process the IC definition data set, and generate an IC (e.g., the IC embodying the viewport transformation module 212 described in any of the examples herein) based on the IC definition data set. The processing of the IC definition data set configures the IC manufacturing system 1502 to manufacture an integrated circuit embodying the viewport transformation module described in any of the examples herein.

[0139] The layout processing system 1504 is configured to receive and process an IC definition data set to determine a circuit layout. Methods for determining a circuit layout from an IC definition data set are known in the art, and may, for example, include synthesizing RTL code to determine a gate level representation of the circuit to be generated, for example, in terms of logic components (e.g., NAND, NOR, AND, OR, MUX, and FLIP-FLOP components). By determining the location information of the logic components, the circuit layout can be determined from the gate level representation of the circuit. This can be done automatically or with user participation in order to optimize the circuit layout. When the layout processing system 1504 has determined the circuit layout, it can output a circuit layout definition to the IC generation system 1506. The circuit layout definition can be, for example, a circuit layout description.

[0140] As is known in the art, IC generation system 1506 generates an IC according to a circuit layout definition. For example, IC generation system 1506 may implement a semiconductor device manufacturing process to generate an IC, which may include a multi-step sequence of photolithography and chemical processing steps during which electronic circuits are gradually formed on a wafer made of semiconductor material. The circuit layout definition may be in the form of a mask that may be used in a photolithography process for generating an IC according to the circuit definition. Alternatively, the circuit layout definition provided to IC generation system 1506 may be in the form of a computer-readable code that IC generation system 1506 may use to form an appropriate mask for use in generating an IC.

[0141] The different processes performed by IC manufacturing system 1502 may all be implemented at one location (e.g., by one party). Alternatively, IC manufacturing system 1502 may be a distributed system such that some processes may be performed at different locations and may be performed by different parties. For example, some stages in (i) synthesizing RTL code representing an IC definition data set to form a gate-level representation of a circuit to be generated, (ii) generating a circuit layout based on the gate-level representation, (iii) forming a mask based on the circuit layout, and (iv) using the mask to manufacture an integrated circuit may be performed at different locations and / or by different parties.

[0142] In other examples, processing an integrated circuit definition dataset at an integrated circuit manufacturing system may configure the system to (without processing the IC definition dataset to determine a circuit layout) manufacture the viewport transformation module 212. For example, the integrated circuit definition dataset may define a configuration of a reconfigurable processor (e.g., an FPGA), and processing the dataset may configure the IC manufacturing system to generate a reconfigurable processor having the defined configuration (e.g., by loading the configuration data into the FPGA).

[0143] In some embodiments, when the integrated circuit manufacturing definition data set is processed in the integrated circuit manufacturing system, it can cause the integrated circuit manufacturing system to generate the device as described herein. Fig.15 The described approach uses an integrated circuit manufacturing definition data set to configure an integrated circuit manufacturing system so that the device described herein can be manufactured.

[0144] In some examples, the integrated circuit definition data set may include software that runs on or in conjunction with hardware defined by the data set. Fig.15 In the example shown, the IC generation system can be further configured by the integrated circuit definition dataset to load firmware onto the integrated circuit according to the program code defined in the integrated circuit definition dataset when manufacturing the integrated circuit, or otherwise provide the integrated circuit with program code for use with the integrated circuit.

[0145] Compared with known implementations, the implementation of the concepts set forth in this application in devices, apparatuses, modules, and / or systems (and in the methods implemented herein) can produce performance improvements. Performance improvements can include one or more of increased computing performance, reduced delays, increased throughput, and / or reduced power consumption. During the manufacture of such devices, devices, modules, and systems (e.g., in integrated circuits), performance improvements can be weighed against physical implementations, thereby improving manufacturing methods. For example, performance improvements can be weighed against layout area, thereby matching the performance of known implementations, but using less silicon. This can be accomplished, for example, by reusing functional blocks in a serialized manner, or sharing functional blocks between elements of devices, devices, modules, and / or systems. On the contrary, the concepts proposed in this application that produce improvements (e.g., reduced silicon area) to the physical implementations of devices, devices, modules, and systems can be weighed against performance improvements. This can be accomplished, for example, by manufacturing multiple instances of modules within a predefined area budget.

[0146] The applicant hereby independently discloses each individual feature described herein and any combination of two or more such features, including such features or combinations that can be performed based on this specification as a whole according to the general common sense of those skilled in the art, regardless of whether such features or combinations of features solve any problems disclosed herein. In view of the foregoing description, it is obvious to those skilled in the art that various modifications can be made within the scope of the present invention.

Claims

1. A viewport transformation module (212) for use in a three-dimensional rendering system (200), wherein primitives are formed from vertices in a strip, wherein each primitive comprises a plurality of vertices, the viewport transformation module (212) comprising: a processing module (804) configured to perform a viewport transformation on untransformed coordinate data for vertices in the strip for each of a plurality of viewports to generate transformed coordinate data for the vertex for each of the plurality of viewports, the plurality of viewports including a viewport associated with the vertex and a viewport associated with at least one other vertex in the strip, the at least one other vertex selected based on an initiating vertex of a primitive and a number of vertices in each primitive formed by the vertices in the strip; as well as A writing module (806) is configured to write the transformed coordinate data for the vertex into a vertex buffer (408) so that the transformed coordinate data is stored in the vertex buffer (408) in an order corresponding to an order of vertices in the strips associated with the plurality of viewports.

2. The viewport transformation module (212) according to claim 1, further comprising: The fetch module (802) is configured to read from the vertex buffer (408): untransformed coordinate data for the vertex; information identifying a viewport associated with the vertex; and Information identifying a viewport associated with at least one other vertex in the strip.

3. The viewport transformation module (212) according to claim 1, wherein: The at least one other vertex includes N-1 other vertices, where N is the number of vertices in each primitive.

4. The viewport transformation module (212) according to claim 1, wherein: Each primitive is a triangle including a head vertex, a middle vertex, and a tail vertex, and at least one other vertex in the strip is selected from two vertices immediately before the vertex in the strip and two vertices immediately after the vertex in the strip.

5. The viewport transformation module (212) of claim 4, wherein: When the initiating vertex is the head vertex, the at least one other vertex in the strip includes two vertices immediately preceding the vertex in the strip; When the initiating vertex is the intermediate vertex, the at least one other vertex in the strip includes a vertex immediately before the vertex in the strip and a vertex immediately after the vertex in the strip; and When the initiating vertex is the trailing vertex, the at least one other vertex in the strip includes two vertices immediately following the vertex in the strip.

6. The viewport transformation module (212) according to any one of claims 1 to 5, wherein: The write module (806) is configured to write the transformed coordinate data to the vertex buffer (408) in an order corresponding to the order of vertices in the strips associated with the plurality of viewports by associating each viewport transform with a different offset representing the order of the vertices associated with the corresponding viewport in the strip, and writing the transformed coordinate data for each viewport transform to a separate location in the vertex buffer (408) based on the offset associated with the viewport transform.

7. The viewport transformation module (212) according to claim 6, wherein: Individual locations in the vertex buffer (408) where the transformed coordinate data for the vertex for a viewport transform is written are identified by an address of the vertex buffer (408) that is based on a base address associated with the vertex and an offset associated with the viewport transform.

8. The viewport transformation module (212) according to claim 7, wherein: Each offset corresponds to a particular row of the vertex buffer, and the transformed coordinate data includes transformed data for each of a plurality of coordinates, and the transformed data for each coordinate is written to a different column of the vertex buffer (408).

9. The viewport transformation module (212) according to claim 6, wherein: each viewport transformation performed on the untransformed coordinate data is associated with an iteration identifier, the iteration identifier identifying an order of the viewport transformation relative to other viewport transformations performed on the untransformed coordinate data; and The offset associated with each viewport transform is based on the iteration identifier associated with that viewport transform and the inciting vertex.

10. The viewport transformation module (212) according to claim 9, wherein: The processing module (804) is configured to perform each viewport transform in response to receiving a viewport transform instruction from the transaction processing module (402), the viewport transform instruction specifying the vertex and the iteration identifier.

11. The viewport transformation module (212) according to claim 6, wherein: Each primitive is a triangle formed by a head vertex, a middle vertex, and a tail vertex, and the processing module (804) is configured to perform the viewport transformation based on a viewport associated with the vertex in a first iteration and perform the viewport transformation based on a viewport associated with the at least one other vertex in one or more subsequent iterations; and The write module (806) is configured to associate the viewport transformation performed in the first iteration with a third offset when the inciting vertex is the head vertex, to associate the viewport transformation performed in the first iteration with a second offset when the inciting vertex is the middle vertex, and to associate the viewport transformation performed in the first iteration with a first offset when the inciting vertex is the tail vertex.

12. The viewport transformation module (212) of claim 6, wherein Each primitive is a triangle formed by a head vertex, a middle vertex, and a tail vertex, and one viewport transformation performed on the untransformed coordinate data corresponds to a viewport transformation for the vertex as a head vertex in the primitive, one viewport transformation performed on the untransformed coordinate data corresponds to a viewport transformation for the vertex as a middle vertex in the primitive, and one viewport transformation performed on the untransformed coordinate data corresponds to a viewport transformation for the vertex as a tail vertex in the primitive; and The write module (806) is configured to associate a viewport transform corresponding to a viewport transform for the vertex as a head vertex in a primitive with a third offset, associate a viewport transform corresponding to a viewport transform for the vertex as a middle vertex in a primitive with a second offset, and associate a viewport transform corresponding to a viewport transform for the vertex as a tail vertex in a primitive with the first offset.

13. The viewport transformation module (212) according to any one of claims 1 to 5, wherein: Each primitive is a triangle formed by a head vertex, a middle vertex, and a tail vertex, and one viewport transformation performed on the untransformed coordinate data corresponds to a viewport transformation for the vertex as a head vertex in the primitive, one viewport transformation performed on the untransformed coordinate data corresponds to a viewport transformation for the vertex as a middle vertex in the primitive, and one viewport transformation performed on the untransformed coordinate data corresponds to a viewport transformation for the vertex as a tail vertex in the primitive.

14. The viewport transformation module (212) according to any one of claims 1 to 5, wherein: The processing module (804) is further configured to perform a viewport transformation on the untransformed coordinate data of the second vertices in the second strip for each viewport in the second plurality of viewports to generate transformed coordinate data for the second vertices for each viewport in the second plurality of viewports; and The writing module (806) is configured to write the transformed coordinate data for the second vertex into the vertex buffer (408) at the same location as the transformed coordinate data for the vertex.

15. The viewport transformation module (212) according to any one of claims 1 to 5, wherein: The viewport transformation module (212) is embodied in the form of hardware on an integrated circuit.

16. A three-dimensional rendering system, comprising a viewport transformation module (212) according to any one of claims 1 to 5.

17. A non-transitory computer-readable storage medium having stored thereon computer-readable code in the form of an integrated circuit definition data set, wherein when the computer-readable code is processed in an integrated circuit manufacturing system (1502), the integrated circuit manufacturing system (1502) manufactures an integrated circuit embodying a viewport transformation module (212) according to any one of claims 1 to 5.

18. A method (600) for performing multi-viewport transformation on vertices in a strip in a three-dimensional rendering system, wherein primitives are formed from the vertices in the strip, wherein each primitive includes a plurality of vertices, the method comprising: performing a viewport transformation on untransformed coordinate data for the vertex in the strip for each of a plurality of viewports to generate transformed coordinate data for the vertex for each of the plurality of viewports, the plurality of viewports including a viewport associated with the vertex and a viewport associated with at least one other vertex in the strip, the at least one other vertex selected based on an initiating vertex of a primitive and a number of vertices in each primitive formed by the vertices in the strip; as well as The transformed coordinate data for the vertices are written to a vertex buffer such that the transformed coordinate data is stored in the vertex buffer in an order that corresponds to an order of vertices in the strips associated with the plurality of viewports.

Images