https://bugzilla.kernel.org/show_bug.cgi?id=201275
--- Comment #23 from quirin.blae...@freenet.de ---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c (v4.18.12)
There is a lot of work to do:
230 for (i = 0; i < dc_clks->num_levels; i++) {
231 DRM_INF
https://bugs.freedesktop.org/show_bug.cgi?id=107928
--- Comment #3 from Vik-T ---
I hope it's ok if I bump this bug report. It's been almost a month since I
reported it and I haven't received any feedback since.
Nothing really new I can report as such otherwise. The problem still exists,
the dr
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #4 from george ---
I have same problem on Fedora F28 with 4.18 kernel. I have since switched back
to DVI interface which does not exhibit this bug.
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #5 from Shmerl ---
My card doesn't have DVI, and HDMI produces horrible colors, so DisplayPort is
the only sane option and it's broken :(
--
You are receiving this mail because:
You are the assignee for the bug.
Hi Dave,
This time mostly further refinement of dpu1+a6xx for sdm845 and
beyond.. and hurray for more negative diffstat :-)
- Misc cleanups and fixes
- GPU preemption optimization
- a6xx perf improvements and clock fixes (ie. lets actually not run at
minimum clks)
- a6xx devfreq/DCVS
- Lots of
On Sun, Oct 7, 2018 at 3:23 PM Rob Clark wrote:
>
> Hi Dave,
>
> This time mostly further refinement of dpu1+a6xx for sdm845 and
> beyond.. and hurray for more negative diffstat :-)
>
> - Misc cleanups and fixes
> - GPU preemption optimization
> - a6xx perf improvements and clock fixes (ie. lets a
https://bugs.freedesktop.org/show_bug.cgi?id=107928
--- Comment #4 from dwagner ---
@ Vik-T: The way you describe your symptoms let it seem possible to me that you
are experiencing the very same long-standing bug that I reported in
https://bugs.freedesktop.org/show_bug.cgi?id=102322
If you want
https://bugs.freedesktop.org/show_bug.cgi?id=107928
--- Comment #5 from Vik-T ---
@dwagner:
Thanks for your comment. I could not reproduce the error with the 3fps 1080p
video on naked X. I let it run for 25 minutes without any issues.
Besides, unlike yourself, I never experienced any sort of f
https://bugs.freedesktop.org/show_bug.cgi?id=99923
--- Comment #37 from liam.ginger.benn...@gmail.com ---
Currently also experiencing the issue with an AMD R9 280.
Mesa and LLVM versions:
$ glxinfo | grep Mesa
client glx vendor string: Mesa Project and SGI
OpenGL core profile version string: 4.5
https://bugs.freedesktop.org/show_bug.cgi?id=108270
Bug ID: 108270
Summary: [proton] Wolfenstein: The New Order (frame rate issue)
Product: Mesa
Version: 18.2
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
On Mon, Oct 01, 2018 at 11:56:17PM +0300, Leonard Crestez wrote:
> On some chips the PCIE and PCIE_PHY blocks are in separate power domains
> which can be power-gated independently. The driver needs to handle this
> by keeping both domain active.
>
> This is intended for imx6sx where PCIE is in DI
> -Original Message-
> From: Nicolai Hähnle
> Sent: Wednesday, September 26, 2018 5:06 PM
> To: Zhou, David(ChunMing) ; dri-
> de...@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> Subject: Re: [PATCH 5/6] drm/amdgpu: add timeline support in amdgpu CS
>
> Hey Chunming,
>
>
> -Original Message-
> From: Nicolai Hähnle
> Sent: Wednesday, September 26, 2018 4:44 PM
> To: Zhou, David(ChunMing) ; dri-
> de...@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> Subject: Re: [PATCH 5/6] drm/amdgpu: add timeline support in amdgpu CS
>
> > static int amdg
Hi,
I recently filed a bug report regarding graphics corruption seen on
Gemini Lake platforms:
https://bugs.freedesktop.org/show_bug.cgi?id=108085
This has been reproduced on multiple distros on products from at least
4 vendors. It seems to apply to every GeminiLake product that we have
seen.
Th
>> Another general comment (no good place to put it) is that I think we want
>> two kinds of waits: Wait for time point to be completed and wait for time
>> point to become available. The first is the usual CPU wait for completion
>> while the second is for use by userspace drivers to wait unt
From: Ville Syrjälä
Date: Fri, 24 Aug 2018 14:58:52 +0300
> But yeah, given the V2CLK thing /5 seems like a perfectly good
> value to use here.
Patch applied.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mai
16 matches
Mail list logo
