[Bug 111122] 2500U: Graphics corruption on kernel 5.2
https://bugs.freedesktop.org/show_bug.cgi?id=22 --- Comment #3 from Brian Schott --- I think that I'm seeing something related with my 2700u Inspiron 7375. If I have compositing enabled in XFWM4, the system will immediately stop responding after logging in with LightDM. If the window manager compositing is disabled, I'm able to log in, but then there is graphical corruption. With git bisect I traced the problem back to https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=df8368be1382=df8368be1382b442384507a5147c89978cd60702 I can edit the source file, and by only changing the KMS_DRIVER_MINOR definition from 32 to 30, get the system working correctly with 5.2.0. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111124] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! happens every time when a сutscene showed in Max Payne 3
https://bugs.freedesktop.org/show_bug.cgi?id=24 --- Comment #9 from mikhail.v.gavri...@gmail.com --- GPU: AMD Radeon VII -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111124] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! happens every time when a сutscene showed in Max Payne 3
https://bugs.freedesktop.org/show_bug.cgi?id=24 mikhail.v.gavri...@gmail.com changed: What|Removed |Added Attachment #144777|event_dump |trace-cmd start -e description||dma_fence -e gpu_scheduler ||-e amdgpu -v -e ||"amdgpu:amdgpu_mm_rreg" -e ||"amdgpu:amdgpu_mm_wreg" -e ||"amdgpu:amdgpu_iv" -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111124] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! happens every time when a сutscene showed in Max Payne 3
https://bugs.freedesktop.org/show_bug.cgi?id=24 mikhail.v.gavri...@gmail.com changed: What|Removed |Added Attachment #144779|gfx |./umr -R gfx[.] description|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111124] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! happens every time when a сutscene showed in Max Payne 3
https://bugs.freedesktop.org/show_bug.cgi?id=24 mikhail.v.gavri...@gmail.com changed: What|Removed |Added Attachment #144778|halt_waves |./umr -O halt_waves -wa description|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111124] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! happens every time when a сutscene showed in Max Payne 3
https://bugs.freedesktop.org/show_bug.cgi?id=24 --- Comment #7 from mikhail.v.gavri...@gmail.com --- Created attachment 144782 --> https://bugs.freedesktop.org/attachment.cgi?id=144782=edit ./umr -O many,bits -r *.*.mmCP_PFP_HEADER_DUMP -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111124] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! happens every time when a сutscene showed in Max Payne 3
https://bugs.freedesktop.org/show_bug.cgi?id=24 --- Comment #8 from mikhail.v.gavri...@gmail.com --- Created attachment 144783 --> https://bugs.freedesktop.org/attachment.cgi?id=144783=edit ./umr -O many,bits -r *.*.mmCP_ME_HEADER_DUMP -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111124] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! happens every time when a сutscene showed in Max Payne 3
https://bugs.freedesktop.org/show_bug.cgi?id=24 --- Comment #5 from mikhail.v.gavri...@gmail.com --- Created attachment 144780 --> https://bugs.freedesktop.org/attachment.cgi?id=144780=edit ./umr -O many,bits -r *.*.mmGRBM_STATUS* -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111124] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! happens every time when a сutscene showed in Max Payne 3
https://bugs.freedesktop.org/show_bug.cgi?id=24 --- Comment #6 from mikhail.v.gavri...@gmail.com --- Created attachment 144781 --> https://bugs.freedesktop.org/attachment.cgi?id=144781=edit ./umr -O many,bits -r *.*.mmCP_EOP_* -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111124] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! happens every time when a сutscene showed in Max Payne 3
https://bugs.freedesktop.org/show_bug.cgi?id=24 --- Comment #4 from mikhail.v.gavri...@gmail.com --- Created attachment 144779 --> https://bugs.freedesktop.org/attachment.cgi?id=144779=edit gfx -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111124] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! happens every time when a сutscene showed in Max Payne 3
https://bugs.freedesktop.org/show_bug.cgi?id=24 --- Comment #2 from mikhail.v.gavri...@gmail.com --- Created attachment 144777 --> https://bugs.freedesktop.org/attachment.cgi?id=144777=edit event_dump -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111124] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! happens every time when a сutscene showed in Max Payne 3
https://bugs.freedesktop.org/show_bug.cgi?id=24 --- Comment #3 from mikhail.v.gavri...@gmail.com --- Created attachment 144778 --> https://bugs.freedesktop.org/attachment.cgi?id=144778=edit halt_waves -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111124] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! happens every time when a сutscene showed in Max Payne 3
https://bugs.freedesktop.org/show_bug.cgi?id=24 --- Comment #1 from mikhail.v.gavri...@gmail.com --- Created attachment 144776 --> https://bugs.freedesktop.org/attachment.cgi?id=144776=edit dmesg -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111124] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! happens every time when a сutscene showed in Max Payne 3
https://bugs.freedesktop.org/show_bug.cgi?id=24 Bug ID: 24 Summary: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! happens every time when a сutscene showed in Max Payne 3 Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: mikhail.v.gavri...@gmail.com Created attachment 144775 --> https://bugs.freedesktop.org/attachment.cgi?id=144775=edit save game should be placed in ".steam/steam/steamapps/compatdata/204100/pfx/drive_c/users/steamuser/My Documents/Rockstar Games" directory Here is a demonstration: https://youtu.be/5-peqm82_qI Kernel: 5.3.0 commit 5450e8a316a6 Mesa: 19.2.0 commit f1e0a45d libdrm: 2.4.99 commit 331e51e3 llvm: 8.0.0 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] drm/modes: Don't apply cmdline's rotation if it wasn't specified
12.07.2019 22:54, Maxime Ripard пишет:
> On Thu, Jul 11, 2019 at 05:13:13AM +0300, Dmitry Osipenko wrote:
>> The rotation mode from cmdline shouldn't be taken into account if it
>> wasn't specified in the cmdline. This fixes ignored default display
>> orientation when display mode is given using cmdline without the
>> rotation being specified.
>>
>> Fixes: 1bf4e09227c3 ("drm/modes: Allow to specify rotation and reflection on
>> the commandline")
>> Signed-off-by: Dmitry Osipenko
>
> Acked-by: Maxime Ripard
>
> Thanks!
> Maxime
Thank you. Please note that I'm not a DRM maintainer, hence either you
should pick up and apply the patch by yourself or somebody else who has
the commit rights will have do that. I guess Thierry could also pick up
the patch into the Tegra's tree, but this patch is more DRM-generic.
[Bug 107296] WARNING: CPU: 0 PID: 370 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1355 dcn_bw_update_from_pplib+0x16b/0x280 [amdgpu]
https://bugs.freedesktop.org/show_bug.cgi?id=107296
Paul Menzel changed:
What|Removed |Added
CC||paulepanter@users.sourcefor
||ge.net
--- Comment #16 from Paul Menzel ---
Could some AMD developer please comment, on how to fix this? Tables(?)
containing “0 kHz” are apparently shipped by vendors, so what to do?
```
static bool verify_clock_values(struct dm_pp_clock_levels_with_voltage *clks)
{
int i;
if (clks->num_levels == 0)
return false;
for (i = 0; i < clks->num_levels; i++)
/* Ensure that the result is sane */
if (clks->data[i].clocks_in_khz == 0)
return false;
return true;
}
```
Should commit 00893681a0ff4 (drm/amd/display: Reject PPLib clock values if they
are invalid) [1] be reverted? Andrew, Tony, Harry?
> drm/amd/display: Reject PPLib clock values if they are invalid
>
> We should be sticking with the default clock values if the values
> obtained from PPLib are bogus.
>
> Signed-off-by: Andrew Jiang
> Reviewed-by: Tony Cheng
> Acked-by: Harry Wentland
> Signed-off-by: Alex Deucher
PS: AMDGPU’s commit messages are too terse, and should be more elaborate.
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=00893681a0ff41cacecabc3dafe0987593a3d5c5
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #51 from shadow.archem...@gmail.com --- (In reply to Wilko Bartels from comment #49) > (In reply to Sam from comment #47) > > The relevant issue and bug report here (the system freezing completely or if > > lucky just killing the X session, NOT games crashing) seems to be related > > exclusively to AMDGPU, and not to mesa. Whereas I got the same issues over > > and over after trying out several versions of mesa, switching to older > > versions of the kernel "fixes" it for me (the latest version I tried out > > which didn't have these issues is Kernel 4.20.13, in my case from > > https://download.opensuse.org/repositories/home:/tiwai:/kernel:/4.20/ > > standard/x86_64/) > > > > There is also a report from another user which temporarily fixed it by > > forcing the gpu to run at the maximum power setting > > (https://bugzilla.opensuse.org/show_bug.cgi?id=1136293): > > > > # echo manual > > > /sys/class/drm/card0/device/power_dpm_force_performance_level > > # echo 7 > /sys/class/drm/card0/device/pp_dpm_sclk > > > > and then to reset back to normal: > > > > # echo auto > /sys/class/drm/card0/device/power_dpm_force_performance_level > > I am currently on my 4th game of dota in a row when setting performance > level manual to 7. working so far. Everyone should test this now so we have > more reliable data. As we all now the issue can be gone for several hours so > my experience means nothing yet. > Would be amazing if we can pin down the issue to the performance level of > the cards. Played Monster Hunter and Dota 2 for quite a long time, and I didn't experience any system freezes with the max performance settings. Will test again tomorrow to see if the workaround is consistent enough. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] drm/modes: Skip invalid cmdline mode
12.07.2019 22:53, Maxime Ripard пишет: > On Fri, Jul 12, 2019 at 11:30:01AM +0300, Dmitry Osipenko wrote: >> 12.07.2019 11:10, Maxime Ripard пишет: >>> On Thu, Jul 11, 2019 at 06:55:03PM +0300, Dmitry Osipenko wrote: 11.07.2019 12:03, Maxime Ripard пишет: > On Wed, Jul 10, 2019 at 06:05:18PM +0300, Dmitry Osipenko wrote: >> 10.07.2019 17:05, Maxime Ripard пишет: >>> On Wed, Jul 10, 2019 at 04:29:19PM +0300, Dmitry Osipenko wrote: This works: diff --git a/drivers/gpu/drm/drm_client_modeset.c b/drivers/gpu/drm/drm_client_modeset.c index 56d36779d213..e5a2f9c8f404 100644 --- a/drivers/gpu/drm/drm_client_modeset.c +++ b/drivers/gpu/drm/drm_client_modeset.c @@ -182,6 +182,8 @@ drm_connector_pick_cmdline_mode(struct drm_connector *connector) mode = drm_mode_create_from_cmdline_mode(connector->dev, cmdline_mode); if (mode) list_add(>head, >modes); + else + cmdline_mode->specified = false; >>> >>> Hmmm, it's not clear to me why that wouldn't be the case. >>> >>> If we come back to the beginning of that function, we retrieve the >>> cmdline_mode buffer from the connector pointer, that will probably >>> have been parsed a first time using drm_mode_create_from_cmdline_mode >>> in drm_helper_probe_add_cmdline_mode. >>> >>> Now, I'm guessing that the issue is that in >>> drm_mode_parse_command_line_for_connector, if we have a named mode, we >>> just copy the mode over and set mode->specified. >>> >>> And we then move over to do other checks, and that's probably what >>> fails and returns, but our drm_cmdline_mode will have been modified. >>> >>> I'm not entirely sure how to deal with that though. >>> >>> I guess we could allocate a drm_cmdline_mode structure on the stack, >>> fill that, and if successful copy over its content to the one in >>> drm_connector. That would allow us to only change the content on >>> success, which is what I would expect from such a function? >>> >>> How does that sound? >> >> I now see that there is DRM_MODE_TYPE_USERDEF flag that is assigned only >> for the "cmdline" mode and drm_client_rotation() is the only place in >> DRM code that cares about whether mode is from cmdline, hence looks like >> it will be more correct to do the following: > > I'm still under the impression that we're dealing with workarounds of > a more central issue, which is that we shouldn't return a partially > modified drm_cmdline_mode. > > You said it yourself, the breakage is in the commit changing the > command line parsing logic, while you're fixing here some code that > was introduced later on. The problem stems from assumption that *any* named mode is valid. It looks to me that the ultimate solution would be to move the mode's name comparison into the [1], if that's possible. [1] drm_mode_parse_command_line_for_connector() >>> >>> Well, one could argue that video=tegrafb is invalid and should be >>> rejected as well, but we haven't cleared that up. >> >> The video=tegrafb is invalid mode, there is nothing to argue here. And >> the problem is that invalid modes and not rejected for the very beginning. > > Yeah, I guess fb_get_options should also return an error in such a > case, but I'm a bit worried about the side effects here. At least the showstopper regression is fixed now. Everything else could be worked out later on. > Can you try the followintg patch? > http://code.bulix.org/8cwk4c-794565?raw This doesn't help because the problem with the rotation_reflection is that it's 0 if "rotation" not present in the cmdline and then ilog2(0) returns -1. So the patch "drm/modes: Don't apply cmdline's rotation if it wasn't specified" should be correct in any case. >>> >>> So we would have the same issue with rotate=0 then? >> >> No, we won't. Rotation mode is parsed into the DRM_MODE bitmask and >> rotate=0 corresponds to DRM_MODE_ROTATE_0, which is BIT(0) as you may >> notice. Hence rotation_reflection=0 is always an invalid value, meaning >> that "rotate" option does not present in the cmdline. Please consult the >> code, in particular see drm_mode_parse_cmdline_options() which was >> written by yourself ;) > > Sigh... You're right :) > > Sorry for that, I'll reply to the other patch Thank you very much.
Re: [PATCH v1] drm/modes: Skip invalid cmdline mode
12.07.2019 11:10, Maxime Ripard пишет: > On Thu, Jul 11, 2019 at 06:55:03PM +0300, Dmitry Osipenko wrote: >> 11.07.2019 12:03, Maxime Ripard пишет: >>> On Wed, Jul 10, 2019 at 06:05:18PM +0300, Dmitry Osipenko wrote: 10.07.2019 17:05, Maxime Ripard пишет: > On Wed, Jul 10, 2019 at 04:29:19PM +0300, Dmitry Osipenko wrote: >> This works: >> >> diff --git a/drivers/gpu/drm/drm_client_modeset.c >> b/drivers/gpu/drm/drm_client_modeset.c >> index 56d36779d213..e5a2f9c8f404 100644 >> --- a/drivers/gpu/drm/drm_client_modeset.c >> +++ b/drivers/gpu/drm/drm_client_modeset.c >> @@ -182,6 +182,8 @@ drm_connector_pick_cmdline_mode(struct drm_connector >> *connector) >> mode = drm_mode_create_from_cmdline_mode(connector->dev, >> cmdline_mode); >> if (mode) >> list_add(>head, >modes); >> + else >> + cmdline_mode->specified = false; > > Hmmm, it's not clear to me why that wouldn't be the case. > > If we come back to the beginning of that function, we retrieve the > cmdline_mode buffer from the connector pointer, that will probably > have been parsed a first time using drm_mode_create_from_cmdline_mode > in drm_helper_probe_add_cmdline_mode. > > Now, I'm guessing that the issue is that in > drm_mode_parse_command_line_for_connector, if we have a named mode, we > just copy the mode over and set mode->specified. > > And we then move over to do other checks, and that's probably what > fails and returns, but our drm_cmdline_mode will have been modified. > > I'm not entirely sure how to deal with that though. > > I guess we could allocate a drm_cmdline_mode structure on the stack, > fill that, and if successful copy over its content to the one in > drm_connector. That would allow us to only change the content on > success, which is what I would expect from such a function? > > How does that sound? I now see that there is DRM_MODE_TYPE_USERDEF flag that is assigned only for the "cmdline" mode and drm_client_rotation() is the only place in DRM code that cares about whether mode is from cmdline, hence looks like it will be more correct to do the following: >>> >>> I'm still under the impression that we're dealing with workarounds of >>> a more central issue, which is that we shouldn't return a partially >>> modified drm_cmdline_mode. >>> >>> You said it yourself, the breakage is in the commit changing the >>> command line parsing logic, while you're fixing here some code that >>> was introduced later on. >> >> The problem stems from assumption that *any* named mode is valid. It >> looks to me that the ultimate solution would be to move the mode's name >> comparison into the [1], if that's possible. >> >> [1] drm_mode_parse_command_line_for_connector() > > Well, one could argue that video=tegrafb is invalid and should be > rejected as well, but we haven't cleared that up. The video=tegrafb is invalid mode, there is nothing to argue here. And the problem is that invalid modes and not rejected for the very beginning. >>> Can you try the followintg patch? >>> http://code.bulix.org/8cwk4c-794565?raw >> >> This doesn't help because the problem with the rotation_reflection is >> that it's 0 if "rotation" not present in the cmdline and then ilog2(0) >> returns -1. So the patch "drm/modes: Don't apply cmdline's rotation if >> it wasn't specified" should be correct in any case. > > So we would have the same issue with rotate=0 then? No, we won't. Rotation mode is parsed into the DRM_MODE bitmask and rotate=0 corresponds to DRM_MODE_ROTATE_0, which is BIT(0) as you may notice. Hence rotation_reflection=0 is always an invalid value, meaning that "rotate" option does not present in the cmdline. Please consult the code, in particular see drm_mode_parse_cmdline_options() which was written by yourself ;) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Support clang option for stack alignment
On Fri, Jul 12, 2019 at 2:37 AM Arnd Bergmann wrote:
>
> As previously fixed for dml in commit 4769278e5c7f ("amdgpu/dc/dml:
> Support clang option for stack alignment") and calcs in commit
> cc32ad8f559c ("amdgpu/dc/calcs: Support clang option for stack
> alignment"), dcn20 uses an option that is not available with clang:
>
> clang: error: unknown argument: '-mpreferred-stack-boundary=4'
> scripts/Makefile.build:281: recipe for target
> 'drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.o' failed
>
> Use the same trick that we have in the other two files.
Maybe time for a macro in Kbuild.include or some such, if we see this
pattern being repeated?
>
> Fixes: 7ed4e6352c16 ("drm/amd/display: Add DCN2 HW Sequencer and Resource")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/gpu/drm/amd/display/dc/dcn20/Makefile | 8 +++-
> drivers/gpu/drm/amd/display/dc/dsc/Makefile | 16
> 2 files changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/Makefile
> b/drivers/gpu/drm/amd/display/dc/dcn20/Makefile
> index 1b68de27ba74..e9721a906592 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn20/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dcn20/Makefile
> @@ -10,7 +10,13 @@ ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
> DCN20 += dcn20_dsc.o
> endif
>
> -CFLAGS_dcn20_resource.o := -mhard-float -msse -mpreferred-stack-boundary=4
> +ifneq ($(call cc-option, -mpreferred-stack-boundary=4),)
> + cc_stack_align := -mpreferred-stack-boundary=4
> +else ifneq ($(call cc-option, -mstack-alignment=16),)
> + cc_stack_align := -mstack-alignment=16
> +endif
> +
> +CFLAGS_dcn20_resource.o := -mhard-float -msse $(cc_stack_align)
>
> AMD_DAL_DCN20 = $(addprefix $(AMDDALPATH)/dc/dcn20/,$(DCN20))
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dsc/Makefile
> b/drivers/gpu/drm/amd/display/dc/dsc/Makefile
> index c5d5b94e2604..e019cd9447e8 100644
> --- a/drivers/gpu/drm/amd/display/dc/dsc/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dsc/Makefile
> @@ -1,10 +1,18 @@
> #
> # Makefile for the 'dsc' sub-component of DAL.
>
> -CFLAGS_rc_calc.o := -mhard-float -msse -mpreferred-stack-boundary=4
> -CFLAGS_rc_calc_dpi.o := -mhard-float -msse -mpreferred-stack-boundary=4
> -CFLAGS_codec_main_amd.o := -mhard-float -msse -mpreferred-stack-boundary=4
> -CFLAGS_dc_dsc.o := -mhard-float -msse -mpreferred-stack-boundary=4
> +ifneq ($(call cc-option, -mpreferred-stack-boundary=4),)
> + cc_stack_align := -mpreferred-stack-boundary=4
> +else ifneq ($(call cc-option, -mstack-alignment=16),)
> + cc_stack_align := -mstack-alignment=16
> +endif
> +
> +dsc_ccflags := -mhard-float -msse $(cc_stack_align)
> +
> +CFLAGS_rc_calc.o := $(dsc_ccflags)
> +CFLAGS_rc_calc_dpi.o := $(dsc_ccflags)
> +CFLAGS_codec_main_amd.o := $(dsc_ccflags)
> +CFLAGS_dc_dsc.o := $(dsc_ccflags)
--
Thanks,
~Nick Desaulniers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] staging: android: ion: Remove unused rbtree for ion_buffer
ion_buffer_add() insert ion_buffer into rbtree every time creating
an ion_buffer but never use it after ION reworking.
Also, buffer_lock protects only rbtree operation, remove it together.
Signed-off-by: Lecopzer Chen
Cc: YJ Chiang
Cc: Lecopzer Chen
---
drivers/staging/android/ion/ion.c | 36 ---
drivers/staging/android/ion/ion.h | 10 +
2 files changed, 1 insertion(+), 45 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 92c2914239e3..e6b1ca141b93 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -29,32 +29,6 @@
static struct ion_device *internal_dev;
static int heap_id;
-/* this function should only be called while dev->lock is held */
-static void ion_buffer_add(struct ion_device *dev,
- struct ion_buffer *buffer)
-{
- struct rb_node **p = >buffers.rb_node;
- struct rb_node *parent = NULL;
- struct ion_buffer *entry;
-
- while (*p) {
- parent = *p;
- entry = rb_entry(parent, struct ion_buffer, node);
-
- if (buffer < entry) {
- p = &(*p)->rb_left;
- } else if (buffer > entry) {
- p = &(*p)->rb_right;
- } else {
- pr_err("%s: buffer already found.", __func__);
- BUG();
- }
- }
-
- rb_link_node(>node, parent, p);
- rb_insert_color(>node, >buffers);
-}
-
/* this function should only be called while dev->lock is held */
static struct ion_buffer *ion_buffer_create(struct ion_heap *heap,
struct ion_device *dev,
@@ -100,9 +74,6 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap
*heap,
INIT_LIST_HEAD(>attachments);
mutex_init(>lock);
- mutex_lock(>buffer_lock);
- ion_buffer_add(dev, buffer);
- mutex_unlock(>buffer_lock);
return buffer;
err1:
@@ -131,11 +102,6 @@ void ion_buffer_destroy(struct ion_buffer *buffer)
static void _ion_buffer_destroy(struct ion_buffer *buffer)
{
struct ion_heap *heap = buffer->heap;
- struct ion_device *dev = buffer->dev;
-
- mutex_lock(>buffer_lock);
- rb_erase(>node, >buffers);
- mutex_unlock(>buffer_lock);
if (heap->flags & ION_HEAP_FLAG_DEFER_FREE)
ion_heap_freelist_add(heap, buffer);
@@ -694,8 +660,6 @@ static int ion_device_create(void)
}
idev->debug_root = debugfs_create_dir("ion", NULL);
- idev->buffers = RB_ROOT;
- mutex_init(>buffer_lock);
init_rwsem(>lock);
plist_head_init(>heaps);
internal_dev = idev;
diff --git a/drivers/staging/android/ion/ion.h
b/drivers/staging/android/ion/ion.h
index e291299fd35f..74914a266e25 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -23,7 +23,6 @@
/**
* struct ion_buffer - metadata for a particular buffer
- * @node: node in the ion_device buffers tree
* @list: element in list of deferred freeable buffers
* @dev: back pointer to the ion_device
* @heap: back pointer to the heap the buffer came from
@@ -39,10 +38,7 @@
* @attachments: list of devices attached to this buffer
*/
struct ion_buffer {
- union {
- struct rb_node node;
- struct list_head list;
- };
+ struct list_head list;
struct ion_device *dev;
struct ion_heap *heap;
unsigned long flags;
@@ -61,14 +57,10 @@ void ion_buffer_destroy(struct ion_buffer *buffer);
/**
* struct ion_device - the metadata of the ion device node
* @dev: the actual misc device
- * @buffers: an rb tree of all the existing buffers
- * @buffer_lock: lock protecting the tree of buffers
* @lock: rwsem protecting the tree of heaps and clients
*/
struct ion_device {
struct miscdevice dev;
- struct rb_root buffers;
- struct mutex buffer_lock;
struct rw_semaphore lock;
struct plist_head heaps;
struct dentry *debug_root;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: return 'NULL' instead of 'false' from dcn20_acquire_idle_pipe_for_layer
On Fri, Jul 12, 2019 at 11:39:52AM +0200, Arnd Bergmann wrote:
> clang complains that 'false' is a not a pointer:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:2428:10:
> error: expression which evaluates to zero treated as a null pointer constant
> of type 'struct pipe_ctx *' [-Werror,-Wnon-literal-null-conversion]
> return false;
>
> Changing it to 'NULL' looks like the right thing that will shut up
> the warning and make it easier to read, while not changing behavior.
>
> Fixes: 7ed4e6352c16 ("drm/amd/display: Add DCN2 HW Sequencer and Resource")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Nathan Chancellor
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204145] amdgpu video playback causes host to hard reset (checkstop) on POWER9 with RX 580
https://bugzilla.kernel.org/show_bug.cgi?id=204145 Daniel Kolesa (li...@octaforge.org) changed: What|Removed |Added CC||li...@octaforge.org --- Comment #4 from Daniel Kolesa (li...@octaforge.org) --- Can't reproduce this on 5.1.17 with Polaris WX5100 and 18-core POWER9. Since both you and Timothy have dual-CPU systems with the GPU on the second CPU's PCIe, this could indicate that the problem is only affecting dual processor systems possibly in that specific configuration (alternatively, the problem could be fixed in 5.1.17 already...) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/sun4i: sun8i-csc: Add support for color encoding and range
Conversion from YUV to RGB depends on range (limited or full) and
encoding (BT.601 or BT.709). Current code doesn't consider this and
always uses BT.601 encoding and limited range.
Fix this by introducing new CSC matrices, which are selected based on
range and encoding parameters.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_csc.c | 144 -
drivers/gpu/drm/sun4i/sun8i_csc.h | 6 +-
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 4 +-
3 files changed, 126 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_csc.c
b/drivers/gpu/drm/sun4i/sun8i_csc.c
index e07b7876d89b..70c792d052fe 100644
--- a/drivers/gpu/drm/sun4i/sun8i_csc.c
+++ b/drivers/gpu/drm/sun4i/sun8i_csc.c
@@ -18,16 +18,59 @@ static const u32 ccsc_base[2][2] = {
* First tree values in each line are multiplication factor and last
* value is constant, which is added at the end.
*/
-static const u32 yuv2rgb[] = {
- 0x04A8, 0x, 0x0662, 0xFFFC845A,
- 0x04A8, 0xFE6F, 0xFCBF, 0x00021DF4,
- 0x04A8, 0x0813, 0x, 0xFFFBAC4A,
+
+static const u32 yuv2rgb[2][2][12] = {
+ [DRM_COLOR_YCBCR_LIMITED_RANGE] = {
+ [DRM_COLOR_YCBCR_BT601] = {
+ 0x04A8, 0x, 0x0662, 0xFFFC8451,
+ 0x04A8, 0xFE6F, 0xFCC0, 0x00021E4D,
+ 0x04A8, 0x0811, 0x, 0xFFFBACA9,
+ },
+ [DRM_COLOR_YCBCR_BT709] = {
+ 0x04A8, 0x, 0x072B, 0xFFFC1F99,
+ 0x04A8, 0xFF26, 0xFDDF, 0x00013383,
+ 0x04A8, 0x0873, 0x, 0xFFFB7BEF,
+ }
+ },
+ [DRM_COLOR_YCBCR_FULL_RANGE] = {
+ [DRM_COLOR_YCBCR_BT601] = {
+ 0x0400, 0x, 0x059B, 0xFFFD322E,
+ 0x0400, 0xFEA0, 0xFD25, 0x00021DD5,
+ 0x0400, 0x0716, 0x, 0xFFFC74BD,
+ },
+ [DRM_COLOR_YCBCR_BT709] = {
+ 0x0400, 0x, 0x064C, 0xFFFCD9B4,
+ 0x0400, 0xFF41, 0xFE21, 0x00014F96,
+ 0x0400, 0x076C, 0x, 0xFFFC49EF,
+ }
+ },
};
-static const u32 yvu2rgb[] = {
- 0x04A8, 0x0662, 0x, 0xFFFC845A,
- 0x04A8, 0xFCBF, 0xFE6F, 0x00021DF4,
- 0x04A8, 0x, 0x0813, 0xFFFBAC4A,
+static const u32 yvu2rgb[2][2][12] = {
+ [DRM_COLOR_YCBCR_LIMITED_RANGE] = {
+ [DRM_COLOR_YCBCR_BT601] = {
+ 0x04A8, 0x0662, 0x, 0xFFFC8451,
+ 0x04A8, 0xFCC0, 0xFE6F, 0x00021E4D,
+ 0x04A8, 0x, 0x0811, 0xFFFBACA9,
+ },
+ [DRM_COLOR_YCBCR_BT709] = {
+ 0x04A8, 0x072B, 0x, 0xFFFC1F99,
+ 0x04A8, 0xFDDF, 0xFF26, 0x00013383,
+ 0x04A8, 0x, 0x0873, 0xFFFB7BEF,
+ }
+ },
+ [DRM_COLOR_YCBCR_FULL_RANGE] = {
+ [DRM_COLOR_YCBCR_BT601] = {
+ 0x0400, 0x059B, 0x, 0xFFFD322E,
+ 0x0400, 0xFD25, 0xFEA0, 0x00021DD5,
+ 0x0400, 0x, 0x0716, 0xFFFC74BD,
+ },
+ [DRM_COLOR_YCBCR_BT709] = {
+ 0x0400, 0x064C, 0x, 0xFFFCD9B4,
+ 0x0400, 0xFE21, 0xFF41, 0x00014F96,
+ 0x0400, 0x, 0x076C, 0xFFFC49EF,
+ }
+ },
};
/*
@@ -53,30 +96,74 @@ static const u32 yvu2rgb[] = {
* c20 c21 c22 [d2 const2]
*/
-static const u32 yuv2rgb_de3[] = {
- 0x0002542a, 0x, 0x0003312a, 0xffc0,
- 0x0002542a, 0x376b, 0xfffe5fc3, 0xfe00,
- 0x0002542a, 0x000408d3, 0x, 0xfe00,
+static const u32 yuv2rgb_de3[2][2][12] = {
+ [DRM_COLOR_YCBCR_LIMITED_RANGE] = {
+ [DRM_COLOR_YCBCR_BT601] = {
+ 0x0002542A, 0x, 0x0003312A, 0xFFC0,
+ 0x0002542A, 0x376B, 0xFFFE5FC3, 0xFE00,
+ 0x0002542A, 0x000408D2, 0x, 0xFE00,
+ },
+ [DRM_COLOR_YCBCR_BT709] = {
+ 0x0002542A, 0x, 0x000395E2, 0xFFC0,
+ 0x0002542A, 0x92D2, 0xFFFEEF27, 0xFE00,
+ 0x0002542A, 0x0004398C, 0x, 0xFE00,
+ }
+ },
+ [DRM_COLOR_YCBCR_FULL_RANGE] = {
+ [DRM_COLOR_YCBCR_BT601] = {
+ 0x0002, 0x, 0x0002CDD2, 0x,
+
[PATCH 2/3] drm/sun4i: sun8i_csc: Simplify register writes
It turns out addition of 0x200 to constant parts (+0.5) is not really
necessary. Besides, we can consider that before and fix value in CSC
matrix.
This simplifies register writes quiet a bit.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_csc.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_csc.c
b/drivers/gpu/drm/sun4i/sun8i_csc.c
index b8c059f1a118..e07b7876d89b 100644
--- a/drivers/gpu/drm/sun4i/sun8i_csc.c
+++ b/drivers/gpu/drm/sun4i/sun8i_csc.c
@@ -69,7 +69,7 @@ static void sun8i_csc_set_coefficients(struct regmap *map,
u32 base,
enum sun8i_csc_mode mode)
{
const u32 *table;
- int i, data;
+ u32 base_reg;
switch (mode) {
case SUN8I_CSC_MODE_YUV2RGB:
@@ -83,13 +83,8 @@ static void sun8i_csc_set_coefficients(struct regmap *map,
u32 base,
return;
}
- for (i = 0; i < 12; i++) {
- data = table[i];
- /* For some reason, 0x200 must be added to constant parts */
- if (((i + 1) & 3) == 0)
- data += 0x200;
- regmap_write(map, SUN8I_CSC_COEFF(base, i), data);
- }
+ base_reg = SUN8I_CSC_COEFF(base, 0);
+ regmap_bulk_write(map, base_reg, table, 12);
}
static void sun8i_de3_ccsc_set_coefficients(struct regmap *map, int layer,
--
2.22.0
[PATCH 0/3] drm/sun4i: Add support for color encoding and range
In order to correctly convert image between YUV and RGB, you have to know color encoding and color range. This patch set adds appropriate properties and considers them when choosing CSC conversion matrix for DE2 and DE3. Note that this is only the half of needed changes when using HDMI output. DW HDMI bridge driver has to be extended to have a property to select limited (TVs) or full (PC monitors) range. But that will be done at a later time. Please take a look. Best regards, Jernej Jernej Skrabec (3): drm/sun4i: Introduce color encoding and range properties drm/sun4i: sun8i_csc: Simplify register writes drm/sun4i: sun8i-csc: Add support for color encoding and range drivers/gpu/drm/sun4i/sun8i_csc.c | 155 +++-- drivers/gpu/drm/sun4i/sun8i_csc.h | 6 +- drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 21 +++- 3 files changed, 146 insertions(+), 36 deletions(-) -- 2.22.0
[PATCH 1/3] drm/sun4i: Introduce color encoding and range properties
In order to correctly convert YUV color space to RGB, we have to know
color encoding and range.
Introduce these two properties using helper method.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
index bd0e6a52d1d8..240a800217df 100644
--- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
@@ -441,6 +441,7 @@ struct sun8i_vi_layer *sun8i_vi_layer_init_one(struct
drm_device *drm,
struct sun8i_mixer *mixer,
int index)
{
+ u32 supported_encodings, supported_ranges;
struct sun8i_vi_layer *layer;
unsigned int plane_cnt;
int ret;
@@ -469,6 +470,22 @@ struct sun8i_vi_layer *sun8i_vi_layer_init_one(struct
drm_device *drm,
return ERR_PTR(ret);
}
+ supported_encodings = BIT(DRM_COLOR_YCBCR_BT601) |
+ BIT(DRM_COLOR_YCBCR_BT709);
+
+ supported_ranges = BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) |
+ BIT(DRM_COLOR_YCBCR_FULL_RANGE);
+
+ ret = drm_plane_create_color_properties(>plane,
+ supported_encodings,
+ supported_ranges,
+ DRM_COLOR_YCBCR_BT709,
+ DRM_COLOR_YCBCR_LIMITED_RANGE);
+ if (ret) {
+ dev_err(drm->dev, "Couldn't add encoding and range
properties!\n");
+ return ERR_PTR(ret);
+ }
+
drm_plane_helper_add(>plane, _vi_layer_helper_funcs);
layer->mixer = mixer;
layer->channel = index;
--
2.22.0
[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U
https://bugs.freedesktop.org/show_bug.cgi?id=109206 --- Comment #59 from Jay Fitzpatrick --- (In reply to Jay Fitzpatrick from comment #56) > (In reply to Ondrej Lang from comment #53) > > According to the linux kernel 5.2 changelog > > (https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.2), the fix for > > the DMCU firmware issue on raven1 platform is included in that release. > > > > I went ahead and tested this and can confirm that I was able to boot without > > a blank screen into my machine with kernel 5.2 without needing to use the > > workaround. > > > > I tested with: > > 1.) re-installed latest linux-firmware package > > 2.) installed kernel 5.2 > > 3.) re-generated the initramfs > > 4.) booted into linux using kernel 5.2 and had no blank screen, dmesg output > > is clean with no erros for amdgpu > > > > Tested on: > > HP HP ENVY x360 Convertible 15-bq1xx/83C6, BIOS F.21 04/29/2019 > > > > I guess if someone else can confirm my findings, maybe on different raven1 > > hardware, this ticket can be closed. > > > Hi Ondrej > > While I have not been able to test the 5.2 kernel on my Fedora system I have > installed the 5.3 kernel from rawhide and am seeing the same results: > > [root@envy ~]# cp /home/XXX/raven_dmcu.bin /usr/lib/firmware/amdgpu/ > [root@envy ~]# dracut -f --kver 5.3.0-0.rc0.git2.2.fc31.x86_64 > [root@envy ~]# reboot > > Tested on HP ENVY x360 Convertible 15-bq1xx/83C6, BIOS F.20 12/25/2018 > Kernel version 5.3.0-0.rc0.git2.2.fc31.x86_64 > > Installing rawhide kernel on Fedora without debug enabled: > sudo dnf config-manager > --add-repo=http://alt.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/ > fedora-rawhide-kernel-nodebug.repo > sudo yum upgrade --Update-- While kernel versions 5.3.0-0.rc0.git2.2.fc31.x86_64 and 5.3.0-0.rc0.git2.4.fc31.x86_64 versions of the kernel seemed to be pretty stable when it came to booting the system / touchscreen working etc, there was a massive amount of video tearing (within Chrome / Konsole) within my KDE session, enough to force me to roll back to 5.1.16-300.fc30.x86_64 Jay -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111122] 2500U: Graphics corruption on kernel 5.2
https://bugs.freedesktop.org/show_bug.cgi?id=22 --- Comment #2 from andreas...@web.de --- Reintroducing iommu=pt does, indeed, seem to fix these graphical issues. Why is this flag suddenly required for proper operation again? Is every laptop with an Raven Ridge APU different here or why can the kernel not just figure out how to properly configure the IOMMU so that everything works? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111122] 2500U: Graphics corruption on kernel 5.2
https://bugs.freedesktop.org/show_bug.cgi?id=22 --- Comment #1 from andreas...@web.de --- Created attachment 144772 --> https://bugs.freedesktop.org/attachment.cgi?id=144772=edit Xorg log -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111122] 2500U: Graphics corruption on kernel 5.2
https://bugs.freedesktop.org/show_bug.cgi?id=22 Bug ID: 22 Summary: 2500U: Graphics corruption on kernel 5.2 Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: andreas...@web.de Created attachment 144771 --> https://bugs.freedesktop.org/attachment.cgi?id=144771=edit Kernel log Arch Linux Lenovo E485 (16 GiB RAM) AMD Ryzen 2500U xorg-server 1.20.5-2 mesa 19.1.2-1 xf86-video-amdgpu 19.0.1-1 libdrm 2.4.99-1 After upgrading to the linux kernel 5.2 from the Arch Linux repositories, my laptop started to show graphical corruption in Firefox or Konsole. It is much worse if something is moving on the screen e.g., a video is playing. Sometimes Firefox is almost unusable as a result. A downgrade to 5.1.16 immediately fixes the issues. Somebody mentioned similar corruption for bug 109206: https://bugs.freedesktop.org/show_bug.cgi?id=109206#c57 My kernel command line is: initrd=\amd-ucode.img initrd=\initramfs-linux.img root=PARTUUID=34098e4c-f1bf-4a43-a0a8-2ba3ed3c71a6 idle=nomwait psmouse.synaptics_intertouch=1 acpi_osi=Linux amdgpu.gpu_recovery=1 ivrs_ioapic[32]=00:14.0 I used to have iommu=pt or iommu=off on the command line to get this laptop to boot properly but I have not needed that switch for a while. I might try to reintroduce it with 5.2 just to see what happens. In any case, my setup worked before, so something does not seem right. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110783] Mesa 19.1 rc crashing MPV with VAAPI
https://bugs.freedesktop.org/show_bug.cgi?id=110783 --- Comment #24 from ITwrx --- 19.1.2 did the trick. thanks -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
