- 06 Jun, 2017 7 commits
-
-
Huang Rui authored
Signed-off-by:
Huang Rui <ray.huang@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Acked-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
- 01 Jun, 2017 7 commits
-
-
Leo Liu authored
We are using PSP to resume firmware after suspend, and it is resumed at where it got suspended, so we'd better save the the context. Signed-off-by:
Leo Liu <leo.liu@amd.com> Reviewed-by:
-
Leo Liu authored
To simplify vce bo create Signed-off-by:
-
Leo Liu authored
Signed-off-by:
-
Alex Xie authored
In review, Christian would like to keep the logic inside amdgpu_vm.c with a cost of slightly slower. The loop is still optimized out with this patch. v2: remove the if statement. Now it is not slower. Signed-off-by:
Alex Xie <AlexBin.Xie@amd.com> Reviewed-by:
Christian König <christian.koeng@amd.com> Signed-off-by:
-
Rex Zhu authored
Signed-off-by:
Rex Zhu <Rex.Zhu@amd.com> Reviewed-by:
-
Rex Zhu authored
Signed-off-by:
-
Rex Zhu authored
Use the vbios to look up the default frequencies for socclk and dcefclk. Signed-off-by:
-
- 31 May, 2017 26 commits
-
-
Andres Rodriguez authored
Spreading the load across multiple SDMA engines can increase memory transfer performance. Signed-off-by:
Andres Rodriguez <andresx7@gmail.com> Reviewed-by:
Nicolai Hähnle <nicolai.haehnle@amd.com> Signed-off-by:
-
Andres Rodriguez authored
Depending on usage patterns, the current LRU policy may create a non-injective mapping between userspace ring ids and kernel rings. This behaviour is undesired as apps that attempt to fill all HW blocks would be unable to reach some of them. This change forces the LRU policy to create bijective mappings only. v2: compress ring_blacklist v3: simplify amdgpu_ring_is_blacklisted() logic Signed-off-by:
-
Andres Rodriguez authored
Use an LRU policy to map usermode rings to HW compute queues. Most compute clients use one queue, and usually the first queue available. This results in poor pipe/queue work distribution when multiple compute apps are running. In most cases pipe 0 queue 0 is the only queue that gets used. In order to better distribute work across multiple HW queues, we adopt a policy to map the usermode ring ids to the LRU HW queue. This fixes a large majority of multi-app compute workloads sharing the same HW queue, even though 7 other queues are available. v2: use ring->funcs->type instead of ring->hw_ip v3: remove amdgpu_queue_mapper_funcs v4: change ring_lru_list_lock to spinlock, grab only once in lru_get() Signed-off-by:
-
Andres Rodriguez authored
Add amdgpu_queue_mgr, a mechanism that allows disjointing usermode's ring ids from the kernel's ring ids. The queue manager maintains a per-file descriptor map of user ring ids to amdgpu_ring pointers. Once a map is created it is permanent (this is required to maintain FIFO execution guarantees for a context's ring). Different queue map policies can be configured for each HW IP. Currently all HW IPs use the identity mapper, i.e. kernel ring id is equal to the user ring id. The purpose of this mechanism is to distribute the load across multiple queues more effectively for HW IPs that support multiple rings. Userspace clients are unable to check whether a specific resource is in use by a different client. Therefore, it is up to the kernel driver to make the optimal choice. v2: remove amdgpu_queue_mapper_funcs v3: made amdgpu_queue_mgr per context instead of per-fd v4: add context_put on error paths v5: rebase and include new IPs UVD_ENC & VCN_* v6: drop unused amdgpu_ring_is_valid_index (Alex) Reviewed-by:
-
Andres Rodriguez authored
Tonga based asics may experience hangs when an HQD's EOP parameters are modified. Workaround this HW issue by avoiding writes to these registers for tonga asics. Based on the following ROCm commit: 2a0fb8 - drm/amdgpu: Synchronize KFD HQD load protocol with CP scheduler From the ROCm git repository: https://github.com/RadeonOpenCompute/ROCK-Kernel-Driver.git CC: Jay Cornwall <Jay.Cornwall@amd.com> Suggested-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
-
Andres Rodriguez authored
The MQD structure matches the reg layout. Take advantage of this to simplify HQD programming. Note that the ACTIVE field still needs to be programmed last. Suggested-by:
-
Andres Rodriguez authored
Instead of taking the first pipe and giving the rest to kfd, take the first 2 queues of each pipe. Effectively, amdgpu and amdkfd own the same number of queues. But because the queues are spread over multiple pipes the hardware will be able to better handle concurrent compute workloads. amdgpu goes from 1 pipe to 4 pipes, i.e. from 1 compute threads to 4 amdkfd goes from 3 pipe to 4 pipes, i.e. from 3 compute threads to 4 v2: fix policy comment Reviewed-by:
Edward O'Callaghan <funfunctor@folklore1984.net> Reviewed-by:
-
Andres Rodriguez authored
Instead of picking an arbitrary queue for KIQ, search for one according to policy. The queue must be unused. Also report the KIQ as an unavailable resource to KFD. In testing I ran into KCQ initialization issues when using pipes 2/3 of MEC2 for the KIQ. Therefore the policy disallows grabbing one of these. v2: fix (ring.me + 1) to (ring.me -1) in amdgpu_amdkfd_device_init Reviewed-by:
-
Andres Rodriguez authored
The assumption that we are only using the first pipe no longer holds. Instead, calculate the queue_mask from the queue_bitmap. Acked-by:
-
Andres Rodriguez authored
Pipes provide better concurrency than queues, therefore we want to make sure that apps use queues from different pipes whenever possible. Optimize for the trivial case where an app will consume rings in order, therefore we don't want adjacent rings to belong to the same pipe. Reviewed-by:
-
Andres Rodriguez authored
This information is already available in adev. Reviewed-by:
-
Andres Rodriguez authored
Update the KGD to KFD interface to allow sharing pipes with queue granularity instead of pipe granularity. This allows for more interesting pipe/queue splits. v2: fix overflow check for res.queue_mask v3: fix shift overflow when setting res.queue_mask v4: fix comment in is_pipeline_enabled() v5: clamp res.queue_mask to the first MEC only Reviewed-by:
-
Andres Rodriguez authored
The current implementation is hardcoded to enable ME1/PIPE0 interrupts only. This patch allows amdgpu to enable interrupts for any pipe of ME1. v2: added gfx9 support v3: use soc15_grbm_select for gfx9 Acked-by:
-
Andres Rodriguez authored
Previously the queue/pipe split with kfd operated with pipe granularity. This patch allows amdgpu to take ownership of an arbitrary set of queues. It also consolidates the last few magic numbers in the compute initialization process into mec_init. v2: support for gfx9 v3: renamed AMDGPU_MAX_QUEUES to AMDGPU_MAX_COMPUTE_QUEUES v4: fix off-by-one in num_mec checks in *_compute_queue_acquire Reviewed-by:
-
Andres Rodriguez authored
Make amdgpu the owner of all per-pipe state of the HQDs. This change will allow us to split the queues between kfd and amdgpu with a queue granularity instead of pipe granularity. This patch fixes kfd allocating an HDP_EOP region for its 3 pipes which goes unused. v2: support for gfx9 v3: fix gfx7 HPD intitialization Reviewed-by:
-
Andres Rodriguez authored
Take ownership of pipe initialization away from KFD. Note that hpd_eop_gpu_addr was already large enough to accomodate all pipes. Reviewed-by:
-
Andres Rodriguez authored
Rename straggler instances of r(adeon)dev to a(mdgpu)dev Reviewed-by:
-
Andres Rodriguez authored
The return value from copy_form_user is 0 for the success case. Reviewed-by:
-
Andres Rodriguez authored
Use the same gfx_*_mqd_commit function for kfd and amdgpu codepaths. This removes the last duplicates of this programming sequence. v2: fix cp_hqd_pq_wptr value Reviewed-by:
-
Andres Rodriguez authored
The gfxv7 contains a slightly different version of cik_mqd called bonaire_mqd. This can introduce subtle bugs if fixes are not applied in both places. Reviewed-by:
-
Andres Rodriguez authored
Handle HQD deactivation timeouts instead of ignoring them. Reviewed-by:
-
Andres Rodriguez authored
The MQD programming sequence currently exists in 3 different places. Refactor it to absorb all the duplicates. The success path remains mostly identical except for a slightly different order in the non-kiq case. This shouldn't matter if the HQD is disabled. The error handling paths have been updated to deal with the new code structure. v2: the non-kiq path for gfxv8 was dropped in the rebase v3: split MEC_HPD_SIZE rename, dropped doorbell changes Reviewed-by:
-
Andres Rodriguez authored
Rename MEC_HPD_SIZE to GFXN_MEC_HPD_SIZE to clarify it is specific to a gfx generation. Signed-off-by:
-
Rex Zhu authored
Signed-off-by:
-
Rex Zhu authored
This reverts commit f8fdaa0e7b81698ba2ad8c2d20c7f9a44c75e0c6. firmware add support for this feature, so still ctrl by vbios. Signed-off-by: -
Rex Zhu authored
Signed-off-by:
-
