From: Michel Dänzer
It would crash if RandR is disabled, e.g. because Xinerama is enabled.
Bugzilla: https://bugs.freedesktop.org/109230
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/drmmode_display.c b/src
From: Michel Dänzer
There's no point in listening for hotplug events if RandR is disabled,
as there's no other mechanism for them to be propagated. We were already
mostly ignoring them in that case.
Inspired by
https://gitlab.freedesktop.org/xorg/driver/xf86-video-in
s using DXVK, it could be an issue between DXVK and RADV.
I'd start by filing a bug report against RADV.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
Hi Christoph,
https://bugs.freedesktop.org/109234 (please ignore comments #6-#9) was
bisected to your commit 55897af63091 "dma-direct: merge swiotlb_dma_ops
into the dma_direct code". Any ideas?
--
Earthling Michel Dänzer | http://www.amd.com
Libr
On 2019-01-10 10:42 a.m., Mikhail Gavrilov wrote:
> On Thu, 10 Jan 2019 at 13:54, Michel Dänzer wrote:
>>
>> Assuming that's using DXVK, it could be an issue between DXVK and RADV.
>> I'd start by filing a bug report against RADV.
>
> In the case of the last
From: Michel Dänzer
It was at the same time too strict (for linear tiling modes, where no
height alignment is required) and too lenient (for 2D tiling modes,
where height may need to be aligned to values > 8).
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
t; drm/amdgpu: validate user pitch alignment
>
> Userspace may request pitch alignment that is not supported by GPU.
> Some requests 32, but GPU ignores it and uses default 64 when cpp is
> 4. If GEM object is allocated based on the smaller alignment, GPU
>
On 2019-01-10 3:22 p.m., Alex Deucher wrote:
> Signed-off-by: Alex Deucher
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X develo
bject *bo);
... and this should be named something like del_from_lru_notify, for
clarity.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
t;>
>>> [...]
>>>
>>> 79c6b898011958fba7722528d567b64e1cdc8dbe is the first bad commit
>>> commit 79c6b898011958fba7722528d567b64e1cdc8dbe
>>> Author: Yu Zhao
>>> Date: Mon Jan 7 15:51:14 2019 -0700
>>>
>>> drm/amdgpu: v
On 2019-01-11 2:15 p.m., Christian König wrote:
> Move the BO on the LRU only when it is actually moved by a DMA
> operation.
>
> Signed-off-by: Christian König
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre softwar
goto out_unlock;
> }
> +
> + if (bo->moving != moving) {
Hmm, could a driver just update the existing fence instead of attaching
a new one?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
From: Michel Dänzer
The check turned out to be too strict in some cases.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu
ould be able to help with that.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 70a816dd8
On 2019-01-11 8:12 p.m., Christian König wrote:
> Am 11.01.19 um 15:17 schrieb Michel Dänzer:
>> On 2019-01-11 2:15 p.m., Christian König wrote:
>>> Move the BO on the LRU only when it is actually moved by a DMA
>>> operation.
>>>
>>> [...]
&
printk_once in is_swiotlb_buffer,
> maybe that gives a clue why we are hitting the swiotlb code here.
Any progress? https://bugzilla.kernel.org/show_bug.cgi?id=202261 was
also filed about this.
I hope everyone's clear that this needs to be resolved one way or
another
On 2019-01-11 10:37 p.m., Yu Zhao wrote:
> On Fri, Jan 11, 2019 at 04:27:44PM +0100, Michel Dänzer wrote:
>> On 2019-01-10 6:56 p.m., Przemek Socha wrote:
>>>
>>> [ 147.846148] [drm:amdgpu_display_user_framebuffer_create [amdgpu]]
>>> Invalid
>
https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/21
Thanks in advance for taking a look!
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
oblem, see the rules for updating this.
>>
>> IIRC the code must land in an upstream kernel before it can be committed
>> to libdrm.
>>
>> Christian.
>>
>
> It looks like it's all in the master branch.
That's good, but
27;optimization' to get things working.
FWIW, the amdgpu driver doesn't rely on non-snooped transfers for
correct basic operation (the scenario Christian brought up is a very
specialized use-case), so that shouldn't be an issue.
--
Earthling Michel Dänzer
On 2019-01-21 6:59 p.m., Ard Biesheuvel wrote:
> On Mon, 21 Jan 2019 at 18:55, Michel Dänzer wrote:
>>
>> On 2019-01-21 5:30 p.m., Ard Biesheuvel wrote:
>>> On Mon, 21 Jan 2019 at 17:22, Christoph Hellwig wrote:
>>>
>>>> Until that happens we sh
On 2019-01-21 7:20 p.m., Ard Biesheuvel wrote:
> On Mon, 21 Jan 2019 at 19:04, Michel Dänzer wrote:
>>
>> On 2019-01-21 6:59 p.m., Ard Biesheuvel wrote:
>>> On Mon, 21 Jan 2019 at 18:55, Michel Dänzer wrote:
>>>>
>>>> On 2019-01-21 5:30 p.m., Ard B
On 2019-01-21 7:28 p.m., Ard Biesheuvel wrote:
> On Mon, 21 Jan 2019 at 19:24, Michel Dänzer wrote:
>> On 2019-01-21 7:20 p.m., Ard Biesheuvel wrote:
>>> On Mon, 21 Jan 2019 at 19:04, Michel Dänzer wrote:
>>>> On 2019-01-21 6:59 p.m., Ard Biesheuvel wrote:
>
; afb->address != old_afb->address);
The second check after the || cannot be true if old_plane_state->fb ==
new_plane_state->fb, so it's dead code.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | M
>> -
>> - if (bo->flags & AMDGPU_GEM_CREATE_CPU_GTT_USWC)
>> - DRM_INFO_ONCE("Please enable CONFIG_MTRR and CONFIG_X86_PAT
>> for "
>> - "better performance thanks to
>> write-combini
about non-cache coherent likely not working *at
>>> all* unless the optimization is enabled.
>>
>> As Michel tried to explain this CAN'T happen. The optimization is a
>> purely optional request from userspace.
>>
>
> Right.
>
> S
https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/24
Thanks in advance for taking a look!
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
L);
> +
> + if (!flip)
> + dm_error("Failed to allocate update bundles\n");
I can't see where this memory is freed, maybe this is the leak?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
gt; but we wouldn't should be doing anything in that case anyway.
>
> Fixes: c00e0cc0fdc0 ("drm/amd/display: Call into DC once per multiplane flip")
> Fixes: ea39594e0855 ("drm/amd/display: Perform plane updates only when
> needed")
>
> Cc: Michel
From: Michel Dänzer
If the compositing manager uses direct rendering (as is usually the case
these days), the storage of a pixmap allocated by glamor_create_pixmap
needs to be reallocated for sharing it with the compositing manager.
Instead, allocate pixmap storage which can be shared directly
From: Michel Dänzer
To make sure the client can't use the shared pixmap storage for direct
rendering first, which could produce garbage.
Bugzilla: https://bugs.freedesktop.org/109235
(Ported from amdgpu commit ebd32b1c07208f8dbe853e089f5e4b7c6a7a658a)
Signed-off-by: Michel Dänzer
---
From: Michel Dänzer
We were using a relative target of 0, meaning "complete the flip ASAP".
This could result in the flip sometimes, but not always completing in
the same vertical blank period where the corresponding drawing occurred,
potentially causing judder artifacts with ap
From: Michel Dänzer
drm_wait_pending_flip stopped waiting if drm_handle_event returned 0,
but that might have processed only some unrelated DRM events. As long as
the flip is pending, we have to keep waiting for its completion event.
Noticed while working on the previous fix.
(Ported from
From: Michel Dänzer
drmHandleEvent can be interrupted by a signal in read(), in which case
it doesn't process any events but returns -1, which
drm_handle_event propagated to its callers. This could cause the
following failure cascade:
1. drm_wait_pending_flip stopped waiting for a pending
From: Michel Dänzer
And only clear it if it matches the framebuffer of the completed flip
being processed.
Fixes
(WW) RADEON(0): flip queue failed: Device or resource busy
(WW) RADEON(0): Page flip failed: Device or resource busy
(EE) RADEON(0): present flip failed
due to clobbering
From: Michel Dänzer
To make sure the client can't use the shared pixmap storage for direct
rendering first, which could produce garbage.
Bugzilla: https://bugs.freedesktop.org/109235
(Ported from amdgpu commit d168532ee739f7e33a2798051e64ba445dd3859f)
Signed-off-by: Michel Dänzer
---
Bad news I'm afraid, looks like the latest firmware (based on
linux-firmware commit bc656509a3cfb60fcdfc905d7e23c18873e4e7b9 from
2019-01-14) broke some RX 580 cards.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthu
issues and these updates have been upstream
> in linux-firmware for over a month now.
It entered Debian sid about two weeks ago, so might have only entered
Debian testing this week.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
ched via steam play DXVK
> - vulcan-cube (backtrace is included to this message)
>
> Last working mesa version:
> 18.3.2-1
Please report RADV issues at
https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa&component=Drivers/Vulkan/radeon
.
--
Earthling Michel Dänzer
eucher
>
> Signed-off-by: Kenneth Feng
Revert "Revert "..."" is kind of an ugly shortlog. :) It's nicer to
re-use the original commit's log, possibly amended with an explanation
why the change is applied again.
--
Earthling Michel Dänzer
Hit this with an amdgpu piglit run today, see the attached dmesg
excerpt. It's ttm_bo_ref_bug() being called from ttm_bo_del_from_lru().
Maybe this is still fallout from the "cleanup setting bulk_movable" change?
--
Earthling Michel Dänzer | http://ww
before (not 100% sure though).
I reverted the remaining hunk of the "cleanup setting bulk_movable"
change, and it survived a piglit run. Could just be luck, though...
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
On 2019-02-07 10:58 a.m., Christian König wrote:
> Am 05.02.19 um 18:40 schrieb Michel Dänzer:
>> On 2019-02-05 4:45 p.m., Christian König wrote:
>>> Possible, but unlikely.
>>>
>>> That sounds more like a reference counting problem where something is
>>
hine without it is
> working fine.
Same for me with Tonga.
Chiawen / Tony / other DC developers, any ideas? If it cannot be fixed
quickly, let's revert this change for now.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
On 2019-02-07 4:37 p.m., Alex Deucher wrote:
> On Thu, Feb 7, 2019 at 10:33 AM Michel Dänzer wrote:
>>
>> On 2019-02-06 10:48 a.m., Przemek Socha wrote:
>>> Good morning,
>>>
>>> on my Lenovo G50-45 a6310 APU with R4 Mullins commit
>>> e261568
h rate.
>
> Fixes: bb47de736661 ("drm/amdgpu: Set FreeSync state using drm VRR
> properties")
> Signed-off-by: Mario Kleiner
> Cc:
> Cc: Nicholas Kazlauskas
> Cc: Harry Wentland
> Cc: Alex Deucher
> Cc: Michel Dänzer
I wonder if this couldn't be
On 2019-02-12 9:39 a.m., Mario Kleiner via dri-devel wrote:
> On Mon, Feb 11, 2019 at 4:01 PM Michel Dänzer wrote:
>>
>> On 2019-02-09 7:52 a.m., Mario Kleiner wrote:
>>> In VRR mode, keep track of the vblank count of the last
>>> completed pageflip in
On 2019-02-13 10:53 a.m., Daniel Vetter wrote:
> On Mon, Feb 11, 2019 at 04:01:12PM +0100, Michel Dänzer wrote:
>> On 2019-02-09 7:52 a.m., Mario Kleiner wrote:
>>> In VRR mode, keep track of the vblank count of the last
>>> completed pageflip in amdgpu_crtc->last_f
Thanks for your cooperation.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.fre
erve it at all.
>>
>> That a good point, I honestly can't remember any more why it's here...
>> It does look unnecessary given that we are not validating the BO here.
>
> I think we reserve it to grab the tiling flags to update the plane
> address (and some ot
On 2019-02-14 5:57 p.m., Kazlauskas, Nicholas wrote:
> On 2/14/19 11:47 AM, Grodzovsky, Andrey wrote:
>>
>> On 2/14/19 11:07 AM, Michel Dänzer wrote:
>>> On 2019-02-14 4:54 p.m., Kazlauskas, Nicholas wrote:
>>>> On 2/14/19 10:42 AM, Grodzovsky, Andrey wrote:
On 2019-02-14 9:58 p.m., Alex Deucher via amd-gfx wrote:
> Carried over from radeon, but no longer used.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software e
See the attached dmesg excerpt. I've hit this a few times running piglit
with amd-staging-drm-next, first on February 22nd.
The memory was freed after calling hmm_mirror_unregister in
amdgpu_mn_destroy.
--
Earthling Michel Dänzer | https://www.amd.com
Libre sof
to workaround the issue.
Please push it to amd-staging-drm-next, so that others don't run into
the issue as well.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
__
e change?
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^~
./include/linux/kernel.h:879:19: note: in expansion of macro ‘__careful_cmp’
#define min(x, y) __careful_cmp(x, y, <)
^
drivers/gpu/drm//amd/amdgpu/amdgpu_ras.c:162:14: note: in expansion of
macro ‘min’
ssize_t s = min(64ULL, size);
drm_now % 100,
>
This isn't a good solution I'm afraid, as it'll leave the struct
amdgpu_drm_queue_entry memory associated with event_info->drm_queue_seq
linked into the amdgpu_drm_queue list, which would gradually slow down
processing o
On 2019-02-28 1:05 p.m., Michel Dänzer wrote:
> On 2019-02-28 3:52 a.m., Aaron Liu wrote:
>>
>> @@ -900,7 +900,12 @@ CARD32 amdgpu_dri2_deferred_event(OsTimerPtr timer,
>> CARD32 now, pointer data)
>> delta_seq = delta_t * drmmode_crtc->dpms_last_fps
On 2019-03-01 7:37 a.m., Liu, Aaron wrote:
> @Michel Dänzer,
>
> I have reviewed your patch and verified it passed.
Thanks Aaron, so I assume I can add
Reviewed-by: Aaron Liu
Tested-by: Aaron Liu
?
> I couldn't merge this merge request to your master manually.
Don'
Thanks Marek for the patch, but xf86-video-amdgpu patches are being
reviewed as GitLab merge requests since the last release[0].
I'll create a merge request with this patch and some follow-up changes.
[0] Isn't README.md clear enough on this?
--
Earthling Mic
From: Michel Dänzer
drm_queue_handler just puts the event on the signalled list; without
calling drm_queue_handle_deferred, actual processing of the event may be
delayed indefinitely, e.g. until another event arrives from the kernel.
This could result in DRI2 clients hanging during DPMS off
From: Michel Dänzer
If they don't, flipping will result in corrupted display.
Test case:
* Run Xorg at 1920x1080 with no window manager
* glxgears -geometry 2048x1080
The Present extension code in xserver 1.21 will check for this.
(Ported from amdgpu c
From: Michel Dänzer
The compiler pointed out that one if block unintentionally wasn't part
of the loop:
In file included from ./include/linux/kernfs.h:14,
from ./include/linux/sysfs.h:16,
from ./include/linux/kobject.h:20,
from ./include/
nes;
> + /* There is one primary plane per CRTC */
> + primary_planes = dm->dc->caps.max_streams;
> + ASSERT(primary_planes < AMDGPU_MAX_PLANES);
This assertion fails for me with Bonaire. In fact, since
AMDGPU_MAX_PLANES is 6, and primary_planes seems to be the number o
On 2019-03-05 6:24 p.m., Nicholas Kazlauskas wrote:
> [Why]
> Can happen on ASICs with 6 planes, but this isn't a bug since we haven't
> written outside the array.
>
> [How]
> Use <= instead of <.
>
> Cc: Leo Li
> Cc: Michel Dänzer
> Reporte
anks Leo, but I already sent a fix for this:
https://patchwork.freedesktop.org/patch/290410/
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd
so buggy/malicious userspace could
spam dmesg with these errors. I'm afraid a different solution is needed.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
ns.
Plus other improvements and fixes. Thanks to everybody who contributed
to this release in any way!
Mario Kleiner (1):
Fix crash when page flipping in multi-X-Screen/Zaphod mode
Michel Dänzer (53):
Post-release version bump
Convert README to markdown
Handle pending sc
On 2019-03-06 3:42 p.m., Yang, Philip wrote:
> On 2019-03-06 4:05 a.m., Michel Dänzer wrote:
>> On 2019-03-05 7:09 p.m., Yang, Philip wrote:
>>> If using old kernel config file, CONFIG_ZONE_DEVICE is not selected,
>>> so CONFIG_HMM and CONFIG_HMM_MIRROR is not enabled, t
589] [drm] SADs count is: -2, don't need to read it
>
> I didn’t provide the output of xrandr in my previous message.
>
> $ xrandr --listmonitors
> Monitors: 2
> 0: +DisplayPort-9 1920/698x2160/392+0+0 DisplayPor
ed\n");
>>> + DRM_WARN_ONCE("add CONFIG_ZONE_DEVICE=y in config file to fix
>>> this\n");
>>
>> One message please, apart from that looks good to me.
>>
>> Christian.
>>
> Do you mean use multiple line string with one DRM_
t;
> + "add CONFIG_ZONE_DEVICE=y in config file to fix this\n");
With the second line indentation fixed to properly line up with the
opening parenthesis,
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | https://www.amd.com
Libre software en
age flipping in multi-X-Screen/Zaphod mode
Michel Dänzer (30):
dri3: Handle radeon_get_pixmap_bo returning NULL
Handle pending scanout update in drmmode_crtc_scanout_free
Make wait_pending_flip / handle_deferred symmetric in set_mode_major
Allow up to six instances in Zaphod
t? Maybe you ran into the Mesa bug fixed by
https://gitlab.freedesktop.org/mesa/mesa/commit/c0a540f32067cc8cb126d9aa1eb12a11cf15373a?merge_request_iid=202
, or a similar bug elsewhere?
--
Earthling Michel Dänzer | https://www.amd.com
Libre software en
IORITY_VERYHIGH;
if (bp->type == ttm_bo_type_kernel)
bo->tbo.priority = TTM_BO_PRIORITY_VERYHIGH;
else
bo->tbo.priority = bp->priority;
would be clearer I think.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
On 2019-03-07 11:48 a.m., zhoucm1 wrote:
> On 2019年03月07日 17:55, Michel Dänzer wrote:
>> On 2019-03-07 10:15 a.m., Chunming Zhou wrote:
>>> Signed-off-by: Chunming Zhou
>> Please provide corresponding UMD patches showing how this is to be used.
> spec is here:
> ht
On 2019-03-06 5:35 p.m., Paul Menzel wrote:
> On 03/06/19 15:55, Michel Dänzer wrote:
>> On 2019-03-06 1:41 p.m., Paul Menzel wrote:
>>> On 03/05/19 20:07, Alex Deucher wrote:
>>>> On Tue, Mar 5, 2019 at 1:16 PM Paul Menzel wrote:
>>>
>>>>> U
our in the commit
log, and it doesn't seem related to checking a VBIOS table for ECC
capability. Was it intended?
P.S. AFAICT this patch wasn't submitted to the amd-gfx list for review.
All changes must be reviewed here before being applied to
amd-staging-drm-next.
--
Ear
From: Michel Dänzer
This reverts commit 274703087f80342f51fa69c935bb9a1cb0c4ae47.
Reports of visual corruption were bisected to this, e.g.
https://bugs.archlinux.org/task/61941 . I can reproduce this with Turks,
but not with Bonaire. I assume it's a Mesa/glamor bug, but let's reve
mber of IVs processed at once */
> +#define AMDGPU_IH_MAX_NUM_IVS32
> +
> struct amdgpu_device;
> struct amdgpu_iv_entry;
>
>
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast |
your editor is properly configured for the Linux kernel coding style.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailin
86-video-amdgpu requires the amdgpu kernel driver. Assuming the latter
is working with your card, the former will work (as well as the generic
modesetting Xorg driver).
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast
On 2019-02-05 6:40 p.m., Michel Dänzer wrote:
>
> FWIW, I've hit this twice now today, whereas I don't remember ever
> hitting it before (not 100% sure though).
>
> I reverted the remaining hunk of the "cleanup setting bulk_movable"
> change, and it sur
On 2019-03-12 3:26 p.m., Koenig, Christian wrote:
> Am 12.03.19 um 14:47 schrieb Michel Dänzer:
>> On 2019-02-05 6:40 p.m., Michel Dänzer wrote:
>>> FWIW, I've hit this twice now today, whereas I don't remember ever
>>> hitting it before (not 100% sure thou
vm->evicted);
> +
> list_for_each_entry_safe(bo_base, tmp, &vm->evicted, vm_status) {
> struct amdgpu_bo *bo = bo_base->bo;
>
>
Reviewed-by: Michel Dänzer
Tested-by: Michel Dänzer
--
Earthling Michel Dänzer |
be waiting for a flip - eg. DMCU powering down HUBP during PSR
> entry. Static screen interrupt should happen after that flip finishes I
> think.
>
> The CRTC can still be powered on with zero planes, and I don't think any
> userspace explicitly asks for vblank events in this ca
On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> For Mesa, we could run CI only when Marge pushes, so that it's a strictly
> pre-merge CI.
Thanks for the suggestion! I implemented something like this for Mesa:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432
--
Earth
always NULL here,
and I don't think MST connectors getting added after dev->registered is
set can be avoided?
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
Apr 3 17:32:55 thor kerne
7;t fix all of those, there's also one
triggered by dm_dp_add_mst_connector => drm_encoder_init.
git grep mst_encoders drivers/gpu/drm/i915/
shows how the i915 driver deals with this.
Can you guys take care of that for 5.7 as well?
--
Earthling Michel Dänzer |
ered jobs don't exist at all in the pipeline, so they can't
be triggered by any means. :)
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
_
r 5.7.
That'll be great, thanks!
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://l
(3 << SH_MEM_CONFIG__INITIAL_INST_PREFETCH__SHIFT))
>
>
I bisected a bunch of piglit regressions (mostly half-float related,
e.g. draw-vertices-half-float_gles2) with radeonsi on Navi 10 to this
change.
Does radeonsi/LLVM need corresponding changes?
--
Earthling Miche
On 2020-04-16 3:25 p.m., Deucher, Alexander wrote:
> [AMD Official Use Only - Internal Distribution Only]
>
>> -Original Message-
>> From: amd-gfx On Behalf Of
>> Michel Dänzer
>> Sent: Thursday, April 16, 2020 5:57 AM
>> To: Gao, Likun ; Marek O
hey should be a NO-OP on x86 if everything is done right.
The *b*e macros aren't NOPs on little endian architectures like x86,
they are on big endian architectures. Vice versa for the *l*e macros.
--
Earthling Michel Dänzer | https://redhat.com
indowPtr only. *
>
> Can you please help me in understanding on this ?
This code in amdgpu_vrr_property_update is for the case when the
ChangeProperty request is called for a window which is already flipping.
In the case you're looking at, the window only starts flipping later,
and the KMS property
sa-defaults.conf (mostly for compositors /
browsers / video players).
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing
On 2020-04-20 6:45 p.m., uday kiran pichika wrote:
> On Mon, Apr 20, 2020 at 9:45 PM Michel Dänzer wrote:
>> On 2020-04-20 6:04 p.m., uday kiran pichika wrote:
>>>
>>> Even in amdgpu_present_flip(), there is a check
>>> for amdgpu_window_has_variable_ref
From: Michel Dänzer
Once should generally be enough for diagnosing what lead up to it,
repeating it over and over can be pretty annoying.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/display/dc/os_types.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu
On 2020-04-30 4:55 p.m., Alex Deucher wrote:
> On Wed, Apr 29, 2020 at 12:28 PM Michel Dänzer wrote:
>>
>> From: Michel Dänzer
>>
>> Once should generally be enough for diagnosing what lead up to it,
>> repeating it over and over can be pretty annoying.
&
3
> -#define KMS_DRIVER_MINOR 36
> +#define KMS_DRIVER_MINOR 37
> #define KMS_DRIVER_PATCHLEVEL0
>
> int amdgpu_vram_limit = 0;
>
This requires the parent commit fdf83646c0542ecfb9adc4db8f741a1f43dca058
"drm/amdgpu: invalidate L2 before SDMA IBs (v2)
401 - 500 of 2109 matches
Mail list logo
