| /third_party/skia/third_party/externals/swiftshader/src/Renderer/ |
| D | Context.cpp | 550 bool Context::texCoordActive(int coordinate, int component) in texCoordActive() argument
558 if(vertexShader->getOutput(T0 + coordinate, component).usage == Shader::USAGE_TEXCOORD) in texCoordActive()
570 switch(texGen[coordinate]) in texCoordActive()
576 …hasTexture = hasTexture || (component < input[TexCoord0 + textureStage[coordinate].texCoordIndex].… in texCoordActive()
595 bool project = isProjectionComponent(coordinate, component); in texCoordActive()
600 usesTexture = pixelShader->usesTexture(coordinate, component) || project; in texCoordActive()
604 usesTexture = textureStage[coordinate].usesTexture() || project; in texCoordActive()
610 bool Context::texCoordActive(int coordinate) in texCoordActive() argument
612 return texCoordActive(coordinate, 0) || in texCoordActive()
613 texCoordActive(coordinate, 1) || in texCoordActive()
[all …]
|
| D | SetupProcessor.cpp | 186 for(int coordinate = 0; coordinate < 8; coordinate++) in update() local
190 if(context->textureActive(coordinate, component)) in update()
192 state.texture[coordinate][component].attribute = T0 + coordinate; in update()
193 state.texture[coordinate][component].flat = point && !sprite; in update()
194 …state.texture[coordinate][component].wrap = (context->textureWrap[coordinate] & (1 << component)) … in update()
|
| /third_party/skia/third_party/externals/opengl-registry/extensions/EXT/ |
| D | EXT_fog_coord.txt | 33 coordinate to be used in fog computations, rather than using a
60 * Interpolation of the fog coordinate may be perspective-correct or
68 * Should the current fog coordinate be queryable?
72 * Control the fog coordinate source via an Enable instead of a fog
77 * Should the fog coordinate be restricted to non-negative values?
79 Perhaps. Eye-coordinate distance of fragments will be
126 These changes describe a new current state type, the fog coordinate,
133 current color, and current fog coordinate may be used in
156 the current fog coordinate, four floating-point values to store
161 initial value of q is one. The initial fog coordinate is zero.
[all …]
|
| /third_party/openGLES/extensions/EXT/ |
| D | EXT_fog_coord.txt | 33 coordinate to be used in fog computations, rather than using a
60 * Interpolation of the fog coordinate may be perspective-correct or
68 * Should the current fog coordinate be queryable?
72 * Control the fog coordinate source via an Enable instead of a fog
77 * Should the fog coordinate be restricted to non-negative values?
79 Perhaps. Eye-coordinate distance of fragments will be
126 These changes describe a new current state type, the fog coordinate,
133 current color, and current fog coordinate may be used in
156 the current fog coordinate, four floating-point values to store
161 initial value of q is one. The initial fog coordinate is zero.
[all …]
|
| /third_party/openGLES/docs/ |
| D | fog_coord.txt | 33 coordinate to be used in fog computations, rather than using a
60 * Interpolation of the fog coordinate may be perspective-correct or
68 * Should the current fog coordinate be queryable?
72 * Control the fog coordinate source via an Enable instead of a fog
77 * Should the fog coordinate be restricted to non-negative values?
79 Perhaps. Eye-coordinate distance of fragments will be
126 These changes describe a new current state type, the fog coordinate,
133 current color, and current fog coordinate may be used in
156 the current fog coordinate, four floating-point values to store
161 initial value of q is one. The initial fog coordinate is zero.
[all …]
|
| /third_party/skia/third_party/externals/opengl-registry/docs/ |
| D | fog_coord.txt | 33 coordinate to be used in fog computations, rather than using a
60 * Interpolation of the fog coordinate may be perspective-correct or
68 * Should the current fog coordinate be queryable?
72 * Control the fog coordinate source via an Enable instead of a fog
77 * Should the fog coordinate be restricted to non-negative values?
79 Perhaps. Eye-coordinate distance of fragments will be
126 These changes describe a new current state type, the fog coordinate,
133 current color, and current fog coordinate may be used in
156 the current fog coordinate, four floating-point values to store
161 initial value of q is one. The initial fog coordinate is zero.
[all …]
|
| /third_party/skia/third_party/externals/opengl-registry/extensions/REND/ |
| D | REND_screen_coordinates.txt | 27 This extension allows the specification of screen coordinate vertex
28 data. Screen coordinate vertices completely bypass transformation,
32 If we get screen coordinate inputs then in order to perspectively
49 coordinate data with respect to the w term prior to interpolation.
132 possibly affected by a texture coordinate generation function.
137 coordinate generation functions.
140 If screen coordinate vertex data is enabled, then the
144 If screen coordinate vertex data is enabled, then clipping is
151 represent screen coordinate values. Additionally if
153 the actual 1/w coordinate.
[all …]
|
| /third_party/openGLES/extensions/REND/ |
| D | REND_screen_coordinates.txt | 27 This extension allows the specification of screen coordinate vertex
28 data. Screen coordinate vertices completely bypass transformation,
32 If we get screen coordinate inputs then in order to perspectively
49 coordinate data with respect to the w term prior to interpolation.
132 possibly affected by a texture coordinate generation function.
137 coordinate generation functions.
140 If screen coordinate vertex data is enabled, then the
144 If screen coordinate vertex data is enabled, then clipping is
151 represent screen coordinate values. Additionally if
153 the actual 1/w coordinate.
[all …]
|
| /third_party/openGLES/extensions/NV/ |
| D | NV_texgen_emboss.txt | 48 This extension provides a new texture coordinate generation mode
59 coordinate. The perturbation is also scaled by program-supplied
74 Can you just enable one coordinate of a texture unit for embossing?
76 Yes but NOT REALLY. The texture coordinate generation formula
80 for texture coordinate generation and setup for embossing.
109 YES. Except when the texture unit's texture coordinate evaluator
122 evaluated texture coordinate if the vertex is evaluated with
123 texture coordinate evaluation enabled, otherwise if the vertex is
124 generated via vertex arrays with the respective texture coordinate
125 array enabled, the texture coordinate from the texture coordinate
[all …]
|
| D | NV_texgen_reflection.txt | 22 This extension's texture coordinate generation functionality is
45 This extension provides two new texture coordinate generation modes
72 texture coordinate for this spec?
81 The value of the q texture coordinate then simply scales the
119 value assigned to an s coordinate (the first TexGen argument value
120 is S) is s = rx; the value assigned to a t coordinate is t = ry;
121 and the value assigned to a r coordinate is r = rz. Calling TexGen
127 to an s coordinate (the first TexGen argument value is S) is s =
128 nfx; the value assigned to a t coordinate is t = nfy; and the
129 value assigned to a r coordinate is r = nfz. (The values nfx, nfy,
[all …]
|
| D | NV_point_sprite.txt | 58 generate the R coordinate for point sprites; the R coordinate can
59 either be zero, the input S coordinate, or the input R coordinate.
78 texture coordinate decreases, not increases, with Y; that is,
155 applications already need to put the R coordinate in R, and they
160 than TexCoord3 to specify their third texture coordinate. This
163 map the input S texture coordinate into the output R coordinate
187 coordinate set appears when fragment attribute variables
192 a given texture unit is GL_TRUE, the texture coordinate set for
262 The point sprite R coordinate mode is set with one of the commands
270 The point sprite texture coordinate replacement mode is set with one
[all …]
|
| /third_party/skia/third_party/externals/opengl-registry/extensions/NV/ |
| D | NV_texgen_emboss.txt | 48 This extension provides a new texture coordinate generation mode
59 coordinate. The perturbation is also scaled by program-supplied
74 Can you just enable one coordinate of a texture unit for embossing?
76 Yes but NOT REALLY. The texture coordinate generation formula
80 for texture coordinate generation and setup for embossing.
109 YES. Except when the texture unit's texture coordinate evaluator
122 evaluated texture coordinate if the vertex is evaluated with
123 texture coordinate evaluation enabled, otherwise if the vertex is
124 generated via vertex arrays with the respective texture coordinate
125 array enabled, the texture coordinate from the texture coordinate
[all …]
|
| D | NV_texgen_reflection.txt | 22 This extension's texture coordinate generation functionality is
45 This extension provides two new texture coordinate generation modes
72 texture coordinate for this spec?
81 The value of the q texture coordinate then simply scales the
119 value assigned to an s coordinate (the first TexGen argument value
120 is S) is s = rx; the value assigned to a t coordinate is t = ry;
121 and the value assigned to a r coordinate is r = rz. Calling TexGen
127 to an s coordinate (the first TexGen argument value is S) is s =
128 nfx; the value assigned to a t coordinate is t = nfy; and the
129 value assigned to a r coordinate is r = nfz. (The values nfx, nfy,
[all …]
|
| D | NV_point_sprite.txt | 58 generate the R coordinate for point sprites; the R coordinate can
59 either be zero, the input S coordinate, or the input R coordinate.
78 texture coordinate decreases, not increases, with Y; that is,
155 applications already need to put the R coordinate in R, and they
160 than TexCoord3 to specify their third texture coordinate. This
163 map the input S texture coordinate into the output R coordinate
187 coordinate set appears when fragment attribute variables
192 a given texture unit is GL_TRUE, the texture coordinate set for
262 The point sprite R coordinate mode is set with one of the commands
270 The point sprite texture coordinate replacement mode is set with one
[all …]
|
| /third_party/skia/third_party/externals/opengl-registry/extensions/ARB/ |
| D | ARB_fragment_coord_conventions.txt | 61 coordinate XY location available for programmable fragment processing.
64 coordinate XY location appears during programming fragment processing.
65 Beyond the scope of this extension are coordinate conventions used
68 In the case of the coordinate conventions for rasterization and
71 arbitrary clip-space and window-space coordinate space conventions.
75 window-space coordinate system because such shaders are encoded in
94 Other window coordinate conventions exist for other rendering APIs.
107 "fragment coordinate".
111 for determining the fragment coordinate value accessed during
116 location to adopt the fragment coordinate convention for which the
[all …]
|
| D | ARB_window_pos.txt | 40 coordinate with the RasterPos command, the modelview matrix, projection
42 desired window coordinate is outside of the window's bounds one must rely
53 to a specific window coordinate prior to calling DrawPixels, CopyPixels or
65 RESOLVED. No. Don't implement the 4-coordinate functions as
78 window coordinate values can be perfectly represented with
82 z is a window coordinate, not an object coordinate.
108 (7) What about the raster fog coordinate?
115 coordinate source is FRAGMENT_DEPTH_EXT, CURRENT_RASTER_DISTANCE
116 is set to zero. If the fog coordinate source is FOG_COORDINATE_EXT,
117 CURRENT_RASTER_DISTANCE is set to the current fog coordinate.
[all …]
|
| /third_party/openGLES/extensions/ARB/ |
| D | ARB_fragment_coord_conventions.txt | 71 coordinate XY location available for programmable fragment processing.
74 coordinate XY location appears during programming fragment processing.
75 Beyond the scope of this extension are coordinate conventions used
78 In the case of the coordinate conventions for rasterization and
81 arbitrary clip-space and window-space coordinate space conventions.
85 window-space coordinate system because such shaders are encoded in
104 Other window coordinate conventions exist for other rendering APIs.
117 "fragment coordinate".
121 for determining the fragment coordinate value accessed during
126 location to adopt the fragment coordinate convention for which the
[all …]
|
| D | ARB_window_pos.txt | 50 coordinate with the RasterPos command, the modelview matrix, projection
52 desired window coordinate is outside of the window's bounds one must rely
63 to a specific window coordinate prior to calling DrawPixels, CopyPixels or
75 RESOLVED. No. Don't implement the 4-coordinate functions as
88 window coordinate values can be perfectly represented with
92 z is a window coordinate, not an object coordinate.
118 (7) What about the raster fog coordinate?
125 coordinate source is FRAGMENT_DEPTH_EXT, CURRENT_RASTER_DISTANCE
126 is set to zero. If the fog coordinate source is FOG_COORDINATE_EXT,
127 CURRENT_RASTER_DISTANCE is set to the current fog coordinate.
[all …]
|
| /third_party/openGLES/extensions/INTEL/ |
| D | INTEL_parallel_arrays.txt | 29 Pointers to the coordinate arrays are specified using new vector versions of the
89 where pointer[0] is a pointer to the x coordinate of the first vertex in the
90 array, pointer[1] specifies a pointer to the y coordinate of the first
91 vertex in the array, pointer[2] specifies a pointer to the z coordinate of
93 coordinate of the first vertex in the array.
94 <type> specifies the data type of each coordinate in the array, and must be
101 pointer[0] is a pointer to the x coordinate of the first normal in the
102 array, pointer[1] specifies a pointer to the y coordinate of the first
103 normal in the array, pointer[2] specifies a pointer to the z coordinate of
105 coordinate of the first normal in the array. <type> specifies the
[all …]
|
| /third_party/skia/third_party/externals/opengl-registry/extensions/INTEL/ |
| D | INTEL_parallel_arrays.txt | 29 Pointers to the coordinate arrays are specified using new vector versions of the
89 where pointer[0] is a pointer to the x coordinate of the first vertex in the
90 array, pointer[1] specifies a pointer to the y coordinate of the first
91 vertex in the array, pointer[2] specifies a pointer to the z coordinate of
93 coordinate of the first vertex in the array.
94 <type> specifies the data type of each coordinate in the array, and must be
101 pointer[0] is a pointer to the x coordinate of the first normal in the
102 array, pointer[1] specifies a pointer to the y coordinate of the first
103 normal in the array, pointer[2] specifies a pointer to the z coordinate of
105 coordinate of the first normal in the array. <type> specifies the
[all …]
|
| /third_party/vk-gl-cts/external/openglcts/modules/glesext/tessellation_shader/ |
| D | esextcTessellationShaderVertexSpacing.cpp | 165 const float* coordinate = (const float*)(&run.data[0]) + 3 /* components */ * n_vertex; in getEdgesForIsolinesTessellation() local
168 new_item.x = coordinate[0]; in getEdgesForIsolinesTessellation()
169 new_item.y = coordinate[1]; in getEdgesForIsolinesTessellation()
179 if (de::abs(edge.points[0].y - coordinate[1]) < epsilon) in getEdgesForIsolinesTessellation()
279 const _tess_coordinate_cartesian& coordinate = *coordinate_iterator; in getEdgesForQuadsTessellation() local
280 float delta_x = coordinate.x - 0.5f; in getEdgesForQuadsTessellation()
281 float delta_y = coordinate.y - 0.5f; in getEdgesForQuadsTessellation()
289 current_tl_point = coordinate; in getEdgesForQuadsTessellation()
299 current_tr_point = coordinate; in getEdgesForQuadsTessellation()
309 current_bl_point = coordinate; in getEdgesForQuadsTessellation()
[all …]
|
| /third_party/skia/third_party/externals/angle2/src/common/spirv/ |
| D | spirv_instruction_parser_autogen.h | 156 IdRef *coordinate,
251 IdRef *coordinate,
258 IdRef *coordinate,
265 IdRef *coordinate,
273 IdRef *coordinate,
281 IdRef *coordinate,
288 IdRef *coordinate,
295 IdRef *coordinate,
303 IdRef *coordinate,
311 IdRef *coordinate,
[all …]
|
| /third_party/skia/site/docs/user/ |
| D | coordinates.md | 8 Skia generally refers to two different coordinate spaces: **device** and
18 The local coordinate space is how all geometry and shaders are supplied to the
19 `SkCanvas`. By default, the local and device coordinate systems are the same.
40 What happened? Remember, the local coordinate space has not changed. The origin
53 Instead, we can use methods on `SkCanvas` to **change the local coordinate
63 Finally, it is possible to transform the coordinate space of the `SkShader`,
64 relative to the canvas local coordinate space. To do this, you supply a
69 shader's coordinates to the coordinate space of the geometry.
|
| /third_party/vk-gl-cts/external/vulkan-docs/src/appendices/ |
| D | VK_NV_viewport_swizzle.adoc | 150 The viewport swizzle feature performs the coordinate transformation handled
160 code:normal would remain in the original coordinate system.
162 would want to perform lighting in the original coordinate system.
164 the original coordinate system using code:gl_FragCoord, a constant or
167 Since the value of code:normal is in the original coordinate system, it
168 would not need to be modified as part of this coordinate transformation.
177 coordinate (typically 1.0) into the [eq]#Z# coordinate of the swizzle
178 output and the eye coordinate component used for depth into the [eq]#W#
179 coordinate.
182 The [eq]#Z# normalized device coordinate computed after swizzling would
[all …]
|
| D | VK_NV_viewport_swizzle.txt | 150 The viewport swizzle feature performs the coordinate transformation handled
160 code:normal would remain in the original coordinate system.
162 would want to perform lighting in the original coordinate system.
164 the original coordinate system using code:gl_FragCoord, a constant or
167 Since the value of code:normal is in the original coordinate system, it
168 would not need to be modified as part of this coordinate transformation.
177 coordinate (typically 1.0) into the [eq]#Z# coordinate of the swizzle
178 output and the eye coordinate component used for depth into the [eq]#W#
179 coordinate.
182 The [eq]#Z# normalized device coordinate computed after swizzling would
[all …]
|