Lines Matching refs:GPU
52 This extension enables novel multi-GPU rendering techniques by providing application control
55 Multi-GPU rendering techniques fall into two categories: implicit and explicit. Existing
57 application complexity. An application must manage one context per GPU and multi-pump the API
58 stream. Implicit multi-GPU rendering techniques avoid these issues by broadcasting rendering
60 rendering (AFR), split-frame rendering (SFR) and multi-GPU anti-aliasing. They each have
63 With multi-GPU anti-aliasing, each GPU renders the same content with alternate sample
67 These issues with implicit multi-GPU rendering all have the same root cause: the driver lacks
73 - One context controls multiple GPUs. Every GPU in the linked group can access every object.
77 - Each GPU gets its own instance of all framebuffers, allowing individualized output for each
78 GPU. Input data can be customized for each GPU using buffers created with the storage flag,
81 - New interfaces provide mechanisms to transfer textures and buffers from one GPU to another.
157 repeated across all enabled GPUs. Objects are shared by all GPUs, however each GPU has its
158 own instance (copy) of many resources, including framebuffers. When each GPU has its own
159 instance of a resource, it is considered to have per-GPU storage. When all GPUs share a
160 single instance of a resource, this is considered GPU-shared storage.
167 multicast GPUs. GPUs are also identified by bitmasks of the form 2^i, where i is the GPU
168 index. A set of GPUs is specified by the union of masks for each GPU in the set.
187 Render commands are skipped for a GPU that is not present in RENDER_GPU_MASK_NV. For example:
194 20.2 Multi-GPU Buffer Storage
196 Like other resources, buffer objects can have two types of storage, per-GPU storage or
197 GPU-shared storage. Per-GPU storage can be explicitly requested using the
200 transition between them at any time. Client reads of a buffer with per-GPU storage may source
201 from any GPU.
203 The following rules apply to buffer objects with per-GPU storage:
209 The following commands affect storage on all GPUs, even if the buffer object has per-GPU
224 This command operates similarly to NamedBufferSubData, except that it updates the per-GPU
225 buffer data on the set of GPUs defined by <gpuMask>. If <buffer> has GPU-shared storage,
249 source and destination GPU(s). The read GPU index is specified by <readGpu> and
256 type (per-GPU or GPU-shared) currently used for <writeBuffer>. If <writeBuffer> is using
257 GPU-shared storage, the normal error checks apply but the command behaves as if <writeGpuMask>
258 includes all GPUs. If <writeBuffer> is using per-GPU storage, the command behaves as if
288 20.3 Multi-GPU Framebuffers and Textures
290 All buffers in the default framebuffer as well as renderbuffers receive per-GPU storage. By
291 default, storage for textures is undefined: it may be per-GPU or GPU-shared and can transition
292 between the types at any time. Per-GPU storage can be specified via
312 This command operates equivalently to CopyImageSubData, except that it takes a source GPU and
313 a destination GPU set defined by <srcGpu> and <dstGpuMask> (respectively). Texel data is
314 copied from the source GPU to all destination GPUs. The following errors apply to
346 To copy pixel values from one GPU to another use the following command:
353 This command operates equivalently to BlitNamedFramebuffer except that it takes a source GPU
354 and a destination GPU defined by <srcGpu> and <dstGpu> (respectively). Pixel values are
355 copied from the read framebuffer on the source GPU to the draw framebuffer on the destination
356 GPU.
362 20.3.2 Per-GPU Sample Locations
364 Programmable sample locations can be customized for each GPU and framebuffer using the
379 MULTICAST_PROGRAMMABLE_SAMPLE_LOCATION_NV at the appropriate offset for the specified GPU.
395 Many existing commands can be used to copy between resources with GPU-shared, per-GPU or
400 Table 20.1 Behavior of Copy Commands with Multi-GPU Storage
404 GPU-shared GPU-shared There is just one source and one destination. Copy from source to
406 GPU-shared per-GPU There is a single source. Copy it to the destination on all GPUs.
407 GPU-shared undefined Either of the above behaviors for a GPU-shared source may apply.
409 per-GPU GPU-shared Copy from the GPU with the lowest index set in RENDER_GPU_MASK_NV to
411 per-GPU per-GPU Implementations are encouraged to copy from source to destination
412 separately on each GPU. This is not required. If and when this is not
413 feasible, the copy should source from the GPU with the lowest index set
415 per-GPU undefined Either of the above behaviors for a per-GPU source may apply.
417 undefined GPU-shared Either of the above behaviors for a GPU-shared destination may apply.
418 undefined per-GPU Either of the above behaviors for a per-GPU destination may apply.
421 20.5 Multi-GPU Synchronization
424 synchronization with previous work on the source GPU. MulticastBlitFramebufferNV is
425 different, providing implicit synchronization with previous work on the destination GPU.
437 GPU writes and reads to/from GPU-shared locations require synchronization as well. GPU writes
439 automatically synchronized with writes by other GPUs. Neither are GPU reads such as texture
442 for rendering, writes and reads on a single GPU.
445 on another GPU without synchronizing all GPUs with MulticastBarrierNV. This can be performed
459 the GPUs specified by waitGpuMask to wait until the GPU specified by <signalGpu> has completed
462 20.6 Multi-GPU Queries
465 values for each GPU. The result value for a specific GPU can be queried using one of the
474 return the result value for the specified GPU. A query may be available on one GPU but not on
475 another, so it may be necessary to check QUERY_RESULT_AVAILABLE for each GPU. GetQueryObject*
476 return query results and availability for GPU 0 only.
514 For each active render GPU, if the result (SAMPLES_PASSED) of the query on that GPU is
516 all rendering commands described in section 2.4 are discarded by this GPU and have no
528 For each active render GPU, if the result (SAMPLES_PASSED) of the query on that GPU is
532 Finally, replace all instances of "the GL" with "each active render GPU".
594 When using the functionality of EXT_bindable_uniform and a per-GPU storage buffer is bound
623 PER_GPU_STORAGE_NV B GetTexParameter FALSE Per-GPU storage requested 20.3
656 Binocular stereo rendering example using NV_gpu_multicast with single GPU fallback:
687 // Make GPU 1 wait for glClear above to complete on GPU 0
689 // Copy right viewport from GPU 1 to GPU 0
694 // Make GPU 0 wait for GPU 1 copy to GPU 0
702 // Both viewports are now present in GPU 0's renderbuffer
706 (1) Should we provide explicit inter-GPU synchronization API? Will this make the implementation
717 RESOLVED. Queries are performed separately on each GPU. The standard GetQueryObject* APIs
718 return query results for GPU 0 only. However GetQueryBufferObject* can be used to retrieve
727 These commands explicitly specify the GPU source and destination and are not influenced by the
732 RESOLVED. When the source and destination involve the same GPU, MulticastCopyBufferSubDataNV
734 INVALID_VALUE error results. When the source and destination do not involve the same GPU,
740 CopyTexImage* sources from the framebuffer, the source always has per-GPU storage.
742 (6) Should we provide a mechanism to modify viewports independently for each GPU?
746 (7) Should we add a present API that automatically displays content from a specific GPU? It
752 multi-GPU rendering techniques (e.g. checkerboard-style split rendering).
756 (8) Should we expose the extension on single-GPU configurations?
758 RESOLVED. Yes, this is recommended. It allows more code sharing between multi-GPU and
759 single-GPU code paths. If there is only one GPU present MULTICAST_GPUS_NV will be 1. It
760 may also be 1 if explicit GPU control is unavailable (e.g. if the active multi-GPU rendering
770 (10) Can a query be complete/available on one GPU and not another?
773 allows each GPU to begin conditional rendering in mode QUERY_WAIT without waiting on other
776 (11) How can custom texel data for be uploaded to each GPU for a given texture?
779 to a texture with per-GPU storage using MulticastCopyImageSubDataNV.
781 (12) Should we allow the waitGpuMask in MulticastWaitSyncNV to include the signal GPU?
783 RESOLVED. No. There is no reason for a GPU to wait on itself. This is effectively a no-op in
784 the command stream. Furthermore it is easy to confuse GPU indices and masks, so it is
795 RESOLVED. Yes, the render GPU mask applies to immediate mode rendering the same as other
806 per-GPU storage