ishes shared ownership), our
> general policy per recommendations is to add the copyright line. It
> helps anyone looking at the file know at a glance that there is more
> than one corporate author, and therefore e.g. the only terms it can
> be used on without a complex multi-party li
of xserver.
A lot 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.
h, 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://ww
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/x
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
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
because each
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 head
ffer_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 p
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
th only the connector property, 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
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
is patch is against 4.18.11: I saw the warnings on 4.17.6 with Mesa
> 18.1.2, but nothing much seems to have changed in this area so I bet
> this could recur.
Not sure it makes sense to have the last paragraph in the Git commit
log, but either way:
Reviewed-by: Michel Dänzer
> Signed-
> Knowing the vmin/vmax could potentially be useful for testing but most
> applications shouldn't be trying to predict or adjust rendering based on
> these.
FWIW, recent research indicates that this is necessary for perfectly
smooth animation without micro-stuttering, even
On 2018-10-05 7:48 p.m., Kazlauskas, Nicholas wrote:
> On 10/05/2018 12:56 PM, Michel Dänzer wrote:
>> On 2018-10-05 6:21 p.m., Kazlauskas, Nicholas wrote:
>>> On 10/05/2018 04:10 AM, Pekka Paalanen wrote:
>>>>
>>>> I also believe that it would be usefu
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
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
ng parameters (BTW Harry,
does that work with DC?), but that should be easy to fix.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
ults can be read through the debugfs entry
> amdgpu_perf_trace. Each result contains the time in ns and
> number of GPU read/writes since the result before it.
>
> In my experimentation, each PERF_TRACE() call uses at most 700ns
Should this use the Linux tracing infrastructure?
--
Eart
a per CRTC property is actually
> the right approach.
>
> What we should rather do instead is to implement a target timestamp for
> the page flip.
You'd have to be more specific about how the latter could completely
replace the former. I don't see how it could.
--
Earthl
On 2018-10-15 11:47 a.m., Christian König wrote:
> Am 15.10.2018 um 11:40 schrieb Michel Dänzer:
>> On 2018-10-13 7:38 p.m., Christian König wrote:
>>> Am 12.10.2018 um 18:44 schrieb Nicholas Kazlauskas:
>>>> This patch introduces the 'vrr_enabled' CRTC pro
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(-)
di
/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> index 0684dcd..a6e18fe 100644
> --- a/include/drm/gpu_scheduler.h
> +++ b/include/drm/gpu_scheduler.h
> @@ -283,12 +283,15 @@ struct drm_gpu_scheduler {
> spinlock_t job_list_lock;
> int
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
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 |
bout AMDGPU_GEM_DOMAIN_CPU? I mean, 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.
--
Eart
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-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:
>>>>>
ich use
them 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
_
s it?
--
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
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 +, Kazlau
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
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 internally a w
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 de
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:
>>>
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
. Ideally, it should also 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 |
ad of 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@list
#x27; and the drm_crtc
>>>> 'vrr_enabled' properties.
>>>>
>>>> Signed-off-by: Nicholas Kazlauskas
>>>> Cc: Harry Wentland
>>>> Cc: Manasi Navare
>>>> Cc: Pekka Paalanen
>>>> Cc: Ville Syrjälä
>>
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
didn't? How are you running piglit?
--
Earthling Michel Dänzer | http://www.amd.com
Libre
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
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:
>>>&
KASAN caught something during today's piglit run, see the attached dmesg
excerpt.
Looks like amdgpu destroys the VM while the scheduler still has a
reference to its entity?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthu
se run
git rm tests/gem_ctx_bad_exec
and re-send the patch.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.
x >= 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
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 always (0
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:
>>>
mdgpu/commit/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
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(+),
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:
>>
ield was added (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
&g
n some following commit).
> Why 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 lo
catch, thanks! Pushed with
Fixes: 740f0850f1e4 "Store FB for each CRTC in drmmode_flipdata_rec"
Reviewed-by: Michel Dänzer
Do you want to make an xf86-video-amdgpu merge request as well? If not,
I can take care of porting the fix. If you do it, please enable the
"Allow commits from membe
On 2018-12-18 8:09 p.m., Mario Kleiner wrote:
> On Tue, Dec 18, 2018 at 3:42 PM Michel Dänzer wrote:
>>
>> Good catch, thanks! Pushed with
>>
>> Fixes: 740f0850f1e4 "Store FB for each CRTC in drmmode_flipdata_rec"
>> Reviewed-by: Michel Dänzer
>&g
900b12f129984e98886a7ac84b2f)
> Signed-off-by: Mario Kleiner
I created
https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/20
for this and merged it, thanks again!
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
tc *crtc,
> + 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
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.o
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
pflip_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_
houldn'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 ==
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 |
eight, 8);
> + if (obj->size < pitch * height) {
> + dev_err(&dev->pdev->dev, "Invalid GEM size: expecting %d but
> got %d\n",
> + pitch * height, obj->size);
Same comment as patch 2, and maybe
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 Deng wrot
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 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
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
xt branch.
Patches must 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 enthu
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än
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
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
Specifically, after both the page flip and vblank ioctls failed, but
then the vblank ioctl started working again. This can happen
intermittently e.g. when hotplugging a DP display. Previously, TearFree
would stay disabled in that case until a modeset was triggered somehow
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
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 c
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
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 and
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
Li
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_reser
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
g/enter_bug.cgi?product=DRI&component=DRM/Radeon
, but note that somebody will likely need to bisect the commit which
introduced it.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
__
return ERR_PTR(-EINVAL);
> + }
>
> obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[0]);
> if (obj == NULL) {
>
Apart from the above, the v5 series looks good to me.
--
Earthling Michel Dänzer | http://www.amd.co
mit.
>> First bad commit: [674e78acae0dfb4beb56132e41cbae5b60f7d662]
>> drm/amd/display: Add fast path for cursor plane updates
>
> IIRC, the issue only shows up with newer versions of the ddx.
Wayland compositors seem to hit it as well, I think Mikhail is using
GNOME on Wayland.
--
Earthling Michel Dänzer
s the GPU to
> hang, so it is not only timing sensitive, but is mainly because of
> wrong openGL commands, that drive the GPU into an invalid state
In that case, the problem would be expected to happen the same way on
x86 as well. There seems to be some kind of platform specific
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
On 2019-01-06 11:26 p.m., Mikhail Gavrilov wrote:
> On Sat, 5 Jan 2019 at 01:13, Mikhail Gavrilov
> wrote:
>>
>> On Fri, 4 Jan 2019 at 23:02, Michel Dänzer wrote:
>>>
>>> On 2019-01-04 4:24 p.m., Alex Deucher wrote:
>>>> On Fri, Jan 4, 2019 at 9:52
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
g, and
page flipping can only be used in Xorg when the application window spans
the whole virtual desktop.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
signature.asc
Description: OpenPGP digit
>
> Cc: sta...@vger.kernel.org # v4.2+
> Signed-off-by: Yu Zhao
Both patches applied to amd-staging-drm-next (should land in 5.0), thanks!
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
27;t needed in older kernels.
--
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
301 - 400 of 2109 matches
Mail list logo
