| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
The CS thread is needed to ensure proper ordering of operations and can't
be disabled (without complicating the code).
Discovered by Nine CSMT, which ended up in a deadlock.
Acked-by: Edward O'Callaghan <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
|
| |
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
|
| |
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
v2: use gfxip names for llvm 4.0+
v3: use tonga for llvm <= 3.8, drop gfxip name,
we can just change that we change the other asics.
Reviewed-by: Marek Olšák <[email protected]>
Signed-off-by: Junwei Zhang <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
Acked-by: Christian König <[email protected]>
|
| |
|
|
|
| |
Tested-by: Edmondo Tommasina <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
|
|
|
|
| |
FORCE_TILING should disable it. It has no effect now, but that may change
soon.
Tested-by: Edmondo Tommasina <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
GCN can use a completely different tile mode for FMASK.
FMASK allocation now skips one unrelated amdgpu_surface_init codepath as
hinted by the assertion.
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
|
|
|
| |
I expect no change in behavior, because r600_texture.c forces the same
tile mode as the base texture has.
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
|
|
| |
these names were misleading.
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
This removes input-only parameters from the radeon_surf structure.
Some of the translation logic from pipe_resource to radeon_surf is moved to
winsys/radeon.
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Maybe this is why SDMA has been broken for many amdgpu users?
SDMA is the only block which is used with imported textures and relies
on this variable. DB also uses it, but it doesn't get imported textures,
so it's unaffected.
I do get SDMA failures on Tonga before this patch if R600_DEBUG=testdma
is changed to use imported textures.
Cc: 11.2 12.0 13.0 <[email protected]>
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
so that decompress blits aren't needed and depth texturing needs less
memory bandwidth.
Z16 and Z24 are promoted to Z32_FLOAT by the driver, because TC-compatible
HTILE only supports Z32_FLOAT. This doubles memory footprint for Z16.
The format promotion is not visible to state trackers.
This is part of TC-compatible renderbuffer compression, which has 3 parts:
DCC, HTILE, FMASK. Only TC-compatible FMASK compression is missing now.
I don't see a measurable increase in performance though.
(I tested Talos Principle and DiRT: Showdown, the latter is improved by
0.5%, which is almost noise, and it originally used layered Z16,
so at least we know that Z16 promoted to Z32F isn't slower now)
Tested-by: Edmondo Tommasina <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
which is returned for GL_MAX_TEXTURE_BUFFER_SIZE.
It doesn't have any other use at the moment.
Bigger allocations are not rejected.
This fixes GL45-CTS.texture_buffer.texture_buffer_max_size on Bonaire.
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
|
| |
|
|
|
|
|
| |
Small buffers are now handled via the slabs code, so separate buckets in
pb_cache have become redundant.
Reviewed-by: Marek Olšák <[email protected]>
|
| |
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
|
| |
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
|
| |
|
|
|
|
| |
Already adjust amdgpu_bo_map/unmap accordingly.
Reviewed-by: Marek Olšák <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a buffer is added to a CS without the SYNCHRONIZED usage flag, we now
no longer add a dependency on the buffer's fence(s).
However, we still need to add a fence to the buffer during flush, so that
cache reclaim works correctly (and in the hypothetical case that the buffer
is later added to a CS _with_ the SYNCHRONIZED flag).
It is now possible that the submissions refererring to a buffer are no longer
linearly ordered, and so we may have to keep multiple fences around. We keep
the fences in a FIFO. It should usually stay quite short (# of contexts * 2,
for gfx + dma rings).
While we're at it, extract amdgpu_add_fence_dependency for a single buffer,
which will make adding the distinction between real buffer and slab cases
easier.
Reviewed-by: Marek Olšák <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When passed to winsys->buffer_create, this flag will indicate that we require
a buffer that maps 1:1 with a kernel buffer handle.
This is currently set for all textures, since textures can potentially be
exported to other processes. This is not a huge loss, since the main purpose
of this patch series is to deal with applications that allocate many small
buffers.
A hypothetical application with tons of tiny textures might still benefit
from not setting this flag, but that's not a use case I'm worried about
just now.
Reviewed-by: Marek Olšák <[email protected]>
|
| |
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
Android porting of the following commits:
f1f1ba3 "radeonsi: move sid.h/r600d_common.h to a common place."
69fca64 "amd/addrlib: move addrlib from amdgpu winsys to common code"
This patch fixes android building errors
Reviewed-by: Dave Airlie <[email protected]>
|
| |
|
|
|
|
|
| |
The radeonsi driver doesn't and shouldn't care about the buffer index.
Only the virtual addresses matter.
Reviewed-by: Marek Olšák <[email protected]>
|
| |
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
|
| |
|
|
|
|
| |
It's really not necessary.
Reviewed-by: Marek Olšák <[email protected]>
|
| |
|
|
|
|
|
| |
While at it, try to be a little more robust in the face of memory allocation
failure.
Reviewed-by: Marek Olšák <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
The fence that is added to the BO during flush is guaranteed to be
signaled after all the fences that were in the fences array of the BO
before the flush, because those fences are added as dependencies for the
submission (and all this happens atomically under the bo_fence_lock).
Therefore, keeping only the last fence around is sufficient.
Reviewed-by: Marek Olšák <[email protected]>
|
| |
|
|
|
|
|
| |
The idea is to have matching init/deinit functions so that deinit can be
re-used for cleanup in the error path of amdgpu_winsys_create.
Reviewed-by: Marek Olšák <[email protected]>
|
| |
|
|
|
|
|
| |
No need to call pb_cache_deinit, because the cache hasn't been initialized
at that point.
Reviewed-by: Marek Olšák <[email protected]>
|
| |
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
|
| |
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
|
|
| |
Not all buffers are unmapped explicitly.
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
|
| |
Acked-by: Marek Olšák <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
Step one to merging radv would be to move some files around.
This only adds the include path to r600/radeonsi, because later
we want to avoid having to add it to the generic target paths.
Acked-by: Marek Olšák <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
|
| |
Reviewed-by: Edward O'Callaghan <[email protected]>
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
|
| |
|
|
| |
Reviewed-by: Edward O'Callaghan <[email protected]>
|
| |
|
|
|
| |
Signed-off-by: Marek Olšák <[email protected]>
Reviewed-by: Edward O'Callaghan <[email protected]>
|
| |
|
|
|
|
| |
If the kernel driver doesn't support it, it returns 0.
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
|
| |
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
|
|
| |
no app calls this AFAIK
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
|
|
|
| |
The radeon kernel module doesn't have the firmware query interface, so the
corresponding values will remain 0.
Reviewed-by: Marek Olšák <[email protected]>
|
| |
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
|
| |
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
|
