Searched refs:We (Results 1 – 25 of 93) sorted by relevance
1234
| /hardware/google/gfxstream/third-party/stb/include/stb/ |
| D | LICENSE | 9 domain. We make this dedication for the benefit of the public at large and to
10 the detriment of our heirs and successors. We intend this dedication to be an
|
| /hardware/nxp/nfc/snxxx/halimpl/power-tracker/ |
| D | README.txt | 15 - We can set these variables during make command
20 We can specify refresh time for power data from config file /vendor/etc/libnfc-nxp.conf.
|
| /hardware/google/gfxstream/codegen/vulkan/vulkan-docs-next/appendices/ |
| D | VK_NV_low_latency.adoc | 26 *RESOLVED*: We are stuck with this for legacy reasons - we are aware this is
|
| D | VK_EXT_device_memory_report.adoc | 38 We want to make this extension tied to the device's lifecycle.
64 We are interested in both alloc/free and import/unimport.
85 We believe there are some cases where drivers can allocate device memory
124 We are not asking the implementation to report ename:VK_OBJECT_TYPE_PIPELINE
|
| D | VK_EXT_rgba10x6_formats.adoc | 30 *RESOLVED*: We reuse an existing format enumeration,
|
| D | VK_NV_inherited_viewport_scissor.adoc | 41 We considered both adding a new ftext:vkCmdSetViewportDepthNV function, and
75 We considered adding a new stext:VkViewportDepthNV struct containing only
|
| D | VK_KHR_swapchain_mutable_format.adoc | 53 We simply use the same slink:VkImageFormatListCreateInfoKHR structure
|
| D | VK_NV_shading_rate_image.adoc | 87 We are including a mechanism to allow applications to specify the orders of
92 We will not be providing a query to determine the implementation-dependent
105 *RESOLVED* We are specifying the pipeline stage to be between the final
|
| D | VK_KHR_sampler_mirror_clamp_to_edge.adoc | 71 We realized shortly before public release that not all implementations could
|
| /hardware/google/gfxstream/third-party/glm/include/glm/detail/ |
| D | type_half.inl | 141 // We convert f to a half zero.
151 // We convert f to a denormalized half.
205 // We try to convert f to a normalized half.
|
| /hardware/google/gfxstream/guest/android-emu/aemu/base/fit/ |
| D | README | 54 necessarily be somewhat low-level but high impact. We don't want to add code to
55 FIT simply because we think it's cool. We need evidence that it is a common
126 - We have observed several re-implementations of the same idea throughout the
133 We were able to replace its hand-rolled lifetime management code with
137 - Case study: We have previously observed bugs where developers were
|
| /hardware/interfaces/security/authgraph/aidl/android/hardware/security/authgraph/ |
| D | DicePolicy.cddl | 25 ; We may add a hashConstraint item later
|
| /hardware/google/gfxstream/codegen/vulkan/vulkan-docs-next/proposals/ |
| D | VK_EXT_shader_module_identifier.adoc | 36 We can just hand back the hash to the implementation instead.
39 We can reuse the main idea of a "non-blocking" compile where we return early if pipeline compilatio…
59 We can store SPIR-V on-disk and reload that in response to a pipeline creation call,
64 We have observed >95% disk savings with this scenario, and this is transformative since it makes it…
84 We then set `VkPipelineShaderStageCreateInfo::module` to `VK_NULL_HANDLE` and chain in `VkPipelineS…
|
| D | VK_EXT_shader_tile_image.adoc | 80 We will therefore expose separate feature bits for color, depth, and stencil access.
129 …*** (We could relax this in a further extension if we wanted to support format reinterpretation in…
228 Add new type: `TileImage`. We have two options for defining `TileImage`:
237 ** (We could relax this in a further extension if we wanted to support format reinterpretation in t…
409 We call these resources tile images.
424 Some implementations pay a performance cost to guarantee raster order access. We need to give them …
464 In SPIR-V, input attachments use images with Dim of SubpassData. We use a new Dim so we can easily …
481 …agments read some implementation-defined pixel from the input attachments. We could define stronge…
499 We have lazily allocated images in Vulkan, but they do not guarantee that memory is not allocated.
|
| D | VK_EXT_image_compression_control.adoc | 23 We want to expose an API mechanism that abstracts the implementation-specific details.
26 We want to expose a query to let applications understand what compression rates are available and w…
42 …. Describe them as bytes per 'block' of compressed data. We would likely need to describe the dime…
|
| /hardware/google/gfxstream/guest/vulkan_enc/ |
| D | vkQueueFlushCommandsGOOGLE_encode_impl.cpp.inl | 4 // We won't use the lock if this command is used (VulkanQueueSubmitWithCommands is enabled)
|
| /hardware/google/gfxstream/codegen/vulkan/vulkan-docs-next/ |
| D | CONTRIBUTING.adoc | 29 We use a short license in each file consisting of just the copyright
|
| D | COPYING.adoc | 36 license statement. We have not added SPDX license identifiers to such
83 A: We are using a dual license on `vk.xml` and `video.xml`, to make them
|
| D | BUILD.adoc | 285 We recommend using Inkscape to modify or create new images, due to problems
305 We use many custom Ruby macros in the reference pages and API spec
319 We (may) eventually tool up the spec and reference pages to the point that
363 We use an HTML stylesheet `config/khronos.css` derived from the
399 We will occasionally update this image if needed, and we recommend people
438 We do not actively support building outside of our Docker image, but it is
|
| /hardware/interfaces/security/rkp/ |
| D | README.md | 25 the secure components. We refer to the public half of this asymmetric key pair
67 hardware-bound identifiers for the device, we must limit access to them. We
86 structure to contain a COSE\_Key with a public key in it. We call this a
112 We believe that Curve25519 offers the best tradeoff in terms of security,
|
| /hardware/google/gfxstream/codegen/vulkan/vulkan-docs-next/config/ |
| D | README.adoc | 44 We use a number of Asciidoctor customizations written in Ruby, described
|
| /hardware/interfaces/neuralnetworks/utils/ |
| D | README.md | 75 We use NDK backend for AIDL interfaces. Handling of lifetimes is generally the same with the
116 We use NDK backend for AIDL interfaces. Handling of asynchronous calls is generally the same with
|
| /hardware/interfaces/gnss/1.0/ |
| D | IGnssGeofenceCallback.hal | 38 * Inside state: We are 95% confident that the user is inside the geofence.
39 * Outside state: We are 95% confident that the user is outside the geofence
|
| /hardware/google/gfxstream/host/ |
| D | NativeSubWindow_cocoa.mm | 95 // We cannot use the dpr from [NSScreen mainScreen], which usually
|
| /hardware/google/gfxstream/host/vulkan/emulated_textures/shaders/ |
| D | AstcToBc3.comp | 42 // only do the PCA step and we use the min and max colors as the endpoints. We should instead see
49 // - Use BC1 instead of BC3 if the image doesn't contain semi-transparent pixels. We will need to
217 // We can't use gl_LocalInvocationID here because the spec doesn't make any guarantees as to how
|
1234