On 26.07.2017 19:42, Marek Olšák wrote:
On Wed, Jul 26, 2017 at 7:05 PM, Alex Deucher <alexdeuc...@gmail.com> wrote:
On Wed, Jul 26, 2017 at 8:15 AM, Nicolai Hähnle <nhaeh...@gmail.com> wrote:
On 26.07.2017 08:29, Michel Dänzer wrote:
On 25/07/17 05:28 PM, Nicolai Hähnle wrote:
On 22.07.2017 14:00, Daniel Stone wrote:
I don't have any great solution off the top of my head, but I'd be
inclined to bundle stride in with placement. TTBOMK (from having
looked at radv), buffers shared cross-GPU also need to be allocated
from a separate externally-visible memory heap. And at the moment,
lacking placement information at allocation time (at least for EGL
allocations, via DRIImage), that happens via transparent migration at
import time I think. Placement restrictions would probably also
involve communicating base address alignment requirements.
Stride isn't really in the same category as placement and base address
alignment, though.
Placement and base address alignment requirements can apply to all
possible texture layouts, while the concept of stride is specific to
linear layouts.
Also, the starting address of shareable buffers is generally aligned to
at least the CPU page size anyway. Do we know of any cases requiring
higher alignment than that, and if so, which address space does the
requirement apply to?
Only tiling modes, as Marek mentioned. We don't do tiling shares across
different GPUs right now.
Maybe we can do it in the future with gfx9 GPUs. But then the alignment
requirements should be known on both sides based on the tiling mode anyway
-- if they even apply for non-VRAM textures.
We should be able to do some 1D tiling modes. That doesn't have any
per sku alignment dependencies.
Yeah, I think 1D tiling for displayable 32bpp is compatible across all
radeon GPUs newer than R600.
All non-X non-VAR tiling modes on Radeon/GFX9 (Vega, Raven) are the
same on all GFX9 GPUs and might be the same on all future products.
The only catch is that X modes are better optimized for the memory
config, so non-X modes can be slower. I think the non-X modes might
also be compatible with Intel (the first 12 at least), so some
cross-vendor interface might be possible. All GFX9 tiling modes:
Right. It might be worth it to try to use some of these tiling modes to
make PRIME a bit more efficient in some cases. Non-X modes may be
non-optimal, but certainly they're better than linear :)
Cheers,
Nicolai
SW_LINEAR (256B pitch alignment)
SW_256B_S
SW_256B_D (compatible with older Radeons if bpp == 32)
SW_256B_R (compatible with older Radeons if bpp == 32)
SW_4KB_Z (Z = depth/stencil sample order)
SW_4KB_S (S = standard)
SW_4KB_D (D = displayable)
SW_4KB_R (R = displayable rotated)
SW_64KB_Z
SW_64KB_S
SW_64KB_D
SW_64KB_R
SW_VAR_Z (VAR = tile size depends on memory config)
SW_VAR_S
SW_VAR_D
SW_VAR_R
SW_64KB_Z_T
SW_64KB_S_T
SW_64KB_D_T
SW_64KB_R_T
SW_4KB_Z_X (X = optimized for memory config)
SW_4KB_S_X
SW_4KB_D_X
SW_4KB_R_X
SW_64KB_Z_X
SW_64KB_S_X
SW_64KB_D_X
SW_64KB_R_X
SW_VAR_Z_X
SW_VAR_S_X
SW_VAR_D_X
SW_VAR_R_X
Marek
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
