- 07 Jun, 2017 1 commit
-
-
Alex Deucher authored
Always use the max for the family rather than the per sku limits. This makes sure the mask is always the max size to avoid reporting the wrong number of CUs. Reviewed-by:
Alex Xie <AlexBin.Xie@amd.com> Reviewed-by:
Andres Rodriguez <andresx7@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
- 06 Jun, 2017 28 commits
-
-
Alex Deucher authored
This was missing for gfx6. Acked-by:
Huang Rui <ray.huang@amd.com> Signed-off-by:
-
Alex Deucher 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 gfx9 was missed when this patch set was rebased to include gfx9. Acked-by:
Tom St Denis <tom.stdenis@amd.com> Acked-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
-
Alex Deucher 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. gfx9 was missed when these patches were rebased. Reviewed-by:
-
Hawking Zhang authored
vddc_dep_on_dal_pwrl is allocated and initialized in cz_hwmgr_backend_init Thus free the memory in cz_hwmgr_backend_fini Signed-off-by:
Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by:
-
Hawking Zhang authored
vddc_dep_on_dal_pwrl and vq_budgeting_table are allocated and initialized in rv_hwmgr_backend_init. Thus free the memory in rv_hwmgr_backend_fini Signed-off-by:
-
Eric Huang authored
For overclocking sclk and mclk. Signed-off-by:
Eric Huang <JinHuiEric.Huang@amd.com> Reviewed-by:
-
Rex Zhu authored
As the min clk may be large than boot level can support. in this case, just ignore the min clk. Signed-off-by:
Rex Zhu <Rex.Zhu@amd.com> Reviewed-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
Something writes over the first 8 MB so reserve this on vega10 until we root cause it. Signed-off-by:
-
Huang Rui authored
User is able to follow the ip block number to write the ip_block_mask for selecting the one which user would like to enable. 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:
-
Huang Rui authored
Signed-off-by:
-
Huang Rui authored
This patch moves invalidation into gart enable function from hw_init. Because we would like align the sequence calling between init and resume. 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:
-
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:
Christian König <christian.koeng@amd.com> Signed-off-by:
-
Rex Zhu authored
Signed-off-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 4 commits
-
-
Andres Rodriguez authored
Spreading the load across multiple SDMA engines can increase memory transfer performance. Signed-off-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:
-
