Am 28.12.2016 um 03:59 schrieb Yu, Xiangliang:
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
Of zhoucm1
Sent: Wednesday, December 28, 2016 10:32 AM
To: Yu, Xiangliang ; amd-
g...@lists.freedesktop.org
Cc: Liu, Monk
Subject: Re: [V2 1/1] drm/amd
Am 28.12.2016 um 04:17 schrieb Roger.He:
From: "Hongbo.He"
rollback to ttm default callback since OCL perf benchmark huge performance drop
Change-Id: If4cfc5a52872a7e00a7cbcad6efa46c57ee533de
Signed-off-by: Roger.He
NAK, as I wrote internally as well we need this for further KFD features.
> -Original Message-
> From: Christian König [mailto:deathsim...@vodafone.de]
> Sent: Wednesday, January 04, 2017 6:27 PM
> To: Yu, Xiangliang ; Zhou, David(ChunMing)
> ; amd-gfx@lists.freedesktop.org
> Cc: Liu, Monk
> Subject: Re: [V2 1/1] drm/amdgpu/gfx8: add support kernel interface
> q
Andres,
I have on rather generic design question:
Why we want to restrict it to CAP_SYS_ADMIN?
+ if (priority == AMD_SCHED_PRIORITY_HIGH && !capable(CAP_SYS_ADMIN))
+ return -EACCES;
Should we make it generic? My understanding is that If we follow "nice" semantic
then it wil
Hi Andres,
I did not follow the previous discussion, so please remind me if my questions
have been covered already~
- The priority should be the queue properties, and do we really want to expose
high priority on none-compute queue?
- Another question is we may need to do per submission priority t
Am 04.01.2017 um 12:03 schrieb Sagalovitch, Serguei:
Andres,
I have on rather generic design question:
Why we want to restrict it to CAP_SYS_ADMIN?
+ if (priority == AMD_SCHED_PRIORITY_HIGH && !capable(CAP_SYS_ADMIN))
+ return -EACCES;
Should we make it generic? My underst
Am 04.01.2017 um 12:34 schrieb Yu, Xiangliang:
-Original Message-
From: Christian König [mailto:deathsim...@vodafone.de]
Sent: Wednesday, January 04, 2017 6:27 PM
To: Yu, Xiangliang ; Zhou, David(ChunMing)
; amd-gfx@lists.freedesktop.org
Cc: Liu, Monk
Subject: Re: [V2 1/1] drm/amdgpu/gfx
> >> Am 28.12.2016 um 03:59 schrieb Yu, Xiangliang:
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On
> Behalf Of zhoucm1
> Sent: Wednesday, December 28, 2016 10:32 AM
> To: Yu, Xiangliang ; amd-
> g...@lists.freedesktop.org
Hi Andres,
Pardon for jumping in uninvited, there's a few comments below that you
might find useful.
On 4 January 2017 at 01:56, Andres Rodriguez wrote:
> --- a/configure.ac
> +++ b/configure.ac
> @@ -20,7 +20,7 @@
>
> AC_PREREQ([2.63])
> AC_INIT([libdrm],
> -[2.4.74],
> +[2.4
Am 04.01.2017 um 14:26 schrieb Yu, Xiangliang:
Am 28.12.2016 um 03:59 schrieb Yu, Xiangliang:
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On
Behalf Of zhoucm1
Sent: Wednesday, December 28, 2016 10:32 AM
To: Yu, Xiangliang ; amd-
g...@lists.freedesktop.
> -Original Message-
> From: Christian König [mailto:deathsim...@vodafone.de]
> Sent: Wednesday, January 04, 2017 10:13 PM
> To: Yu, Xiangliang ; Zhou, David(ChunMing)
> ; amd-gfx@lists.freedesktop.org; Liu, Monk
>
> Subject: Re: [V2 1/1] drm/amdgpu/gfx8: add support kernel interface
> que
On Wed, Jan 4, 2017 at 1:52 AM, Huang Rui wrote:
> 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,
Thanks for the feedback Emil, it is very welcome :)
On 1/4/2017 8:47 AM, Emil Velikov wrote:
Hi Andres,
Pardon for jumping in uninvited, there's a few comments below that you
might find useful.
On 4 January 2017 at 01:56, Andres Rodriguez wrote:
--- a/configure.ac
+++ b/configure.ac
@@ -20,
Hi David,
On 2017-01-04 06:54 AM, Mao, David wrote:
Hi Andres,
I did not follow the previous discussion, so please remind me if my questions
have been covered already~
- The priority should be the queue properties, and do we really want to expose
high priority on none-compute queue?
I exposin
Hey Serguei
On 2017-01-04 07:56 AM, Christian König wrote:
Am 04.01.2017 um 12:03 schrieb Sagalovitch, Serguei:
Andres,
I have on rather generic design question:
Why we want to restrict it to CAP_SYS_ADMIN?
+ if (priority == AMD_SCHED_PRIORITY_HIGH &&
!capable(CAP_SYS_ADMIN))
+
On 17-01-03 08:47 PM, Andres Rodriguez wrote:
> 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 c
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
v3: Swap enum values of
From: Tony Cheng
- also fix YCbCr420 supported on Polaris and up
Change-Id: I96c8ea9544ba6aa50841a2b4ca3d03b927916ca2
Signed-off-by: Tony Cheng
Reviewed-by: Hersen Wu
Reviewed-by: Harry Wentland
---
.../gpu/drm/amd/display/dc/dce/dce_link_encoder.c | 31 --
.../gpu/drm/a
From: Hersen Wu
Change-Id: Ia0e5ede4f3790c32c292ac381d6d373f507640b0
Signed-off-by: Hersen Wu
Reviewed-by: Harry Wentland
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 4 +---
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 4 ++--
drivers/gpu/drm/amd/display/dc/core/dc_link_
From: Roman Li
For dpms usecase we need to set surface transfer function
regardless of gamma set flag.
Change-Id: Ic9bade55ef72e16222569d4e3a18bab610a4b011
Signed-off-by: Roman Li
Reviewed-by: Tony Cheng
Acked-by: Harry Wentland
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 22 +++
* bunch of small patches to enable DP PHY compliance
* gamma fix
* minor link_encoder cleanup
Hersen Wu (2):
drm/amd/display: Fix link retraining hw sequence for auto test
drm/amd/display: Fix DP PHY test pre-emphasis not set properly
Roman Li (1):
drm/amd/display: fix gamma for dpms usecas
From: Tony Cheng
- remove unnecessary feature flags
- remove wireless and VGA validation
Change-Id: Ia7b5939276667cd1be35f7f3dcc3b756545089f3
Signed-off-by: Tony Cheng
Reviewed-by: Harry Wentland
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 8 +--
.../gpu/drm/amd/display/dc/dce/d
From: Hersen Wu
Change-Id: I7d910d09c8af042218aa0853abe041c2726856bc
Signed-off-by: Hersen Wu
Reviewed-by: Hersen Wu
Acked-by: Harry Wentland
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 15 +++
drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c| 9 +
d
From: Zeyu Fan
Change-Id: I1caba702ffa75745bdf3c90c90f9c34faad68016
Signed-off-by: Zeyu Fan
Reviewed-by: Hersen Wu
Acked-by: Harry Wentland
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 15 +++
drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c | 49 +-
driv
Hi
I get the following warnings when using GCC 6.3 and the new
amd-staging-drm-next branch
axion agd5f # make -j20
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CHK include/generated/timeconst.h
CHK include
Thanks, Mike.
Fixing these warnings is on my ToDo list. Expect a patch in the next
couple of days to fix these.
Harry
On 2017-01-04 04:51 PM, Mike Lothian wrote:
Hi
I get the following warnings when using GCC 6.3 and the new
amd-staging-drm-next branch
axionagd5f # make -j20
CHK inc
Current amdgpu allows to disable PCI IO bar but the dmesg still prints it as an
error. It misleads a false alarm to the user and we are receiving those reports
from time to time. Attached patch turns this print from ERROR to INFO.
Amber Lin
Vertical Workstation/Compute
x72135
(289)695-2135
0
This patch is for reference only, as the corresponding kernel change is
still under review.
Signed-off-by: Andres Rodriguez
---
include/drm/amdgpu_drm.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index 3961836..2d3
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
Hey Emil,
Wanted to check if this is more or less what you were thinking in terms
of updating amdgpu_drm.h.
Patch 2 sent as a reference, and waiting for the kernel change to get
merged before sending out the final version.
Regards,
Andres
___
amd-gfx
Generated using make headers_install from:
airlied/drm-next 2cf026a Merge branch 'linux-4.10' ...
Manually re-added missing RADEON_TILING_R600_NO_SCANOUT as documented on
README
Signed-off-by: Andres Rodriguez
---
include/drm/README | 7 +-
include/drm/amdgpu_drm.h | 387 +++
As talked with David. They not only need to know whether the CG/PG is
supported, but also need to
know current CG/PG state.
we added the profile mode, so in runtime, user can disable/enable cg.
Then user wanted to confirm current cg state.
So we may need to export cg/pg mask and current cg/pg
Hey guys,
Just curious if there are any updates on the topic of shared semaphores for
amdgpu discussed here:
https://lists.freedesktop.org/archives/amd-gfx/2016-December/003777.html
I wasn't subscribed to amd-gfx yet when the topic started, so replying to it
directly is cumbersome.
Regards,
An
Sorry, update.
User just need to know the cg/pg feature's state(enable/disable), not current
CG state.
Best Regards
Rex
-Original Message-
From: Zhu, Rex
Sent: Thursday, January 05, 2017 11:34 AM
To: Huang, Ray; Deucher, Alexander
Cc: amd-gfx@lists.freedesktop.org; Mao, David; Fu,
On 05/01/17 05:51 AM, Andres Rodriguez wrote:
> On 2017-01-04 06:54 AM, Mao, David wrote:
>> Hi Andres,
>> I did not follow the previous discussion, so please remind me if my
>> questions have been covered already~
>> - The priority should be the queue properties, and do we really want
>> to expose
Hi Andres,
We have a local change made yesterday which eliminate the need to get unused fd
in the creation time.
If everything goes well, I expect the change could be sent out for review next
week.
Best Regards,
David
From: Andres Rodriguez [mailto:andr...@valvesoftware.com]
Sent: Thursday, Jan
36 matches
Mail list logo
