Searched refs:replay (Results 1 – 25 of 31) sorted by relevance
12
77 unsigned char replay[EAPOL_KEY_REPLAY_LEN]; /* Replay Counter */109 unsigned char replay[EAPOL_WPA_KEY_REPLAY_LEN]; /* Replay Counter */
119 void MediaSnapshotHelper::replay( in replay() function in android::emulation::MediaSnapshotHelper156 replay(oneShotDecode); in load()
278 mSnapshotHelper->replay(func); in try_decode()
50 A trace capture and replay tool can then supply these addresses to be used51 at replay time to match the addresses used when the trace was captured.55 **Note that this mechanism is intended only to support capture/replay tools,
37 It also allows buffer device addresses to be provided by a trace replay
207 capture/replay)225 * added creation time capture and replay flags
238 * added creation time capture and replay flags469 ** added creation time capture/replay flags (#2104,!3774)
83 void replay(std::function<void(uint8_t* data, size_t len, uint64_t pts)>
35 For capture replay, we also allow capture replay handles to be extracted from pipeline libraries. W…36 those capture replay handles can be used, which also ensures invariance for any pipeline that inclu…
148 // trace-replay tools will track the layout anyway.174 trace-replay tools would have to track image layout already anyway.280 the object like the layout of these images since capture-replay tools would
428 …e with the capture/replay feature enabled, an opaque handle can be obtained which can be passed in…515 …moryOpaqueCaptureAddress] must be used to capture the opaque address and replay it with link:{refp…536 …ly for capture replay tools, and allows opaque data to be captured and replayed, allowing the same…594 …` define the maximum size, in bytes, of the opaque data used for capture replay with each respecti…1070 === RESOLVED: How should we expect capture/replay tooling (e.g. RenderDoc/vktrace) to use this?1072 …replay bit on image/buffer creation will be added to enable descriptors to be reused between runs.…
207 .replay.length = 0,234 .replay.length = 0,601 mFfEffects[WAVEFORM_COMPOSE].replay.length = 0; in compose()657 mFfEffects[effectIndex].replay.length = static_cast<uint16_t>(timeoutMs); in on()1218 mFfEffects[WAVEFORM_PWLE].replay.length = totalDuration; in composePwle()1283 mFfEffects[effectId].replay.length); in dump()1524 mFfEffects[WAVEFORM_COMPOSE].replay.length = 0; in getCompoundDetails()
71 out << "FF_PERIODIC, " << arg.id << ", " << arg.replay.length << "ms, " in operator <<()
35 ? -70007 : int, ; Sequence number (if needed to prevent replay attacks)
62 ; A monotonically incrementing number is associated with each RequestPacket to prevent replay
368 effect.replay.length = (duration + 999'999LL) / 1'000'000LL; in vibrate()369 effect.replay.delay = 0; in vibrate()
81 * spoofing and replay attacks and ensures that only a transaction backed188 * outside of an active enrollment window to prevent replay attacks.
979 [[ray-tracing-capture-replay]]986 querying of opaque data which can: be used in a future replay.988 During the capture phase, capture/replay tools are expected to query opaque989 data for shader group handle replay using992 Providing the opaque data during replay, using995 shader group handles to those in the capture phase, allowing capture/replay
705 for trace capture and replay), see711 capturing and replaying (e.g. for trace capture and replay), see823 The expected usage for this is that a trace capture/replay tool will add the827 During replay, the buffers will be created specifying the original address3360 replaying (e.g. for trace capture and replay), see5377 capturing and replaying (e.g. for trace capture and replay), see6343 The expected usage for a trace capture/replay tool is that it will serialize6352 ename:VK_COPY_ACCELERATION_STRUCTURE_MODE_DESERIALIZE_KHR during replay.6426 The expected usage for this is that a trace capture/replay tool will add the6436 During replay, the buffers will be created specifying the original address[all …]
608 logging to capturing data for later replay.
2890 capture and replay.2956 replay.2978 replay mechanism is built around opaque capture addresses for buffer and4009 addresses, e.g. for trace capture and replay.4057 e.g. for trace capture and replay.4411 address and reuse later for replay in5528 supports capture and replay when using descriptor buffers.5642 whether the implementation supports capture and replay of addresses for
2891 information required to do capture and replay for shader group handles.3562 in bytes of the opaque data used for capture and replay with buffers.3565 bytes of the opaque data used for capture and replay with images.3568 size in bytes of the opaque data used for capture and replay with image3572 in bytes of the opaque data used for capture and replay with samplers.3575 maximum size in bytes of the opaque data used for capture and replay
1128 re-populate pname:deviceAddress for replay.1172 pname:pipeline must: have been recreated for replay4771 subsequent run (e.g. for trace capture and replay).5013 subsequent run (e.g. for trace capture and replay).6637 * pname:pShaderGroupCaptureReplayHandle is `NULL` or a pointer to replay6640 <<ray-tracing-capture-replay, Ray Tracing Capture Replay>>.6868 [open,refpage='vkGetRayTracingCaptureReplayShaderGroupHandlesKHR',desc='Query opaque capture replay…6892 as described in <<ray-tracing-capture-replay, Ray Tracing Capture Replay>>.6897 feature is enabled applications can: query capture replay group handles from6899 The capture replay handle remains bitwise identical for any pname:pipeline
3325 (e.g. for trace capture and replay), see3385 This is, however, not a strict requirement because trace capture/replay4499 capture/replay tools to store these addresses in a trace and subsequently4500 specify them during replay.
1043 capture-replay libraries.