On 4/30/21 6:24 AM, Michel Dänzer wrote:
On 2021-04-29 10:50 p.m., Bas Nieuwenhuizen wrote:
This reverts commit f258907fdd835e1aed6d666b00cdd0f186676b7c.
Same problem as "drm/amdgpu: Verify bo size can fit framebuffer size",
but because it gets checked earlier it now only triggers on the
modi
ome way to test this?
Christian.
Am 24.11.20 um 03:48 schrieb Pierre-Loup A. Griffais:
I just built my kernel with it and tested Horizon Zero Dawn on stock
Proton 5.13, and it doesn't seem to change things there.
This pattern looks identical as with before the kernel patch, as fa
I just built my kernel with it and tested Horizon Zero Dawn on stock
Proton 5.13, and it doesn't seem to change things there.
This pattern looks identical as with before the kernel patch, as far as
I can tell:
https://imgur.com/a/1fZWgNG
The last purple block is a piece of GPU work on the gf
It's otherwise properly supported, just needs exposing to userspace.
Signed-off-by: Pierre-Loup A. Griffais
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/dr
On 9/12/19 10:32 AM, Pierre-Loup A. Griffais wrote:
On 9/12/19 10:22 AM, Harry Wentland wrote:
On 2019-09-12 1:01 p.m., Kazlauskas, Nicholas wrote:
On 2019-09-12 12:44 p.m., Pierre-Loup A. Griffais wrote:
It's otherwise properly supported, just needs exposing to userspace.
Signed-o
Hello,
Applying this locally, the issue we were seeing with very high submit
times in high-end workloads seems largely gone. My methodology is to
measure the total time spent in DRM_IOCTL_AMDGPU_CS with `strace -T` for
the whole first scene of the Shadow of the Tomb Raider benchmark, and
divi
On 9/12/19 10:22 AM, Harry Wentland wrote:
On 2019-09-12 1:01 p.m., Kazlauskas, Nicholas wrote:
On 2019-09-12 12:44 p.m., Pierre-Loup A. Griffais wrote:
It's otherwise properly supported, just needs exposing to userspace.
Signed-off-by: Pierre-Loup A. Griffais
I know IGT has some test
It's otherwise properly supported, just needs exposing to userspace.
Signed-off-by: Pierre-Loup A. Griffais
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/dr
7;t want that.
Targeting something like Wayland and when you need X compatibility
XWayland sounds like the much better idea.
Regards,
Christian.
Am 22.12.2016 um 20:54 schrieb Pierre-Loup A. Griffais:
Display concerns are a separate issue, and as Andres said we have
other plans to address. But yes,
hrough the mesa radv UMD.
I'm not sure if I'm asking for too much, but if we can
coordinate a similar interface in radv and amdgpu-pro at the
vulkan level that would be great.
I'm not sure what that's going to be yet.
- Andres
On 12/19/2016 12:11 AM, zhoucm1 wrote:
On
coordinate a
similar interface in radv and amdgpu-pro at the vulkan level that
would be great.
I'm not sure what that's going to be yet.
- Andres
On 12/19/2016 12:11 AM, zhoucm1 wrote:
On 2016年12月19日 11:33, Pierre-Loup A. Griffais wrote:
We're currently working with the
On 12/18/2016 07:26 PM, zhoucm1 wrote:
By the way, are you using all-open driver or amdgpu-pro driver?
+David Mao, who is working on our Vulkan driver.
Regards,
David Zhou
On 2016年12月18日 06:05, Pierre-Loup A. Griffais wrote:
Hi Serguei,
I'm also working on the bringing up our VR runtime
Hi Serguei,
I'm also working on the bringing up our VR runtime on top of amgpu; see
replies inline.
On 12/16/2016 09:05 PM, Sagalovitch, Serguei wrote:
Andres,
For current VR workloads we have 3 separate processes running actually:
So we could have potential memory overcommit case or do y
13 matches
Mail list logo
