On Fri, Dec 23, 2016 at 04:45:52PM +0800, Rex Zhu wrote:
You need add signed-by-off and descriptions here.
> Change-Id: I4a46440882cd94fe5e77e3f351aaccc218a2ece5
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 17 +
> drivers/gpu/drm/amd/amdgpu/ci_dpm.c |
Signed-off-by: Huang Rui
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 5 +
drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 2 ++
drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 2 ++
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 3 +++
5 files changed, 13 insertions
Am 21.12.2016 um 16:12 schrieb Nicolai Hähnle:
On 16.12.2016 03:49, zhoucm1 wrote:
On 2016年12月16日 01:10, Nicolai Hähnle wrote:
From: Nicolai Hähnle
Ensure that the driver can listen to evictions even when they don't
take the
path through ttm_bo_driver::move.
This is crucial for amdgpu, which
NAK on that whole approach. We previously had similar handling in radeon
for the temporary IB buffer and it was a pain to support correctly.
The main problem is that you might then have a mismatch between the
housekeeping structures in the VM and what is really in the page tables
/ page direct
> -Original Message-
> From: Huang Rui [mailto:ray.hu...@amd.com]
> Sent: Tuesday, January 03, 2017 5:47 AM
> To: Deucher, Alexander; amd-gfx@lists.freedesktop.org
> Cc: Zhu, Rex; Mao, David; Fu, Ping; Huang, Ray
> Subject: [PATCH] drm/amdgpu: show gfx clock gating status to user
>
> Signe
Hi,
I didn't check others changes in the series. For these two specific changes
regarding the mailbox communication , I have two concerns
1. This code should only works on SRIOV enabled VF , in your code seems you use
adev->priv_data for the check , I would like to have some more meaning
Add a new context creation flag, AMDGPU_CTX_FLAG_HIGHPRIORITY. This flag
results in the allocated context receiving a higher scheduler priority
that other contexts system-wide.
Signed-off-by: Andres Rodriguez
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 24 ++--
driver
This patch series provides the initial APIs for high priority contexts.
The current implementation is based on top of the SW scheduler, there
are no HW priorities set yet.
This doesn't provide the quality of service we need for VR. Further changes
to enable HW priorities will be required.
For so
On Tue, Jan 3, 2017 at 5:54 PM, Andres Rodriguez wrote:
> Add a new context creation flag, AMDGPU_CTX_FLAG_HIGHPRIORITY. This flag
> results in the allocated context receiving a higher scheduler priority
> that other contexts system-wide.
>
> Signed-off-by: Andres Rodriguez
> ---
> drivers/gpu/d
I was thinking of that originally, but the allocation context already has a
flags variable which allows us to preserve the IOCTL ABI.
We could reserve a few bits of the flags for a priority level instead if
that sounds good?
Regards,
Andres
On Tue, Jan 3, 2017 at 5:59 PM, Alex Deucher wrote:
>
On Tue, Jan 3, 2017 at 6:00 PM, Andres Rodriguez wrote:
> I was thinking of that originally, but the allocation context already has a
> flags variable which allows us to preserve the IOCTL ABI.
>
> We could reserve a few bits of the flags for a priority level instead if
> that sounds good?
We can
Cool. Follow up question then:
We can either:
1. Expose a priority number
2. Expose a priority enum, e.g. PRIORITY_HIGH, PRIORITY_NORMAL (to start)
The HW can do numerical priorities, but the SW scheduler would require a
bit of rework to consume arbitrary priorities.
At least for our use case, I
Already got some feedback from Alex on my kernel patch, so this is going
to have to change accordingly.
Sending for completion. And I would also like feedback on whether the version
change is sufficient to indicate that a new function is being provided.
___
Add a new context creation function that allows specifying the context
priority.
A high priority context has the potential of starving lower priority
contexts. The current kernel driver implementation only allows only the
root user to allocate high priority contexts.
---
amdgpu/amdgpu.h
Add a new context creation parameter to express a global context priority.
Contexts allocated with AMDGPU_CTX_PRIORITY_HIGH will receive higher
priority to scheduler their work than AMDGPU_CTX_PRIORITY_NORMAL
(default) contexts.
v2: Instead of using flags, repurpose __pad
Signed-off-by: Andres R
This patch series provides the initial APIs for high priority contexts.
The current implementation is based on top of the SW scheduler, there
are no HW priorities set yet.
This doesn't provide the quality of service we need for VR. Further changes
to enable HW priorities will be required.
For so
Add a new context creation function that allows specifying the context
priority.
A high priority context has the potential of starving lower priority
contexts. The current kernel driver implementation only allows only the
root user to allocate high priority contexts.
v2: corresponding changes for
Corresponding libdrm changes for:
[PATCH v2] High priority usermode contexts
Comments on version bump appreciated.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Add a new extension VK_EXT_queue_global_priority, which allows the
caller to elevate a queue's priority above all other queues in the
system.
This extension aims to provide a mechanism for compositors to have
achieve a guaranteed quality of service, even when the hardware may be
loaded by a game o
This patch series implements VK_EXT_queue_global_priority, a vulkan extension
that focuses on providing scheduling guarantees.
For further information on the use case refer to:
https://lists.freedesktop.org/archives/amd-gfx/2016-December/004068.html
For some perf data on this initial implementati
Queues are independent execution streams. The vulkan spec provides no
ordering guarantees for different queues.
By using a single context for all queues, we are forcing all commands
into an unecessary FIFO ordering.
This change is a preparation step to allow our-of-ordering scheduling of
certain
Ooops sent this to the wrong list, sorry.
From: amd-gfx [amd-gfx-boun...@lists.freedesktop.org] on behalf of Andres
Rodriguez [andre...@gmail.com]
Sent: Tuesday, January 03, 2017 9:22 PM
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH] radv: Initial imple
On Tue, Jan 03, 2017 at 11:02:09PM +0800, Deucher, Alexander wrote:
> > -Original Message-
> > From: Huang Rui [mailto:ray.hu...@amd.com]
> > Sent: Tuesday, January 03, 2017 5:47 AM
> > To: Deucher, Alexander; amd-gfx@lists.freedesktop.org
> > Cc: Zhu, Rex; Mao, David; Fu, Ping; Huang, Ray
Hey Guys,
One of my first non-trivial contributions to mesa here. Let me know if I've
messed up anything, bad coding style or some patch validation script I
should've run or any other kind of pitfall a newbie might make.
I tried to follow the guidelines over at:
http://www.mesa3d.org/devinfo.html
On Wed, Jan 04, 2017 at 10:21:44AM +0800, Huang Rui wrote:
> On Tue, Jan 03, 2017 at 11:02:09PM +0800, Deucher, Alexander wrote:
> > > -Original Message-
> > > From: Huang Rui [mailto:ray.hu...@amd.com]
> > > Sent: Tuesday, January 03, 2017 5:47 AM
> > > To: Deucher, Alexander; amd-gfx@list
25 matches
Mail list logo
