| /third_party/skia/third_party/externals/swiftshader/third_party/llvm-10.0/llvm/lib/Target/AMDGPU/ |
| D | SIMemoryLegalizer.cpp | 84 LDS = 1u << 1, enumerator
90 FLAT = GLOBAL | LDS | SCRATCH,
93 ATOMIC = GLOBAL | LDS | SCRATCH | GDS,
96 ALL = GLOBAL | LDS | SCRATCH | GDS | OTHER,
503 return SIAtomicAddrSpace::LDS; in toSIAtomicAddrSpace()
789 if ((AddrSpace & SIAtomicAddrSpace::LDS) != SIAtomicAddrSpace::NONE) { in insertWait()
1055 if ((AddrSpace & SIAtomicAddrSpace::LDS) != SIAtomicAddrSpace::NONE) { in insertWait()
|
| D | SIInstrFormats.td | 345 // VINTRP instructions read parameter values from LDS, but these parameter
346 // values are stored outside of the LDS memory that is allocated to the
350 // the parameter values in LDS, this would essentially be an out-of-bounds
|
| D | AMDGPU.td | 154 "Some GFX10 bug with misaligned multi-dword LDS access in WGP mode"
196 "Switching between LDS and VMEM-tex not waiting VM_VSRC=0"
221 "The number of LDS banks per compute unit."
|
| D | AMDGPUISelLowering.h | 483 LDS, enumerator
|
| /third_party/openGLES/extensions/NV/ |
| D | NV_compute_program5.txt | 160 | "LDS" <opModifiers> <instResult> ","
299 from which data can be read or written using the LDS and STS instructions.
314 Shared memory variables may only be used as operands in the ATOMS, LDS,
358 LDS - - X X - F v su load from shared memory
380 operation), LDS (load from shared memory), and STS (store to shared
416 ATOMS, LDS, or STS instructions in a program without a SHARED_MEMORY
548 Section 2.X.8.Z, LDS: Load from Shared Memory
550 The LDS instruction generates a result vector by fetching data from the
552 operand, as described in Section 2.X.4.5. The single operand for the LDS
555 type of operand is used in an LDS instruction.
[all …]
|
| D | NV_gpu_program5_mem_extended.txt | 65 LDS Load from shared memory (via NV_compute_program5)
284 STOREIM, LDB, STB, LDS, STS).
322 If NV_compute_program5 is not supported, references to the LDS and STS
|
| /third_party/skia/third_party/externals/opengl-registry/extensions/NV/ |
| D | NV_compute_program5.txt | 160 | "LDS" <opModifiers> <instResult> ","
299 from which data can be read or written using the LDS and STS instructions.
314 Shared memory variables may only be used as operands in the ATOMS, LDS,
358 LDS - - X X - F v su load from shared memory
380 operation), LDS (load from shared memory), and STS (store to shared
416 ATOMS, LDS, or STS instructions in a program without a SHARED_MEMORY
548 Section 2.X.8.Z, LDS: Load from Shared Memory
550 The LDS instruction generates a result vector by fetching data from the
552 operand, as described in Section 2.X.4.5. The single operand for the LDS
555 type of operand is used in an LDS instruction.
[all …]
|
| D | NV_gpu_program5_mem_extended.txt | 65 LDS Load from shared memory (via NV_compute_program5)
284 STOREIM, LDB, STB, LDS, STS).
322 If NV_compute_program5 is not supported, references to the LDS and STS
|
| /third_party/grpc/src/proto/grpc/testing/xds/v3/ |
| D | discovery.proto | 59 // returned. LDS/CDS may have empty resource_names, which will cause all
60 // resources for the Envoy instance to be returned. The LDS and CDS responses
67 // in requests made via singleton xDS APIs such as CDS, LDS, etc. but is
|
| D | listener.proto | 85 // updated or removed via :ref:`LDS <config_listeners_lds>` a unique name must be provided.
110 // not LDS.
|
| D | config_source.proto | 70 // LDS to RDS on the same server without requiring the management server to know its name
|
| /third_party/mesa3d/src/amd/compiler/ |
| D | README-ISA.md | 116 ## `m0` with LDS instructions on Vega and newer
118 The Vega ISA doc (both the old one and the "7nm" one) claims that LDS instructions
121 In reality, only the `_addtid` variants of LDS instructions use `m0` on Vega and
123 LLVM also doesn't emit any initialization of `m0` for LDS instructions, and this
|
| D | README.md | 172 * LS and HS share the same LDS space, so LS can store its output to LDS, where HS can read it
185 * HW LS and HS stages are merged, and the merged shader still uses LDS in the same way as before
186 * HW ES and GS stages are merged, so ES outputs can go to LDS instead of VRAM
|
| /third_party/mesa3d/docs/relnotes/ |
| D | 17.3.8.rst | 66 - radv: get correct offset into LDS for indexed vars.
|
| D | 20.3.5.rst | 275 - radv/llvm: Fix reporting LDS stats of tess control shaders.
277 - aco: Fix LDS statistics of tess control shaders.
|
| D | 20.3.1.rst | 146 - radv: don't count unusable vertices to the NGG LDS size
|
| D | 13.0.3.rst | 118 - radeonsi: wait for outstanding LDS instructions in memory barriers if
|
| D | 20.2.5.rst | 149 - radv: don't count unusable vertices to the NGG LDS size
|
| D | 12.0.4.rst | 250 - radeonsi: fix 64-bit loads from LDS
|
| /third_party/grpc/doc/ |
| D | grpc_xds_features.md | 39 **xDS Infrastructure in gRPC client channel:**<br>LDS->RDS->CDS->EDS flow,<br>ADS stream, | [A27](h…
|
| /third_party/skia/third_party/externals/angle2/src/libANGLE/renderer/vulkan/shaders/src/ |
| D | GenerateMipmap.comp | 154 // Define the LDS load and store functions
|
| /third_party/grpc/src/proto/grpc/testing/xds/ |
| D | eds_for_test.proto | 145 // returned. LDS/CDS expect empty resource_names, since this is global
146 // discovery for the Envoy instance. The LDS and CDS responses will then imply
153 // in requests made via singleton xDS APIs such as CDS, LDS, etc. but is
|
| D | cds_for_test.proto | 53 // LDS to RDS on the same server without requiring the management server to know its name
|
| D | lds_rds_for_test.proto | 206 // not LDS.
|
| /third_party/mesa3d/src/gallium/drivers/nouveau/codegen/ |
| D | nv50_ir_target_gv100.cpp | 171 OPINFO(LDS , NONE, NONE, NONE, NONE, NONE, NONE);
|