Re: [PATCH 2/2] drm/amd: Re-create firmware framebuffer on failure to probe

What about a system with multiple GPUs? Hybrid graphics? Headless systems? Regards //Ernst Den tors 22 dec. 2022 kl 19:30 skrev Mario Limonciello < mario.limoncie...@amd.com>: > If the probe sequence fails then the user is stuck with a frozen > screen and can only really recover via SSH or by

Re: [PATCH] drm/radeon: Add build directory to include path

Den sön 19 juni 2022 kl 00:20 skrev Masahiro Yamada : > On Wed, Jun 15, 2022 at 5:35 PM Michel Dänzer > wrote: > > > > On 2022-04-14 18:57, Michel Dänzer wrote: > > > On 2022-04-14 17:04, Masahiro Yamada wrote: > > >> On Thu, Apr 14, 2022 at 10:50 PM Michel Dänzer > > >> wrote: > > >>> On

Re: [bug] Radeon 3900XT not switch to graphic mode on kernel 5.10

-2 means no such file or directory. Perhaps you need to rebuild your ramdisk manually for some reason. Regards //Ernst Den sön 27 dec. 2020 kl 17:58 skrev Mikhail Gavrilov < mikhail.v.gavri...@gmail.com>: > On Sun, 27 Dec 2020 at 21:39, Mikhail Gavrilov > wrote: > > I suppose the root of cause

Re: [PATCH] gpu/drm/radeon: fix spellint typo in comments

There is a typo in your patch subject. ;-) Regards //Ernst Den tis 22 sep. 2020 kl 15:11 skrev Wang Qing : > Modify the comment typo: "definately" -> "definitely". > > Signed-off-by: Wang Qing > --- > drivers/gpu/drm/radeon/radeon_vm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >

Re: [PATCH v2 00/11] amd/display: Add GFX9+ modifier support.

Den fre 4 sep. 2020 kl 18:07 skrev Bas Nieuwenhuizen < b...@basnieuwenhuizen.nl>: > This adds modifier support to radeonsi. > Wouldn't it be more correct to say that this adds modifier support to amdgpu (and enables it to work with radeonsi OpenGL) or something like that? //E > It has been

Re: RFC for a render API to support adaptive sync and VRR

It would be really nice to have support for the automatic extension-less fullscreen game scenario. Maybe you don't have to solve everything in the first implementation... So a friendly ping here! Regards //Ernst Den tis 24 apr. 2018 kl 23:58 skrev Daniel Vetter : > > On Tue, Apr 24, 2018 at 4:28

Re: [PATCH 1/2] drm/amdgpu: potential uninitialized variable in amdgpu_vce_ring_parse_cs()

Can't find these anywhere yet, errors still there. https://patchwork.freedesktop.org/series/31220/ Regards //Ernst 2017-09-30 10:25 GMT+02:00 Christian König : > Am 30.09.2017 um 10:13 schrieb Dan Carpenter: >> >> We shifted some code around in commit 9cca0b8e5df0

Testing dc-drm-next-atomic-wip

Hi, this is more feedback about how the code works and runs rather than what you're really looking for, so I thought I'd start a new thread. :-) I get the following error when compiling and (obviously) forgetting to enable the new DC option. I see the option will be removed, so maybe that

[PATCH] drm: disable deep color when EDID violates spec

I kindof assume DP is the default connection these days and with Freesync you use DP or course, but this question was specifically for HDMI. I guess this patch doesn't affect deep color over DP? Anyway, only 17 of those monitors have FreeSync but almost all have DP, so perhaps they only support

[PATCH] drm: disable deep color when EDID violates spec

Isn't 10bpc very common among monitors, and 12bpc very rare? Or maybe I'm confusing the transport layer with the presentation capabilities...? Here are 201 monitors that claim 10bpc: http://pricespy.co.uk/category.php?l=s300859434=eg_401#prodlista Regards //Ernst 2017-01-10 11:52 GMT+01:00 Ville

[RFC] Using DC in amdgpu for upcoming GPU

2016-12-13 3:33 GMT+01:00 Harry Wentland : Please keep asking us to get on dri-devel with questions. I need to get > into the habit again of leaving the IRC channel open. I think most of us > are still a bit scared of it or don't know how to deal with some of the > information overload (IRC and

AMD guys: commit messages?

Hello list! I lurk here and try to follow Mesa/DRI and most specifically Radeon driver development, report bugs, test new stuff and help get the bugs closed and so on... However I see that the commit messages for AMD/Radeon are often very unhelpful. They don't state the motivation behind the

Implementing Miracast?

Sorry if this is completely off-topic, but could this be useful for high performance screen recording also? This seems to be all the rage on Windows these days, with software like OBS (+AMD VCE support), Nvidia ShadowPlay (also HW accel encoding), Xsplit, Twitch etc... Regards //Ernst 2015-12-04

[PATCH 1/2] amdgpu: fix overflow for timeout calculation

Doh, I didn't get that! Sorry. Regards //Ernst 2015-11-21 12:07 GMT+01:00 Christian König : > On 21.11.2015 11:48, Ernst Sjöstrand wrote: > > I guess the patches should be for drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > instead? > > > No, why do you think so? This is a libdrm patch, not a kernel

[PATCH 1/2] amdgpu: fix overflow for timeout calculation

I guess the patches should be for drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c instead? Regards //Ernst 2015-11-21 1:24 GMT+01:00 Alex Deucher : > From: Jammy Zhou > > Set the timeout to AMDGPU_TIMEOUT_INFINITE when overflow happens > > Signed-off-by: Jammy Zhou > Reviewed-by: Christian König >

[pull] amdgpu and radeon drm-next-4.4

Don't forget https://bugs.freedesktop.org/attachment.cgi?id=118844 "drm/amdgpu: adjust default dispclk (v2)" Regards //Ernst 2015-10-14 22:44 GMT+02:00 Alex Deucher : > Hi Dave, > > This is the first radeon and amdgpu pull for drm-next. Highlights include: > - Efficiency improvements to the CS