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
d
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 digital si
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
t; 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 aspect
affecti
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
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
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
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
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 70a816dd8b4d.
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-intel/commit
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
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.freedesk
>
> 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 |
From: Michel Dänzer
The entries were only initialized once in amdgpu_sa_bo_new. If a fence
wasn't signalled yet in the first amdgpu_sa_bo_next_hole call, but then
got signalled before a later amdgpu_sa_bo_next_hole call, it could
destroy the fence but leave its pointer in the array, resulting
On 2018-09-12 2:48 p.m., Kazlauskas, Nicholas wrote:
> On 09/12/2018 04:13 AM, Michel Dänzer wrote:
>> On 2018-09-11 6:18 p.m., Nicholas Kazlauskas wrote:
>>> These patches are part of a proposed new interface for supporting
>>> variable refresh rate via DR
From: Michel Dänzer
We would crash due to dereferencing the NULL mode_res->crtc pointer.
Bugzilla: https://bugs.freedesktop.org/107913
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/drmmode_display.c b/src/drmmode_displa
drmmode_crtc_scanout_free
Keith Packard (3):
modesetting: Record non-desktop kernel property at PreInit time
modesetting: Create CONNECTOR_ID properties for outputs [v2]
Add RandR leases support
Michel Dänzer (55):
Bail from dri2_create_buffer2 if we can't get a pixmap
glamor: Bail
on output_get_property
Enable setting of color properties via RandR
Compose non-legacy with legacy regamma LUT
Also compose LUT when setting legacy gamma
Michel Dänzer (48):
Post-release version bump
Ignore AMDGPU_DRM_QUEUE_ERROR (0) in amdgpu_drm_abort_entry
Track DRM event
pulation with list helper, it
> should not trigger the list corruption. The usage of those helpers should
> ensure the list operation safely...
There's nothing the helpers can do about being passed in pointers to
stack memory. It's a bug in the code using the helpers.
--
Earthling Miche
ncobj_reset
> amdgpu_cs_syncobj_signal
> amdgpu_cs_syncobj_wait
> +amdgpu_cs_syncobj_timeline_wait
> +amdgpu_cs_syncobj_query
> amdgpu_cs_wait_fences
> amdgpu_cs_wait_semaphore
> amdgpu_device_deinitialize
This file should be sorted in lexical order.
--
Earthling Michel Dänzer
reservation_object_assert_held(pos->first->resv);
> + reservation_object_assert_held(pos->last->resv);
> +
> lru = >first->bdev->glob->swap_lru[i];
> - ttm_bo_bulk_move_helper(>swap[i], lru, true);
>
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.
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
2f129984e98886a7ac84b2f)
> 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 |
ut 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 Dänzer
&g
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
---
src
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 flip
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
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
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
ead only allowing the DCC
parameters to change with DRM minor version >= 31 as well. Thanks for
this patch anyway!
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X dev
t I attached shows that SDMA hangs afterwards, so it's
not harmless. :)
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx ma
o submit a zero sized IB to the SDMA.
>
> Signed-off-by: Christian König
Tested-by: Michel Dänzer
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
__
On 2019-03-25 10:05 p.m., Kangjie Lu wrote:
> In case alloc_workqueue fails, the fix frees memory and
> returns -ENOMEM to avoid potential NULL pointer dereference.
>
> Signed-off-by: Kangjie Lu
> ---
> v2: use radeon_crtc_destroy to properly clean up resources as
> sugge
I'm hitting some badness with piglit today, see the attached dmesg
excerpt. I was away for a couple of days, but looks like it might be
related to the VM changes? I'll try bisecting.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast
On 2019-03-26 4:21 p.m., Michel Dänzer wrote:
>
> I'm hitting some badness with piglit today, see the attached dmesg
> excerpt. I was away for a couple of days, but looks like it might be
> related to the VM changes? I'll try bisecting.
Bisected to:
602b5050d839c40572bbb19e9b17
this case and for
radeon_modeset_init to propagate that, which will prevent the driver as
a whole from initializing.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
__
(prev && prev->seqno >= point);
>>
>>
>> I think the WARN/BUG macros should only fire when there is an issue
>> with programming from within the kernel.
>>
>> But this particular warning can be trigge
On 2019-04-05 10:00 p.m., Pinky wrote:
> [...] terminal in X sometimes display black instead of text when
> scrooling.
Sounds like https://bugs.freedesktop.org/show_bug.cgi?id=110214 ?
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enth
,7 @@ static void ttm_put_pages(struct page **pages, unsigned
> npages, int flags,
> unsigned max_size, n2free;
>
> spin_lock_irqsave(>lock, irq_flags);
> - while (i < npages) {
> + while ((npages - i) >= HPAGE_PMD_NR) {
>
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 of that list.
I think I
^~
./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);
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
--
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
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
___
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 software
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 commit
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 scan
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-gfx
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
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
ADs 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 DisplayPort-9
> 1: +Di
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_
e 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 mode
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/linux
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
> Reported-by: Mich
ere 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 of
CRTCs, it'll fail with
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 Michel Dänzer
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't worry
from amdgpu commit 6ee857726166f495abcd68e4ff60e3a09593d079)
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 54 +--
src/drmmode_display.h | 3 +++
2 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/src/drmmode_display.c b/src
From: Michel Dänzer
radeon_glamor_finish only works if we're using glamor, otherwise it'll
crash.
Fixes: ce7db51020d3 "Cancel pending scanout update in
drmmode_crtc_scanout_update"
Bug: https://bugs.debian.org/924540
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 2
of our amd-staging-drm-next includes this patch (about 126 down
> from the tip).
amd-staging-drm-next might be missing more HMM fixes from 5.1, probably
better to wait until we've rebased on that before spending too much more
effort on this.
--
Earthling Michel Dänzer |
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
ty(>evicted);
> +
> list_for_each_entry_safe(bo_base, tmp, >evicted, vm_status) {
> struct amdgpu_bo *bo = bo_base->bo;
>
>
Reviewed-by: Michel Dänzer
Tested-by: Michel Dänzer
--
Earthling Michel Dänzer |
ur 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 mailing lis
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
= >mman.bdev;
> amdgpu_bo_placement_from_domain(bo, bp->domain);
> + bo->tbo.priority = bp->priority;
> if (bp->type == ttm_bo_type_kernel)
> - bo->tbo.priority = 1;
> + bo->tbo.priority = TTM_BO_PRIORITY_VERYHIGH;
if (b
ybe 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 enthusi
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 |
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:
>>>
>>>&
, allowing monitors using
DisplayPort Multi Stream Transport tiling to work better out of the
box.
Thanks to everybody who contributed to this release in any way!
Dave Airlie (1):
modesetting: add tile property support
Michel Dänzer (1):
Bump version for the 19.0.1 release
git tag
contributed to this release in any way!
Dave Airlie (1):
modesetting: add tile property support
Michel Dänzer (3):
Revert "glamor: Avoid glamor_create_pixmap for pixmaps backing windows"
Use radeon_finish in drmmode_crtc_scanout_update
Bump version for 19.0.1 release
git
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 though).
>&
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 survived a pi
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.
--
Earthling Michel Dänzer
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 revert
for now
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
nd machine 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-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
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->las
operation.
--
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
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 other bits of the
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:
gt; 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 solved in a simpler
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
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
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
t; - 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-combining\n");
FWIW, pleas
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.
>
> So in that case,
e 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 |
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 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=Drivers/Vulkan/radeon
.
--
Earthling Michel Dänzer |
>
> 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 | htt
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://www.amd
), GFP_KERNEL);
> +
> + 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 |
ot 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 |
u_device_get_min_pci_speed_width(adev, _speed_cap,
> - _link_width);
> + pcie_bandwidth_available(adev->pdev, NULL,
> + _speed_cap, _link_width);
>
> if (adev-&g
t overlay_formats[] = {
>
Could DRM_FORMAT_ARGB1555 / DRM_FORMAT_C8 be supported as well?
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx
1401 - 1500 of 1906 matches
Mail list logo
