Home
last modified time | relevance | path

Searched refs:likely (Results 1 – 25 of 68) sorted by relevance

123

/hardware/google/gfxstream/guest/mesa/src/util/
Dmacros.h63 #ifndef likely
65 # define likely(x) __builtin_expect(!!(x), 1) macro
68 # define likely(x) (x) macro
Dralloc.c152 if (likely(ptr)) in rzalloc_size()
848 if (likely(ptr)) in gc_zalloc_size()
1009 if (likely(min_size < MIN_LINEAR_BUFSIZE)) in create_linear_node()
1086 if (likely(ptr)) in linear_zalloc_child()
1096 if (likely(ptr)) in linear_zalloc_parent()
1159 if (likely(new_ptr && old_size)) in linear_realloc()
Dsparse_array.c151 if (likely(root_idx < (1ull << node_size_log2))) in util_sparse_array_get()
/hardware/google/gfxstream/codegen/vulkan/vulkan-docs-next/appendices/
DVK_EXT_memory_priority.adoc24 allocations are more likely to remain in device-local memory.
DVK_NV_displacement_micromap.adoc47 likely be changes to the structures, enumerant values, and shader
DVK_KHR_portability_subset.adoc47 implementation is likely not fully conformant with the Vulkan spec.
DVK_NV_cuda_kernel_launch.adoc56 different GPU architecture, the cache is likely to become invalid.
DVK_KHR_surface.adoc95 in many applications and likely will remain in use for the foreseeable
100 Additionally, the performance improvements possible with XCB likely will not
DVK_NV_viewport_swizzle.adoc161 It seems likely that the fragment shader in either version of the example
163 It would likely do this by reconstructing the position of the fragment in
/hardware/google/gfxstream/guest/mesa/src/vulkan/runtime/
Dvk_log.c116 (likely(list_is_empty(&instance->debug_utils.callbacks)) && in __vk_log_impl()
117 likely(list_is_empty(&instance->debug_report.callbacks)))) in __vk_log_impl()
Dvk_object.c275 if (likely(result == VK_SUCCESS)) { in vk_object_base_get_private_data()
Dmeson.build257 # This is likely a bug in the Meson VS backend, as MSVC with ninja works fine.
/hardware/interfaces/neuralnetworks/1.3/
Dtypes.t153 * deadlines will likely also not be met for the same task even after a
166 * calls for the same task will likely also fail even after a short
/hardware/google/gfxstream/codegen/vulkan/vulkan-docs-next/proposals/
DRoadmap.adoc84 One of the products of these efforts is likely to be new API features, which will become candidates…
89 The cadence of releasing new roadmap milestones is likely to be somewhat coincident with hardware v…
90 Given the current cadence of Vulkan versions every 2 years, it is likely that roadmap milestones co…
93 Releasing roadmap milestones once a year is likely to just confuse the market; one year is unlikely…
94 A 2 year cadence, being exactly coincident with core version releases, would likely be the lower bo…
DVK_EXT_shader_module_identifier.adoc35 since most implementations are likely to only hash, and never look at the SPIR-V again.
40 and the translation layer can build SPIR-V as needed. Next time, we are likely to hit in cache.
/hardware/google/gfxstream/guest/mesa/
DAndroid.bp33 // It's likely due to a bug elsewhere, but let's temporarily add them
/hardware/interfaces/radio/1.5/
DIRadioIndication.hal69 * of likely future (statistical) barring for specific services.
73 * barring conditions. Barring status will likely change when the device camps for service,
/hardware/google/pixel/vibrator/common/proto/
Dcapo.proto133 // less likely to transition between states.
151 // this value causes the algorithm to be less likely to detect motion.
/hardware/interfaces/tetheroffload/control/1.0/
Dtypes.hal35 * and add/removeDownstream will likely fail and cannot be presumed to be
/hardware/google/gfxstream/guest/mesa/src/vulkan/wsi/
Dmeson.build92 # This is likely a bug in the Meson VS backend, as MSVC with ninja works fine.
/hardware/interfaces/health/aidl/
DREADME.md42 has `class charger`. Most likely, the declaration looks something like this
191 If you did not define a separate domain, the domain is likely
192 `hal_health_default`. The device-specific rules for it is likely at
/hardware/interfaces/drm/1.2/
Dtypes.hal71 * the operation is likely to succeed.
/hardware/interfaces/drm/1.4/
Dtypes.hal134 * Provisioning failed in a way that is likely to succeed on a subsequent
/hardware/interfaces/wifi/1.2/
Dtypes.hal33 * Beacons), however - cluster synchronization time will likely increase.
/hardware/interfaces/tetheroffload/control/1.1/
DIOffloadControl.hal37 * offload is started. This is because the quota values would likely become stale over

123