===
>
> -This section covers core driver infrastructure.
> +This chapter covers core driver infrastructure.
>
> PRIME Buffer Sharing
>
I don't mind either way, but I copied the "section" wording from i915.rst.
--
Earthling Michel Dänzer
_ID_SYNCOBJ_OUT
> + * These will be parsed as fence dependencies in given requirement,
> + * and will be remembered and to be synced later.
> + *
> + * __u32 _pad:
> + *
> + * __u64 chunks:
> + * Point to the CS chunks.
BTW, this kind of formatting isn't preserved in the generated
On 2018-05-31 08:02 PM, Leo Liu wrote:
> On 05/31/2018 01:04 PM, Michel Dänzer wrote:
>> On 2018-05-31 06:49 PM, Leo Liu wrote:
>>> On 05/31/2018 12:47 PM, Michel Dänzer wrote:
>>>> On 2018-05-31 06:39 PM, Leo Liu wrote:
>>>>> On 05/31/2018 12:30 PM, Mi
From: Michel Dänzer
* Fix format of return value descriptions
* Document all parameters of amdgpu_bo_free_kernel
* Document amdgpu_bo_get_preferred_pin_domain
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 78 +++---
1 file changed, 55 insertions
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
Documentation/gpu/amdgpu.rst | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst
index f557866f6788..ad3711fd2a28 100644
--- a/Documentation/gpu/amdgpu.rst
+++ b
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
Documentation/gpu/amdgpu.rst | 9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst
index ad3711fd2a28..1fbf3876a3d8 100644
--- a/Documentation/gpu/amdgpu.rst
+++ b
On 2018-06-01 02:58 PM, Alex Deucher wrote:
> On Thu, May 31, 2018 at 12:17 PM, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> Signed-off-by: Michel Dänzer
>
> Series is:
> Reviewed-by: Alex Deucher
Thanks. Is it okay to merge all of these via the amdgpu tre
On 2018-06-01 03:44 PM, Alex Deucher wrote:
> On Fri, Jun 1, 2018 at 9:40 AM, Michel Dänzer wrote:
>> On 2018-06-01 02:58 PM, Alex Deucher wrote:
>>> On Thu, May 31, 2018 at 12:17 PM, Michel Dänzer wrote:
>>>> From: Michel Dänzer
>>>>
>>
ndling in amdgpu.
Please rebase this series on top of
https://patchwork.freedesktop.org/patch/226311/ and update the
documentation in amdgpu_prime.c as needed in each patch.
--
Earthling Michel Dänzer | http://www.amd.com
Libre softwa
nt body is missing from the generated documentation.
> + * For coherent userptr handling registers an MMU notifier to inform the
> driver
> + * about updates on a page tables of a process.
Something like "updates to page tables" instead of "updates on a page
tables"
On 2018-06-05 11:48 AM, Christian König wrote:
> Just a copy leftover from radeon.
>
> Signed-off-by: Christian König
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | M
ke sure to merge this change via
a tree which has the v3d driver, and fix it up as well, or don't do the
fini => destroy rename.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
__
ng way
to do it. :)
The xorg.conf.d mechanism is for shipping snippets required for a driver
or other Xorg module to work out of the box. xorg.conf is still the
place for actual configuration.
--
Earthling Michel Dänzer | http://www.amd.com
Libre softwar
On 2018-06-06 07:03 PM, Michel Dänzer wrote:
> On 2018-06-06 06:01 PM, Michel Dänzer wrote:
>> On 2018-06-01 06:03 PM, sunpeng...@amd.com wrote:
>>> From: "Leo (Sunpeng) Li"
>>>
>>> This ended up being different enough from v2 to warrant a new patc
e
4.16 development cycle.
[0] You can change Xorg's colour depth either via -depth on its command
line, or via the xorg.conf screen section:
Section "Screen"
Identifier "Screen0"
DefaultDepth 30 # or 16 or 8
EndSection
--
Earthling Mic
On 2018-06-06 06:01 PM, Michel Dänzer wrote:
> On 2018-06-01 06:03 PM, sunpeng...@amd.com wrote:
>> From: "Leo (Sunpeng) Li"
>>
>> This ended up being different enough from v2 to warrant a new patchset. Per
>> Michel's suggestions, there have been various
the commit log:
Fixes: e277adc5a06c "drm/amd/display: Hookup color management functions"
Tested-by: Michel Dänzer <michel.daen...@amd.com>
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X d
On 2018-06-01 05:17 PM, Christian König wrote:
> Am 01.06.2018 um 16:02 schrieb Michel Dänzer:
>> On 2018-06-01 02:11 PM, Christian König wrote:
>>> Sorry, accidentally send this series without a cover letter.
>>>
>>> This is a cleanup to the DMA-buf int
0 00 00 e9 e5 fd ff ff <0f> 0b
48 83 bb e0 12 00 00 00 0f 84 f3 fe ff ff 48 83 3c 24 00
[ 783.705152] RIP: dm_update_crtcs_state+0x3b8/0x440 [amdgpu] RSP:
b53f884e7ad0
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
commit log should mention that the patch modifies amdgpu_mn.c as
well. With that fixed,
Reviewed-by: Michel Dänzer
> Subject: [PATCH 2/2] drm/amd: Add sphinx documentation for amd_ip_funcs
>
> [...]
>
> + /**
> + * @name: Name of IP block
> + */
>
On 2018-06-22 03:41 PM, Leo Li wrote:
>
> Ping!
>
> FYI, all the new patches are v2, with the exception of 6/7, which is a
> v3. (On second thought, should have started a new thread :) )
I've pushed the changes (with some minor fix-ups), thanks and sorry it
took so long!
--
E
From: Michel Dänzer
In that case, the display hardware applies gamma to the HW cursor.
Bugzilla: https://bugs.freedesktop.org/106578
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/src
sk.
That would be better.
--
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
From: Michel Dänzer
Fixes the BUG_ON spuriously triggering under the following
circumstances:
* ttm_eu_reserve_buffers processes a list containing multiple BOs using
the same reservation object, so it calls
reservation_object_reserve_shared with that reservation object once
for each
From: Michel Dänzer
In that case (with DC as of 4.17 kernels), the display hardware applies
gamma to the HW cursor.
v2:
* Also use all 0s when alpha == 0 in the gamma passthrough case.
Bugzilla: https://bugs.freedesktop.org/106578
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 25
On 2018-06-27 01:50 PM, Chris Wilson wrote:
> Quoting Michel Dänzer (2018-06-26 15:31:47)
>> From: Michel Dänzer
>>
>> Fixes the BUG_ON spuriously triggering under the following
>> circumstances:
>>
>> * ttm_eu_reserve_buffers processes a list cont
From: Michel Dänzer
Instead of from drmmode_set_mode_major. There's no need to re-set the
gamma LUT on every modeset, the kernel should preserve it.
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 29 +
1 file changed, 17 insertions(+), 12 deletions
From: Michel Dänzer
This has always been disabled, no need to keep it.
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 12
1 file changed, 12 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 1563417a7..5fe49b607 100644
--- a/src
same issue applies to at least some of the other
places modified by this patch.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
a
> restrictions
This also needs to be removed in the comment before
amdgpu_bo_pin_restricted. With that fixed,
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
I'm not seeing either issue with my Tonga.
P.S. By default, KASAN only reports the first issue it finds and then
disables itself. One has to pass kasan_multi_shot on the kernel command
line to make it keep reporting issues.
--
Earthling Michel Dänzer | http://ww
On 2018-06-26 10:28 AM, Zhang, Jerry (Junwei) wrote:
> On 06/26/2018 03:46 PM, Michel Dänzer wrote:
>> On 2018-06-26 08:00 AM, Junwei Zhang wrote:
>>> It could be got by amdgpu_bo_gpu_offset() if need
>>>
>>> Signed-off-by: Junwei Zhang
>>&
On 2018-06-26 10:39 AM, Michel Dänzer wrote:
> On 2018-06-25 03:58 PM, Tom St Denis wrote:
>> With a Tonga dGPU installed in a Raven1 system I see (attached) dmesg
>> warning from init.
>>
>> Also, every warm reboot results in my Tonga failing to init (also
>>
From: Michel Dänzer
Without this, there could not be enough slots, which could trigger the
BUG_ON in reservation_object_add_shared_fence.
Cc: sta...@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/106418
Reported-by: mikhail.v.gavri...@gmail.com
Signed-off-by: Michel Dänzer
---
drivers
From: Michel Dänzer
To hopefully make the code dealing with GPU vs CPU pages a little
clearer.
Suggested-by: Christian König
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 8
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h | 2 ++
drivers/gpu/drm/amd/amdgpu
On 2018-06-25 04:15 AM, Zhang, Jerry (Junwei) wrote:
> On 06/23/2018 12:42 AM, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> Without this, there could not be enough slots, which could trigger the
>> BUG_ON in reservation_object_add_shared_fence.
>>
>>
From: Michel Dänzer
Without this, there could not be enough slots, which could trigger the
BUG_ON in reservation_object_add_shared_fence.
v2:
* Jump to the error label instead of returning directly (Jerry Zhang)
Cc: sta...@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/106418
Reported
On 2018-06-25 03:56 AM, zhoucm1 wrote:
> one question to you:
>
> Did you consider the case that GPU_PAGE_SIZE > CPU_PAGE_SIZE?
That is never the case: AMDGPU_GPU_PAGE_SIZE is always 4096, and
PAGE_SIZE is always >= 4096 (an integer multiple of it).
--
Earthlin
On 2018-06-22 12:34 PM, Christian König wrote:
> Am 22.06.2018 um 11:10 schrieb Michel Dänzer:
>> From: Michel Dänzer
>>
>> start / last / max_entries are numbers of GPU pages, pfn / count are
>> numbers of CPU pages. Convert between them accordingly.
>>
>>
too many module parameters. Do we really need yet
another one for this? Can't stutter mode just automatically be enabled
when appropriate?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa
On 2018-06-26 11:09 AM, Michel Dänzer wrote:
> On 2018-06-26 10:39 AM, Michel Dänzer wrote:
>> On 2018-06-25 03:58 PM, Tom St Denis wrote:
>>> With a Tonga dGPU installed in a Raven1 system I see (attached) dmesg
>>> warning from init.
>>>
>>> Also,
here's space for at least one fence after
calling reservation_object_reserve_shared, until
reservation_object_add_shared_fence is called.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and
On 2018-04-29 01:56 AM, Ilia Mirkin wrote:
> On Sat, Apr 28, 2018 at 7:02 PM, Michel Dänzer <mic...@daenzer.net> wrote:
>>
>> Unfortunately, there was an swiotlb regression (not directly related to
>> Christian's work) shortly after this fix, also in 4.16-rc1, which
From: Michel Dänzer <michel.daen...@amd.com>
Preparation for the following fix, no functional change intended.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/drmmode_display.c | 31 +++
1 file changed, 19 insertions(+), 12 deletions(-)
From: Michel Dänzer <michel.daen...@amd.com>
This prevents a nested call to drmHandleEvent, which would hang.
Fixes hangs when disabling TearFree on a CRTC while a DRI3 client is
page flipping.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/drmmode_display.c | 9
gt; gpu recover or hardware is doing reset, it doesn't want to be
> interrupted, and during the reset any driver open kms is meaningless.
Applications randomly failing to start up during a GPU reset would be
surprising and confusing for the user. The driver needs to handle this
transparently.
returning an error here *might* be
appropriate is when the driver has tried resetting the GPU, but it has
definitely and irrecoverably failed. But even in that case, it might be
better to let the open succeed, and let userspace figure out what
happened by other means.
--
Earthling Michel Dänzer
On 2018-04-27 04:44 PM, Michel Dänzer wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> Fixes memory leaks.
>
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
> ---
> amdgpu/amdgpu_device.c | 2 ++
> 1 file changed, 2 insertions(+)
>
commit
0176adb004065d6815a8e67946752df4cd947c5b "swiotlb: refactor
coherent buffer allocation" in 4.16-rc1.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
On 2018-04-29 09:02 AM, Christian König wrote:
> Am 29.04.2018 um 01:02 schrieb Michel Dänzer:
>> On 2018-04-28 06:30 PM, Ilia Mirkin wrote:
>>> On Fri, Apr 27, 2018 at 9:08 AM, Michel Dänzer <mic...@daenzer.net>
>>> wrote:
>>>> From: Michel Dänzer
On 2018-04-28 06:30 PM, Ilia Mirkin wrote:
> On Fri, Apr 27, 2018 at 9:08 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> Previously, TTM would always (with CONFIG_TRANSPARENT_HUGEPAGE enabled)
>> try t
gt;mc.gart_size >> PAGE_SHIFT;
> - placements.flags = bo->mem.placement | TTM_PL_FLAG_TT;
> + placements.flags = (bo->mem.placement & ~TTM_PL_MASK_MEM) |
> + TTM_PL_FLAG_TT;
>
> r = ttm_bo_mem_space(bo, , , true, false);
> if (unli
From: Michel Dänzer <michel.daen...@amd.com>
Not doing so resulted in DRI2 page flips not actually changing the FB
being scanned out, showing intermittent flicker of the "back" buffer
rendering.
Bugzilla: https://bugs.freedesktop.org/102643
Fixes: 55e513b978b2 "U
From: Michel Dänzer <michel.daen...@amd.com>
If we hit a problem while setting up ShadowFB, just carrying on trying
to set up HW acceleration instead is unlikely to work.
(Ported from radeon commit 7d435354099119234d443b07e2df1c7b9f97cf3c)
Signed-off-by: Michel Dänzer <michel.daen..
From: Michel Dänzer <michel.daen...@amd.com>
We were freeing it earlier but then still trying to access it in
AMDGPUFreeRec.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/amdgpu_kms.c | 2 ++
src/amdgpu_probe.c | 8 ++--
2 files changed, 4 insertions(+),
From: Michel Dänzer <michel.daen...@amd.com>
We were not doing so in all cases, leaking memory allocated by the
latter.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/drmmode_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/drmmode
From: Michel Dänzer <michel.daen...@amd.com>
We were leaking the memory allocated by TimerSet.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/amdgpu_kms.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/amdgpu_kms.c b/src/amdgpu_kms.c
index 7d582095b..cb0f
From: Darren Salt <devs...@moreofthesa.me.uk>
(Ported from amdgpu commit 2f72be038d22c54620e436af30121dd89f79a003)
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
man/radeon.man | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/man/radeon.man b/ma
From: Michel Dänzer <michel.daen...@amd.com>
We were trying to call acceleration specific functions from LeaveVT.
Instead, memset the scanout buffer to all 0 in LeaveVT and allocate a
new one in EnterVT.
Bugzilla: https://bugs.freedesktop.org/102948
Fixes: c16ff42f927d ("Make all a
From: Michel Dänzer <michel.daen...@amd.com>
We were leaking it.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/amdgpu_kms.c | 19 +--
src/amdgpu_probe.c | 6 --
2 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/src/amdgpu
ed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/drmmode_display.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 2cef93cdd..4ca94e71d 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -260
ed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/drmmode_display.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 167ecfb43..f57c43647 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -279
From: Michel Dänzer <michel.daen...@amd.com>
We were leaking it.
(Ported from amdgpu commit cfccf4c4e7e5c73fe4040fabeb1b43283cf29b33)
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/radeon_kms.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/radeon
From: Michel Dänzer <michel.daen...@amd.com>
We were leaking it.
(Inspired by amdgpu commit 9d84934309e4ccd9a43c73d958b8ff10ef2fc990)
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/radeon_kms.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
From: Michel Dänzer <michel.daen...@amd.com>
We were not doing so in all cases, leaking memory allocated by the
latter.
(Cherry picked from amdgpu commit f6b39bcd45cb06976ba8a3600df77fc471c63995)
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/drmmode_display.c | 4
From: Michel Dänzer <michel.daen...@amd.com>
We were leaking the memory allocated by TimerSet.
(Ported from amdgpu commit 84aad09f18fed6b52b0c073f0bbd675a6de07807)
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/radeon_kms.c | 1 +
1 file changed, 1 insertion(+)
diff
From: Michel Dänzer <michel.daen...@amd.com>
Not used anymore.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
b/drivers/gpu/dr
From: Michel Dänzer <michel.daen...@amd.com>
Corresponding to the previous non-DC change.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 9 ++---
2 f
From: Michel Dänzer <michel.daen...@amd.com>
Hardcoding the maximum numbers could result in spurious error messages
from the IRQ state callbacks, e.g. on Polaris 11/12:
[drm:dce_v11_0_set_pageflip_irq_state [amdgpu]] *ERROR* invalid pageflip crtc 5
[drm:amdgpu_irq_disable_all [amdgpu]]
From: Michel Dänzer <michel.daen...@amd.com>
It's dead code.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 21 ++---
1 file changed, 6 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm
From: Michel Dänzer <michel.daen...@amd.com>
The compiler was warning:
In file included from drivers/gpu/drm//amd/amdgpu/amdgpu.h:45:0,
from drivers/gpu/drm//amd/amdgpu/psp_v10_0.c:27:
drivers/gpu/drm//amd/amdgpu/psp_v10_0.c: In function ‘psp_v10_0_cmd_submit’:
drivers/g
hat a spin.
>
> Without this flag tilling fails and only displays a quite unusual pattern.
>
> I would actually prefer if we can completely remove this flag and
> instead always enable the VM programming on supported hardware.
>
> Is there any downside on doing so?
Is there a partic
;
> ---
>
> I couldn't figure out how to configure the kernel to get any of this code
> to compile.
Just enabling CONFIG_DRM_AMDGPU should be enough AFAICT.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
gt; libdrmdatadir = @libdrmdatadir@
> +if HAVE_AMDGPU
> dist_libdrmdata_DATA = amdgpu.ids
> +endif
>
Reviewed and pushed, thanks!
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
__
From: Michel Dänzer <michel.daen...@amd.com>
It means it just didn't find an entry for the GPU in the amdgpu.ids file.
Fixes spurious
amdgpu_parse_asic_ids: Cannot parse ASIC IDs: Resource temporarily unavailable
error messages in that case.
Reported-by: Marek Olšák <marek.ol..
From: Michel Dänzer <michel.daen...@amd.com>
In order to use consistent editorconfig settings in both amdgpu
directories.
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
tests/amdgpu/.editorconfig | 13 +
1 file changed, 13 insertions(+)
create mode 100644
> num_handles,
>
> ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_WAIT, );
> if (ret < 0)
> - return ret;
> + return -errno;
>
> if (first_signaled)
> *first_signaled = args.first_signaled;
>
--
Earthling Michel Dän
lpfn ?
> + min(bo->placements[i].lpfn, lpfn) : lpfn;
> }
> return ttm_bo_validate(>tbo, >placement, );
> }
>
Good catch.
Reviewed-by: Michel Dänzer <michel.daen...@amd.com>
--
Earthling Michel Dänzer |
or is used by more than one at the same time.
In that case, accounting a BO as suggested by Michal above, in every
process that shares it, should work fine, shouldn't it?
The OOM killer will first select the process which has more memory
accounted for other things than the BOs shared w
On 2018-01-19 11:02 AM, Michel Dänzer wrote:
> On 2018-01-19 10:58 AM, Christian König wrote:
>> Am 19.01.2018 um 10:32 schrieb Michel Dänzer:
>>> On 2018-01-19 09:39 AM, Christian König wrote:
>>>> Am 19.01.2018 um 09:20 schrieb Michal Hocko:
>>>>>
ule would be
>> that such a memory is bound to the process life time. I guess we will
>> find more users for this later.
>
> I already tried that and the problem with that approach is that some
> buffers are not created by the application which actually uses them.
>
>
On 2018-01-19 10:58 AM, Christian König wrote:
> Am 19.01.2018 um 10:32 schrieb Michel Dänzer:
>> On 2018-01-19 09:39 AM, Christian König wrote:
>>> Am 19.01.2018 um 09:20 schrieb Michal Hocko:
>>>> On Thu 18-01-18 12:01:32, Eric Anholt wrote:
>>>>
On 2018-01-17 05:18 PM, Christian König wrote:
> Am 17.01.2018 um 17:06 schrieb Michel Dänzer:
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> In order to use consistent editorconfig settings in both amdgpu
>> directories.
>>
>> Signed-
PUs.
For issues with the nvidia driver, please use the corresponding support
facilities.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx maili
M_AMDGPU_SI
>
> #if defined(CONFIG_DRM_RADEON) || defined(CONFIG_DRM_RADEON_MODULE)
>
NAK from me as well.
This isn't something that the administrator/user needs to decide.
Somebody needs to figure out the exact conditions under which the DMA
allocation path is needed, and make the cod
On 2018-01-24 06:35 PM, Mario Kleiner wrote:
> On 01/22/2018 07:01 PM, Michel Dänzer wrote:
>> On 2018-01-22 03:14 AM, Mario Kleiner wrote:
>>> Ok, 3rd revision, now with per-x-screen drmmode_crtc_funcs rec
>>> and set_gamma = NULL in the depth 30 case. Also back to Fr
From: Michel Dänzer <michel.daen...@amd.com>
DRI clients can use depth 32 pixmaps while the screen is depth 24, in
which case page flipping would fail.
Reported-by: Mario Kleiner <mario.kleiner...@gmail.com>
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
src/drmm
On 2018-01-24 12:50 PM, Michal Hocko wrote:
> On Wed 24-01-18 12:23:10, Michel Dänzer wrote:
>> On 2018-01-24 12:01 PM, Michal Hocko wrote:
>>> On Wed 24-01-18 11:27:15, Michel Dänzer wrote:
> [...]
>>>> 2. If the OOM killer kills a process which is shar
On 2018-01-30 12:56 PM, Christian König wrote:
> Am 30.01.2018 um 12:42 schrieb Michel Dänzer:
>> On 2018-01-30 12:36 PM, Nicolai Hähnle wrote:
>>> On 30.01.2018 12:34, Michel Dänzer wrote:
>>>> On 2018-01-30 12:28 PM, Christian König wrote:
>>>>>
pen in the code with
> the CONFIG_DEBUG_FS macro).
>
> Saw passing something about an amd-gfx mailing list. Is this list still valid
> for amdgpu related work?
Yes, moving there.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
under Valgrind on Intel GPU and see same
> errors in log:
It could be luck that the Unity engine's errors flagged by valgrind
result in a crash with radeonsi but not with i965.
The best course of action at this point is to fix the errors in the
Unity engine, then check if it still crashes with radeonsi.
--
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-02-02 06:33 PM, Alex Deucher wrote:
> Using the wrong mask.
>
> Noticed-by: Hans de Ruiter <h...@keasigmadelta.com>
> Signed-off-by: Alex Deucher <alexander.deuc...@amd.com>
The series is
Reviewed-by: Michel Dänzer <michel.daen...@amd.c
On 2018-01-26 10:42 PM, Mario Kleiner wrote:
> On 01/25/2018 05:06 PM, Michel Dänzer wrote:
>> On 2018-01-24 06:35 PM, Mario Kleiner wrote:
>>>
>>> It only happens if a client wants a fbconfig with alpha channel, for
>>> destination alpha blending etc.,
include/ddc_service_types.h
> b/drivers/gpu/drm/amd/display/include/ddc_service_types.h
> index 019e7a095ea1..f3bf749b3636 100644
> --- a/drivers/gpu/drm/amd/display/include/ddc_service_types.h
> +++ b/drivers/gpu/drm/amd/display/include/ddc_service_types.h
> @@ -32,7 +32,7 @@
>
> enum ddc_res
On 2018-01-24 12:50 PM, Michal Hocko wrote:
> On Wed 24-01-18 12:23:10, Michel Dänzer wrote:
>> On 2018-01-24 12:01 PM, Michal Hocko wrote:
>>> On Wed 24-01-18 11:27:15, Michel Dänzer wrote:
> [...]
>>>> 2. If the OOM killer kills a process which is shar
t needs to be "export allow_rgb10_configs=false"?
You can also try the method I described in
https://bugs.freedesktop.org/show_bug.cgi?id=104808#c2 , I verified that
to work.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
On 2018-01-30 11:42 AM, Daniel Vetter wrote:
> On Tue, Jan 30, 2018 at 10:43:10AM +0100, Michel Dänzer wrote:
>> On 2018-01-30 10:31 AM, Daniel Vetter wrote:
>>
>>> I guess a good first order approximation would be if we simply charge any
>>> newly allocated bu
ian.koe...@amd.com>
Please add:
Cc: sta...@vger.kernel.org
Fixes: 09ac4fcb3f25 ("drm/ttm: Implement vm_operations_struct.access v2")
so that it'll get backported to the relevant stable branches.
--
Earthling Michel Dänzer | http
On 2018-01-30 12:28 PM, Christian König wrote:
> Am 30.01.2018 um 12:02 schrieb Michel Dänzer:
>> On 2018-01-30 11:40 AM, Christian König wrote:
>>> Am 30.01.2018 um 10:43 schrieb Michel Dänzer:
>>>> [SNIP]
>>>>> Would it be ok to hang onto potentially
On 2018-01-30 11:40 AM, Christian König wrote:
> Am 30.01.2018 um 10:43 schrieb Michel Dänzer:
>> [SNIP]
>>> Would it be ok to hang onto potentially arbitrary mmget references
>>> essentially forever? If that's ok I think we can do your process based
>>> acc
801 - 900 of 1906 matches
Mail list logo
