| /hardware/google/gfxstream/codegen/vulkan/vulkan-docs-next/scripts/ |
| D | compImages.sh | 7 # compareImages - compare all asciidoctor images in two branches
19 echo "Gathering images under compare/$1 compare/$2"
24 cp images/*.svg $img1
36 cp images/*.svg $img2
47 echo "= Image Comparison of Vulkan images in $branch1 $branch2
55 echo "== Images Common to Both Branches
58 # Identical images
61 # Where to generate comparison images
97 echo "== Identical images
107 echo "== Images only in $branch1
[all …]
|
| D | globalizeIncludes | 9 # be relative to specified attributes {generated} and {images}, ensuring
16 -e 's#image:images/#image:{images}/#g' \
17 -e 's#image::images/#image::{images}/#g' \
|
| D | antora-prep.py | 16 partials/, images/, etc. are located).
19 Image files are linked from the component 'images' directory
49 Images = 'images' variable
154 - category - file type - Pages, Partials, or Images. These are
251 # .svg .jpg .png are always images
261 self.category = Images
271 # images/ are treated specially since there is only a single
272 # directory and the component directory is already named Images.
280 # Images go under images/, not under images/images/
281 # This could fail if there were ever top-level images but as all
[all …]
|
| /hardware/google/gfxstream/codegen/vulkan/vulkan-docs-next/style/ |
| D | misc.adoc | 8 Images used in the Vulkan documents must be kept in the directory `images/`
11 Images should be authored in the open-source
14 This allows other people to easily edit your images in the future.
16 image editors have been observed to produce images incompatible with the PDF
19 Images must be authored at their actual image size in the HTML and PDF
21 In most cases, images are included as standalone figures and should occupy
29 As the PDF dimensions are more restrictive, images should not exceed these
40 images are scaled down lies is about 30-something pixels lower than that;
53 Text in images should usually appear at 12 point type so as to match that in
64 The font and color scheme used for existing images (black, red, and 50%
[all …]
|
| /hardware/google/gfxstream/codegen/vulkan/vulkan-docs-next/proposals/ |
| D | VK_EXT_swapchain_maintenance1.adoc | 23 * Impossible to release acquired images without presenting them
39 mode does not affect the actual swapchain images and their associated memory.
52 This requires swapchain implementations to allocate memory for all images
54 This is costly both in startup time, and potentially memory if all images are
65 === Releasing Acquired Images
68 application has acquired images from the old swapchain that it is no longer
70 However, it is unable to release those images before recreating the swapchain.
116 Each present mode may require a different number of images.
126 ** The swapchain would then allocate as many images to satisfy all present
128 * Increase the number of swapchain images as necessary when present mode is
[all …]
|
| D | VK_EXT_host_image_copy.adoc | 14 Copying data to optimal-layout images in Vulkan requires staging the data in a buffer first, and us…
25 …s, it will momentarily have twice as much memory allocated for its images (the images themselves a…
65 …utUUID` can be used to ensure compatible data layouts between memory and images when using `VK_HOS…
103 Defining regions to copy between images
120 …be `VK_HOST_IMAGE_COPY_MEMCPY_EXT`, in which case data is copied between images with no swizzling …
121 Current limitations on source and destination images necessarily lead to raw copies between images,…
159 Images that are used by these copy instructions must have the `VK_IMAGE_USAGE_HOST_TRANSFER_BIT` us…
228 Images in optimal layout are often swizzled non-linearly.
229 When copying between images and buffers, the GPU can perform the swizzling and address translations…
230 When copying between images and host memory however, the CPU needs to perform this swizzling.
|
| D | VK_EXT_image_sliced_view_of_3d.adoc | 27 . Allowing 2D array view of a 3D images, even when used for storage image
29 storage images without any significant change. Functionally, the
65 `VkImageViewSlicedCreateInfoEXT` changes how 3D images are accessed in shaders.
80 … feature is only supported for UAVs on D3D12, and in Vulkan it is only supported on storage images.
|
| D | VK_EXT_shader_tile_image.adoc | 88 image::{images}/tile_image.svg[align="center",title="Tile Image",align="center",opts="{imageopts}"]
90 …bled, the framebuffer is logically divided into a grid of non-overlapping tiles called tile images.
102 … the ability to access current (rasterization order) color values from tile memory via tile images.
113 Depth and stencil fetches use implicit tile images.
243 …`, `OpDepthTileImageRead`, `OpStencilTileImageRead` to read from color, depth, stencil tile images.
409 We call these resources tile images.
432 …SOLVED: Should this extension reuse OpTypeImage, or introduce a new type for declaring tile images?
434 OpTypeImage is reused with a special Dim for tile images, following what was done for subpass attac…
436 An alternative would have been to make tile images their own type, and introduce an OpTypeTileImage…
454 …A. Allow depth and stencil tile images to be declared as variables. Tile images are defined to map…
[all …]
|
| /hardware/google/gfxstream/codegen/vulkan/vulkan-docs-next/chapters/VK_KHR_display_swapchain/ |
| D | create_shared_swapchains.adoc | 7 …SharedSwapchainsKHR',desc='Create multiple swapchains that share presentable images',type='protos']
15 swapchains that share presentable images are created by calling:
35 presentable images must: match between all the swapchains.
38 images, swapchain creation will fail with the result code
41 Images presented to multiple swapchains must: be re-acquired from all of
44 the presentable images can: continue to be used.
|
| /hardware/google/gfxstream/codegen/vulkan/vulkan-docs-next/chapters/VK_KHR_swapchain/ |
| D | wsi.adoc | 15 A swapchain is an abstraction for an array of presentable images that are
17 The presentable images are represented by sname:VkImage objects created by
20 surfaces) is displayed at a time, but multiple images can: be queued for
43 The presentable images of a swapchain are owned by the presentation engine.
66 The presentation engine controls the order in which presentable images are
73 return of images after presentation.
75 referencing all of the images in the swapchain at initialization time,
108 pname:pCreateInfo->minImageCount presentable images.
110 While acquired by the application, presentable images can: be used in any
111 way that equivalent non-presentable images can: be used.
[all …]
|
| /hardware/google/gfxstream/codegen/vulkan/vulkan-docs-next/chapters/VK_GOOGLE_display_timing/ |
| D | queries.adoc | 8 ename:VK_PRESENT_MODE_FIFO_KHR so that presentable images are updated during
13 However, synchronizing the presentation of images with the RC does not
26 They need to know when presentable images were actually presented, and when
75 The rate at which an application renders and presents new images is known as
88 pname:refreshDuration), an application needs to determine when its images
96 This will create visual anomalies, because the images will not be displayed
100 presentation engine to not present images any sooner than every 33.33ms.
110 Adjustments to a larger IPD because of late images should happen quickly,
114 and if pname:presentMargin is consistently large, over multiple images.
217 images presented with fname:vkQueuePresentKHR.
[all …]
|
| /hardware/google/gfxstream/codegen/vulkan/vulkan-docs-next/appendices/ |
| D | VK_NV_corner_sampled_image.adoc | 19 extension refers to as "`corner-sampled`" images.
37 * The minimum level size is 2x2 for 2D images and 2x2x2 for 3D images.
57 aspect of the image organization and referred to such images as
58 "`corner-sampled images`".
71 . Do integer texel coordinates have a different range for corner-sampled images?
77 . Do unnormalized sampler coordinates work with corner-sampled images? Are there any functional dif…
|
| D | VK_KHR_display_swapchain.adoc | 27 1) Should swapchains sharing images each hold a reference to the images, or
28 should it be up to the application to destroy the swapchains and images in
32 The lifetime of presentable images is already complex enough.
39 respecify the mode or create a new swapchain and presentable images.
50 4) How can applications create multiple swapchains that use the same images?
67 images could be built up one at a time.
105 ** Allow creating multiple swapchains that share the same images using a
|
| D | VK_KHR_swapchain.adoc | 44 of the presentable images?
47 Unlike standard images, the implementation will allocate the memory backing
50 2) What operations are allowed on presentable images?
55 3) Does this extension support MSAA presentable images?
58 Presentable images are always single-sampled.
59 Multi-sampled rendering must use regular images.
64 4) Does this extension support stereo/multi-view presentable images?
69 All presentable images in a given swapchain use the same array size.
71 5) Are the layers of stereo presentable images half-sized?
92 7) Does flink:vkAcquireNextImageKHR block if no images are available?
[all …]
|
| D | VK_QNX_external_memory_screen_buffer.adoc | 21 memory objects, where they can be bound to images and buffers.
23 Some code:_screen_buffer images have implementation-defined _external
25 Sampler {YCbCr} conversion can: be used to sample from these images and
|
| D | VK_KHR_swapchain_mutable_format.adoc | 22 This extension allows processing of swapchain images as different formats to
27 presentable images with a different format than the one used to create the
43 This extension requires `VK_KHR_maintenance2` and presentable images of
|
| D | VK_EXT_host_image_copy.adoc | 23 images on the host processor, without staging the data through a
28 This extension additionally allows applications to copy data between images
74 copying to or from images?
76 *RESOLVED*: An existing issue with linear images is that when emulating
|
| D | VK_KHR_maintenance2.adoc | 33 * Allow creating images with usage flags that may not be supported for the
36 * Allow creating uncompressed image views of compressed images.
39 * Adds two new image layouts for depth stencil images to allow either the
51 aspect(s) of multi-aspect images can: be accessed as input attachments.
|
| /hardware/google/gfxstream/codegen/vulkan/vulkan-docs-next/chapters/VK_QNX_external_memory_screen_buffer/ |
| D | qnx_screen_buffer.adoc | 58 QNX Screen buffers may: represent images using implementation-specific
64 representation, images with external formats must: only be used as sampled
65 images, must: only be sampled with a sampler that has {YCbCr} conversion
68 Images that will be backed by a QNX Screen buffer can: use an external
72 Images can: be created with an external format even if the QNX Screen buffer
75 enable consistent handling of images from sources that might use either
86 properties, so Vulkan images bound to memory imported from a QNX Screen
89 be ename:VK_TRUE for images created with
|
| /hardware/google/gfxstream/codegen/vulkan/vulkan-docs-next/antora/ |
| D | Makefile | 18 # Rewrite Vulkan spec sources and images into the module directory, ROOT
47 ./images/*.svg \
58 ./images/tile_image.svg \
63 antora/modules/ROOT/images \
70 antora/modules/proposals/images \
|
| /hardware/google/gfxstream/codegen/vulkan/vulkan-docs-next/chapters/VK_EXT_swapchain_maintenance1/ |
| D | SwapchainPresentModeInfo.adoc | 25 slink:VkSwapchainPresentModeInfoEXT, images that have already been queued
28 The current image being queued for presentation and subsequent images will
45 ename:VK_PRESENT_MODE_FIFO_RELAXED_KHR: Images continue to be appended
48 subsequent images.
54 and subsequent images are appended to the FIFO queue and presented
|
| /hardware/google/gfxstream/guest/mesa/src/vulkan/runtime/ |
| D | vk_pipeline.c | 215 _mesa_sha1_update(&ctx, &rstate->images, sizeof(rstate->images)); in vk_pipeline_hash_shader_stage()
267 rs->images = VK_PIPELINE_ROBUSTNESS_IMAGE_BEHAVIOR_DEVICE_DEFAULT_EXT; in vk_pipeline_robustness_state_fill()
276 rs->images = shader_info->images; in vk_pipeline_robustness_state_fill()
285 rs->images = pipeline_info->images; in vk_pipeline_robustness_state_fill()
301 if (rs->images == VK_PIPELINE_ROBUSTNESS_IMAGE_BEHAVIOR_DEVICE_DEFAULT_EXT) in vk_pipeline_robustness_state_fill()
302 rs->images = vk_device_default_robust_image_behavior(device); in vk_pipeline_robustness_state_fill()
|
| D | vk_image.h | 204 * For 1D or 2D array images, this is the stride in bytes between array
205 * slices. For 3D images, this is the stride in bytes between fixed-Z
243 * For color images, we have three cases:
272 * For depth/stencil images, this is the aspectMask provided by
275 * For color images, we have three cases:
305 * This field will be 0 for 1D and 2D images, 2D views of 3D images, or
312 * This field will be 1 for 1D and 2D images or 2D views of 3D images.
|
| /hardware/google/gfxstream/guest/mesa/src/vulkan/wsi/ |
| D | wsi_common_x11.c | 669 * 1 and 3. Hence the ideal implementation needs only 2 images, but games in x11_get_min_image_count()
671 * hence they need to allocate 3 images. So let us do it for them. in x11_get_min_image_count()
676 * For Xwayland Venus reports four images as described in in x11_get_min_image_count()
1105 /* Total number of images ever pushed to a present queue. */
1107 /* Total number of images returned to application in AcquireNextImage. */
1110 struct x11_image images[0]; member
1221 return &chain->images[image_index].base; in x11_get_wsi_image()
1252 if (chain->images[i].pixmap == idle->pixmap) { in x11_handle_dri3_present_event()
1253 chain->images[i].busy = false; in x11_handle_dri3_present_event()
1270 struct x11_image *image = &chain->images[i]; in x11_handle_dri3_present_event()
[all …]
|
| D | wsi_common_headless.c | 76 /* For true mailbox mode, we need at least 4 images: in wsi_headless_surface_get_capabilities()
268 struct wsi_headless_image images[0]; member
279 return &chain->images[image_index].base; in wsi_headless_swapchain_get_wsi_image()
300 if (!chain->images[i].busy) { in wsi_headless_swapchain_acquire_next_image()
303 chain->images[i].busy = true; in wsi_headless_swapchain_acquire_next_image()
327 chain->images[image_index].busy = false; in wsi_headless_swapchain_queue_present()
340 if (chain->images[i].base.image != VK_NULL_HANDLE) in wsi_headless_swapchain_destroy()
341 wsi_destroy_image(&chain->base, &chain->images[i].base); in wsi_headless_swapchain_destroy()
459 size_t size = sizeof(*chain) + num_images * sizeof(chain->images[0]); in wsi_headless_surface_create_swapchain()
495 &chain->images[i].base); in wsi_headless_surface_create_swapchain()
[all …]
|