on of continuation lines
to match the modified first line.
--
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
From: Michel Dänzer
We were trying to already, but testing the wrong pointer.
Fixes: b85b7b11f5b5 "Add struct radeon_buffer"
Bug: https://bugs.debian.org/910846
Signed-off-by: Michel Dänzer
---
src/radeon_dri3.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
From: Michel Dänzer
Corresponding to up to six CRTCs being available in the hardware.
(Ported from amdgpu commit c9d43c1deb9a9cfc41a8d6439caf46d12d220853)
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 38 -
src/radeon.h | 2 +-
src
From: Michel Dänzer
We have to wait for a pending scanout flip or abort a pending scanout
update, otherwise the corresponding event handler will likely crash
after drmmode_crtc_scanout_free cleaned up the data structures.
Fixes crash after VT switch while dedicated scanout pixmaps are enabled
From: Michel Dänzer
We were always calling the latter, but not always the former, which
could result in handling deferred DRM events prematurely.
(Ported from amdgpu commit 955373a3e69baa241a1f267e96d04ddb902f689f)
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 6 +-
1 file
On 2018-10-23 2:20 p.m., Christian König wrote:
> Ping once more! Adding a few more AMD people.
>
> Any comments on this?
Patches 1 & 3 are a bit over my head I'm afraid.
Patches 2, 4, 6-8 are
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer |
König
As this is a bug fix, should it be before patch 5 and have Cc: stable?
Either way, with the above fixed,
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
On 2018-10-31 2:38 p.m., Kazlauskas, Nicholas wrote:
> On 10/30/18 11:34 AM, Kazlauskas, Nicholas wrote:
>> On 10/30/18 5:29 AM, Michel Dänzer wrote:
>>> On 2018-10-29 7:03 p.m., Ville Syrjälä wrote:
>>>> On Mon, Oct 29, 2018 at 05:37:49PM +0100, Michel Dänzer wrote
On 2018-10-31 3:41 p.m., Kazlauskas, Nicholas wrote:
> On 10/31/18 10:12 AM, Michel Dänzer wrote:
>> On 2018-10-31 2:38 p.m., Kazlauskas, Nicholas wrote:
>>> On 10/30/18 11:34 AM, Kazlauskas, Nicholas wrote:
>>>>
>>>> I understand the issue you're
On 2018-10-31 6:54 p.m., Kazlauskas, Nicholas wrote:
> On 10/31/18 12:20 PM, Michel Dänzer wrote:
>> On 2018-10-31 3:41 p.m., Kazlauskas, Nicholas wrote:
>>> On 10/31/18 10:12 AM, Michel Dänzer wrote:
>>>> On 2018-10-31 2:38 p.m., Kazlauskas, Nicholas wrote:
>>
On 2018-11-01 3:58 p.m., Kazlauskas, Nicholas wrote:
> On 11/1/18 6:58 AM, Michel Dänzer wrote:
>> On 2018-10-31 6:54 p.m., Kazlauskas, Nicholas wrote:
>>> On 10/31/18 12:20 PM, Michel Dänzer wrote:
>>>> On 2018-10-31 3:41 p.m., Kazlauskas, Nicholas wrote:
>>>
On 2018-10-30 4:52 p.m., Marek Olšák wrote:
> On Tue, Oct 30, 2018, 11:49 AM Marek Olšák wrote:
>> On Tue, Oct 30, 2018, 4:20 AM Michel Dänzer wrote:
>>
>>> On 2018-10-29 10:15 p.m., Marek Olšák wrote:
>>>> You and I discussed this extensively inter
On 2018-10-29 8:11 p.m., Kazlauskas, Nicholas wrote:
> On 10/29/18 2:03 PM, Ville Syrjälä wrote:
>> On Mon, Oct 29, 2018 at 05:37:49PM +0100, Michel Dänzer wrote:
>>> On 2018-10-26 7:59 p.m., Ville Syrjälä wrote:
>>>> On Fri, Oct 26, 2018 at 05:34:15PM +00
thling 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
On 2018-10-29 7:03 p.m., Ville Syrjälä wrote:
> On Mon, Oct 29, 2018 at 05:37:49PM +0100, Michel Dänzer wrote:
>> On 2018-10-26 7:59 p.m., Ville Syrjälä wrote:
>>> On Fri, Oct 26, 2018 at 05:34:15PM +, Kazlauskas, Nicholas wrote:
>>>> On 10/26/18
ld be "MHz" for megahertz.
--
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.f
lso check at runtime that GPU
recovery is actually enabled, as that still isn't the case by default
except with bleeding edge amdgpu kernel code.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and
On 2018-10-25 7:57 p.m., Wentland, Harry wrote:
> On 2018-10-12 4:31 a.m., Koenig, Christian wrote:
>> Am 12.10.2018 um 10:26 schrieb Michel Dänzer:
>>> On 2018-10-11 9:44 p.m., Harry Wentland wrote:
>>>> On 2018-10-03 04:25 AM, Mike Lothian wrote:
>>>>>
an, that's unlikely to actually be
used here, but if it were, exporting and importing the resulting BO
should work fine?
Instead of white-listing the domains which can be shared, it might be
better to black-list those which can't, i.e. GDS/GWS/OA.
--
Earthling Michel Dänzer
hem for animation timing.
Maybe the timestamp could be updated appropriately (yes, I'm hand-waving
:) in drm_crtc_send_vblank_event?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
_
On 2018-10-05 7:14 p.m., Nick Alcock wrote:
> On 5 Oct 2018, Michel Dänzer told this:
>
>> On 2018-10-04 9:58 p.m., Nick Alcock wrote:
>>> So a few days ago I started getting sprays of these warnings --
>>> sorry, but because it was a few days ago I'm not sure what
SP == 2 != AMDGPU_FW_LOAD_DIRECT == 0
I suspect you meant something else here.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd
change of that commit in
this patch. Probably better to wait until all the bugs have been fixed,
then re-apply the "move PD/PT bos on LRU again" patch.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Me
pu_bo_handle bo)
> +{
> + atomic_inc(>refcount);
> + return 0;
> +}
What's the point of having a non-void return value that's always 0?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X
o.c
> +++ b/amdgpu/amdgpu_bo.c
> @@ -438,10 +438,9 @@ int amdgpu_bo_free(amdgpu_bo_handle buf_handle)
> return 0;
> }
>
> -int amdgpu_bo_inc_ref(amdgpu_bo_handle bo)
> +void amdgpu_bo_inc_ref(amdgpu_bo_handle bo)
> {
> atomic_
On 2018-08-31 3:10 p.m., Christian König wrote:
> Add BOs to the idle state again and correctly clear the flag when
> new BOs are added.
>
> Signed-off-by: Christian König
Typo in the shortlog: bulk_moveavle -> bulk_moveable
The series is
Tested-by: Michel Dänzer
T
On 2018-08-31 4:46 p.m., Thomas Hellstrom wrote:
> On 08/31/2018 04:38 PM, Michel Dänzer wrote:
>> [ Adding the amd-gfx list ]
>>
>> On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote:
>>> On 08/31/2018 02:30 PM, Emil Velikov wrote:
>>>> On 31 August 2
ndalone vmwgfx is using dynamic major allocation.
I wonder why I haven't heard of any of these issues with the standalone
version of amdgpu shipped in packaged AMD releases. Does that also use a
different major number? If yes, maybe it's just that nobody has tried
Xwayland clients with
On 2018-09-19 6:46 p.m., Michel Dänzer wrote:
>
> With the 18.1.0 release out the door, I want to start making use of more
> Gitlab features for xf86-video-amdgpu development.
>
> I've already enabled merge requests (MRs) at
> https://gitlab.freedesktop.org/xorg/driver/xf86-v
op.org/xorg/driver/xf86-video-amdgpu
using the button with the bell symbol at the top right. (This will only
work if you're logged into your Gitlab account)
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X dev
On 2018-09-21 9:57 a.m., Christian König wrote:
> Am 21.09.2018 um 09:42 schrieb Michel Dänzer:
>> On 2018-09-21 9:22 a.m., Zhou, David(ChunMing) wrote:
>>> After moving patch submitted and reviewed as MRs, mail list will be
>>> no useful? And many people could miss ne
ach
notification e-mail contains an URL which can be used to disable
notification e-mails for the given MR to the corresponding account,
which works without logging into the account. It looks like this is by
design, e.g. so that it can work in e-mail clients via the
List-Unsubscribe header.
--
object *bo;
> - bool shared;
> + unsigned int shared;
> };
>
> /**
>
It would be better to change the name of the field to something more
descriptive, e.g. "num_shared_fence_contexts", and fix up all users
accordingly in this patch
re assigning values > 1 to this field, it would be good to have a
comment explaining what the multiple shared fence slots correspond to.
Same for patch 6.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X de
, or if the patch has already landed, an incremental fix-up
patch. If it isn't clear what the issue is, please ask.
This is a free service which can help improve the quality of our
patches, let's take advantage of it.
--
Earthling Michel Dänzer | http://www.amd.com
Libre
of this is new territory for me, I'll figure it out as I go along.
Please bear with me. Once the new stuff has proven to work well for
xf86-video-amdgpu, I want to start using it for -ati as well.
Don't hesitate to ask questions or give feedback on this.
--
Earthling Michel Dänzer
the user running e.g.
xrandr --output --set variable_refresh_enabled 1
would result in variable refresh being enabled regardless of whether a
variable refresh compatible client is currently using page flipping,
which can result in flickering or getting stuck at the minimum refresh rate.
--
Ear
On 2018-09-25 4:04 p.m., Ville Syrjälä wrote:
> On Tue, Sep 25, 2018 at 03:28:28PM +0200, Michel Dänzer wrote:
>> On 2018-09-24 10:26 p.m., Ville Syrjälä wrote:
>>> On Mon, Sep 24, 2018 at 03:06:02PM -0400, Kazlauskas, Nicholas wrote:
>>>> On 09/24/2018
m, 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 please follow the pr
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.
>>>
>>> [...]
&
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 by 5.0 final (though
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
>
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:
>
; '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 |
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
; 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 | Mesa a
On 2018-12-12 3:58 p.m., Kazlauskas, Nicholas wrote:
> On 12/12/18 9:40 AM, Michel Dänzer wrote:
>> On 2018-12-12 3:17 p.m., Kazlauskas, Nicholas wrote:
>>> On 12/12/18 9:10 AM, Michel Dänzer wrote:
>>>> On 2018-12-12 3:04 p.m., Nicholas Kazlauskas wrote:
>>>
On 2018-12-12 3:17 p.m., Kazlauskas, Nicholas wrote:
> On 12/12/18 9:10 AM, Michel Dänzer wrote:
>> On 2018-12-12 3:04 p.m., Nicholas Kazlauskas wrote:
>>> [Why]
>>> The cursor calculations in amdgpu_dm incorrectly assume that the
>>> cursor hotspot is alway
From: Michel Dänzer
It indicates a pin/unpin imbalance bug somewhere. While the bug isn't
necessarily in the call chain hitting this, it's at least one part
involved.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
it/0d60233d26ec70d4e1faa343b438e33829c6d5e4
, i.e. alternating between two BOs for the HW cursor, instead of always
using the same one.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
Dec 13 16:35:
rtc,
> + struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode,
> + int x, int y, struct drm_framebuffer *old_fb)
Indentation of the continuation lines here looks
rom it, but that shouldn't be
necessary here.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
ht
On 2018-12-21 9:45 a.m., Deng, Emily wrote:
>> -Original Message-
>> From: Michel Dänzer
>> Sent: Friday, December 21, 2018 4:38 PM
>> To: Deng, Emily
>> Cc: amd-gfx@lists.freedesktop.org
>> Subject: Re: [PATCH] drm/amdgpu/virtual_dce: Need to pin the
On 2018-12-21 10:32 a.m., Deng, Emily wrote:
>> -Original Message-
>> From: Michel Dänzer
>> Sent: Friday, December 21, 2018 5:28 PM
>> To: Deng, Emily
>> Cc: amd-gfx@lists.freedesktop.org
>> Subject: Re: [PATCH] drm/amdgpu/virtual_dce: Need to pin t
On 2018-12-21 11:15 a.m., Deng, Emily wrote:
>> -Original Message-
>> From: Michel Dänzer
>> Sent: Friday, December 21, 2018 6:08 PM
>> To: Deng, Emily
>> Cc: amd-gfx@lists.freedesktop.org
>> Subject: Re: [PATCH] drm/amdgpu/virtual_dce: Need to pin t
_status thus will refuse to notify the job
> completion. The job will eventually times out.
>
> Reverse the order of calling page_flip and setting pflip_status to
> fix the race.
There is no race, amdgpu_crtc->pflip_status is protected by dev->event_lock.
On 2018-12-21 10:17 a.m., Deng, Emily wrote:
>> From: amd-gfx On Behalf Of Deng,
>> Emily
>>> From: Michel Dänzer
>>> On 2018-12-21 9:45 a.m., Deng, Emily wrote:
>>>>> From: Michel Dänzer
>>>>> On 2018-12-21 8:26 a.m., Emily Den
dn't be printed by default, or buggy / malicious
userspace can spam dmesg. I suggest using DRM_DEBUG_KMS or DRM_DEBUG_DRIVER.
> + return ERR_PTR(-EINVAL);
> + }
>
> obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[0]);
> if (obj == NULL) {
&
>height, 8);
> + if (obj->size < pitch * height) {
> + dev_err(>pdev->dev, "Invalid GEM size: expecting %d but
> got %d\n",
> + pitch * height, obj->size);
Same comment as patch 2, and maybe write "expecting >= %d but
On 2018-12-21 10:55 a.m., Deng, Emily wrote:
>> -Original Message-
>> From: amd-gfx On Behalf Of Deng,
>> Emily
>> Sent: Friday, December 21, 2018 5:41 PM
>> To: Michel Dänzer
>> Cc: amd-gfx@lists.freedesktop.org
>> Subject: RE: [PATCH] drm/a
pu_align_pitch(adev, mode_cmd->width, cpp, false);
Also, this needs to use mode_cmd->pitches[0] instead of mode_cmd->width,
otherwise it'll spuriously fail for larger but well-aligned pitches.
--
Earthling Michel Dänzer |
t be tested appropriately (against the target branch),
ideally before submitting them for review. Reviewers are not expected to
look for things which trivially break the build.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
On 2018-12-23 10:44 p.m., Yu Zhao wrote:
> On Fri, Dec 21, 2018 at 10:07:26AM +0100, Michel Dänzer wrote:
>> On 2018-12-21 4:10 a.m., Yu Zhao wrote:
>>> Userspace may request pitch alignment that is not supported by GPU.
>>> Some requests 32, but GPU ignores it a
if (unlikely(amdgpu_bo_unpin(new_abo) != 0))
DRM_ERROR("failed to unpin new abo in error path\n");
}
P.S. A lot of people are out for Christmas and New Year's.
--
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
if (amdgpu_crtc->cursor_bo) {
> + if (amdgpu_crtc->cursor_bo &&
> !adev->enable_virtual_display) {
> struct amdgpu_bo *aobj =
> gem_to_amdgpu_bo(amdgpu_crtc->cursor_bo);
> r = amdgpu_bo_reserve(a
On 2018-12-21 7:23 p.m., Koenig, Christian wrote:
> Am 21.12.18 um 19:19 schrieb Alex Deucher:
>> On Fri, Dec 21, 2018 at 1:15 PM Christian König
>> wrote:
>>> Am 21.12.18 um 10:09 schrieb Deng, Emily:
>>>>> From: Michel Dänzer
>>>>> On
On 2018-12-13 9:59 p.m., Kazlauskas, Nicholas wrote:
> On 12/13/18 2:21 PM, Kazlauskas, Nicholas wrote:
>> On 12/13/18 11:01 AM, Kazlauskas, Nicholas wrote:
>>> On 12/13/18 10:48 AM, Michel Dänzer wrote:
>>>> On 2018-12-05 8:59 p.m., Nicholas Kazlauskas wrote:
>>
you think that making this the generic solution by moving this from
> dm_plane_atomic_async_check to drm_atomic_helper_async_check
> will break other drivers ?
Please raise and discuss this with other developers on the dri-devel
mailing list. :)
Anyway, this looks like a much better solution for
(cursor_update) to dm_plane_state that's only
> ever set to true during the fast path. If it's true, then cleanup_fb
> doesn't unpin and unref the fb.
>
> Cc: Leo Li
> Cc: Harry Wentland
> Cc: Michel Dänzer
> Signed-off-by: Nicholas Kazlauskas
>
> [...]
>
> @@
;= 0 ? x : 0;
> + position->y = y >= 0 ? y : 0;
> + position->x_hotspot = plane->state->fb->hot_x;
> + position->y_hotspot = plane->state->fb->hot_y;
I don't see how this could work correctly. Try moving a cursor which
doesn't have the hot spot a
From: Michel Dänzer
This should be functionally equivalent to what drmModeSetCursor(2) do
behind the scenes, but allows for new tricks in following changes.
(Ported from amdgpu commit b344e1559e936046ef02c777fc4f6bcefa3830bc)
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 21
From: Michel Dänzer
The un-premultiplied R/G/B values would overflow the gamma LUT, so just
pass through the data unchanged, and leave it up to the HW how to
interpret such weird premultiplied alpha pixels.
Bugzilla: https://bugs.freedesktop.org/108355
(Ported from amdgpu commit
From: Michel Dänzer
Not needed or even useful for anything.
(Ported from amdgpu commit e95044e45350870fa7e237860e89ade91ac03550)
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 9 -
src/drmmode_display.h | 1 -
src/radeon.h | 1 -
src/radeon_kms.c | 21
From: Michel Dänzer
Otherwise the damaged screen contents may never be displayed in that
case.
(Ported from amdgpu commit 500fadb16285146e91f62fce3a0ce1360ca684ba)
Signed-off-by: Michel Dänzer
---
src/radeon_kms.c | 29 +++--
1 file changed, 19 insertions(+), 10
From: Michel Dänzer
It was still possible for nested xorg_list_for_each_entry_safe loops
to occur over the drm_vblank_signalled list, which could mess up that
list. Moving deferred events to a separate list allows processing the
drm_vblank_signalled list without xorg_list_for_each_entry_safe
From: Michel Dänzer
drmmode_crtc_scanout_update does the equivalent of a scanout update,
so no need to do it again. This might also avoid issues if there's a
pending scanout update at this point.
(Ported from amdgpu commit 4e7a24ac5a64e402146953ec5850d13c05742116)
Signed-off-by: Michel Dänzer
From: Michel Dänzer
When an async flip is performed, and TearFree is enabled on the CRTC
used for timing, we schedule a vblank event for completing the page
flip. The DRM event queuing code treated this event like a vblank event,
but it needs to be treated like a page flip event.
(Ported from
From: Michel Dänzer
X server >= 1.18 already had code for this, but it only caught cases
where some pixels have 0 for alpha and non-0 for a non-alpha component.
Turns out some apps (e.g. the Civilization VI game) use
non-premultiplied cursor data which doesn't have such pixels, but can
st
From: Michel Dänzer
The cursor position is updated to be consistent with the new hotspot in
the same ioctl call.
(Ported from amdgpu commit b04697de5270e8e45744a7025c24df1f454a4cf0)
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 75 +--
src
From: Michel Dänzer
At this point, we've already established that e->handler is NULL, no
need to check again in drm_queue_handle_one. This also makes it clearer
what's happening.
(Ported from amdgpu commit eda571222f5a6be47f8897e82d85199bb9d95251)
Signed-off-by: Michel Dänzer
---
From: Michel Dänzer
These are the outstanding applicable changes ported from
xf86-video-amdgpu.
Michel Dänzer (13):
Detect and fix up non-premultiplied cursor data
Skip gamma correction of cursor data if premultiplied R/G/B > alpha
glamor: Can work at depth >= 15 with current xserv
From: Michel Dänzer
(Ported from amdgpu commit 0734cdf544ffd3f2ac8749ad0e4bf43f8a5cea50)
Signed-off-by: Michel Dänzer
---
src/radeon_bo_helper.c | 2 ++
src/radeon_glamor.c| 9 +++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/radeon_bo_helper.c b/src
From: Michel Dänzer
Switch to the other buffer when xf86_config->cursor changes. Avoids
these issues possible when re-using the same buffer:
* The HW may intermittently display a mix of the old and new cursor
images.
* If the hotspot changes, the HW may intermittently display the new
cur
On 2018-12-05 12:41 p.m., Koenig, Christian wrote:
> Am 05.12.18 um 12:33 schrieb Michel Dänzer:
>> On 2018-12-05 12:24 p.m., Koenig, Christian wrote:
>>> Am 05.12.18 um 11:29 schrieb Michel Dänzer:
>>>> On 2018-12-04 6:35 p.m., Koenig, Christian wrote:
>>>&
On 2018-12-05 12:24 p.m., Koenig, Christian wrote:
> Am 05.12.18 um 11:29 schrieb Michel Dänzer:
>> On 2018-12-04 6:35 p.m., Koenig, Christian wrote:
>>> Thanks, going to take a look tomorrow.
>> I also hit this with Bonaire in my development system. I wonder why you
>&g
suggesting gitlab merge requests.
Pushed, thanks Alan!
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.fre
the drm_crtc
>>>> 'vrr_enabled' properties.
>>>>
>>>> Signed-off-by: Nicholas Kazlauskas
>>>> Cc: Harry Wentland
>>>> Cc: Manasi Navare
>>>> Cc: Pekka Paalanen
>>>> Cc: Ville Syrjälä
>>>> Cc: Michel
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
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
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 rep
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
/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
> DMA
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
;>> [...]
>>>
>>> 79c6b898011958fba7722528d567b64e1cdc8dbe is the first bad commit
>>> commit 79c6b898011958fba7722528d567b64e1cdc8dbe
>>> Author: Yu Zhao
>>> Date: Mon Jan 7 15:51:14 2019 -0700
>>>
>>> drm/amdgpu: validate us
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
REATE_CPU_GTT_USWC;
>
Thanks for taking care of this Christian. Maybe add a reference to at
least one of the bug reports about this, but either way:
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software ent
On 2019-01-07 4:21 p.m., Mikhail Gavrilov wrote:
> On Mon, 7 Jan 2019 at 15:09, Michel Dänzer wrote:
>>
>> Is this reproducible with commit 674e78acae0d ("drm/amd/display: Add
>> fast path for cursor plane updates") + the patch above?
>
> Yes. I am sure I am
On 2019-01-07 5:00 a.m., Yu Zhao wrote:
> On Thu, Jan 03, 2019 at 05:33:19PM +0100, Michel Dänzer wrote:
>> On 2018-12-30 2:00 a.m., Yu Zhao wrote:
>>> Userspace may request pitch alignment that is not supported by GPU.
>>> Some requests 32, but GPU ignores it and uses d
1301 - 1400 of 1906 matches
Mail list logo
