Sounds good!
One thing to confirm, If the original location is already in the invisible,
will the notifier callback to move the bo from invisible to visible? if it is
true and the logic is already available in the kernel, can we use NO_CPU_ACCESS
flag by default to accomplish the similar
On 30/06/17 10:55 AM, Mao, David wrote:
> Vulkan allows the application to decide whether it wants the allocation
> to be host visible and device local.
> If we drop the flag, what will happen if we did not set the
> NO_CPU_ACCESS flag?
> Will it fail the map in case the allocation could be
Vulkan allows the application to decide whether it wants the allocation to be
host visible and device local.
If we drop the flag, what will happen if we did not set the NO_CPU_ACCESS flag?
Will it fail the map in case the allocation could be placed in invisible heap
then?
Thanks.
Best Regards,
On 29/06/17 07:05 PM, Daniel Vetter wrote:
> On Thu, Jun 29, 2017 at 06:58:05PM +0900, Michel Dänzer wrote:
>> On 29/06/17 05:23 PM, Christian König wrote:
>>> Am 29.06.2017 um 04:35 schrieb Michel Dänzer:
On 29/06/17 08:26 AM, John Brooks wrote:
> On Wed, Jun 28, 2017 at 03:05:32PM
On 2017-06-29 09:56 PM, John Brooks wrote:
On Thu, Jun 29, 2017 at 11:35:53AM +0900, Michel Dänzer wrote:
On 29/06/17 08:26 AM, John Brooks wrote:
On Wed, Jun 28, 2017 at 03:05:32PM +0200, Christian König wrote:
Am 28.06.2017 um 04:33 schrieb John Brooks:
When the
On Thu, Jun 29, 2017 at 11:35:53AM +0900, Michel Dänzer wrote:
> On 29/06/17 08:26 AM, John Brooks wrote:
> > On Wed, Jun 28, 2017 at 03:05:32PM +0200, Christian König wrote:
> >> Am 28.06.2017 um 04:33 schrieb John Brooks:
> >>> When the AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag is given by
On 30/06/17 12:03 AM, Marek Olšák wrote:
> Do you have any concern if we also stop using the CPU_ACCESS flag on radeon?
No concern from my side for radeon.
> On Thu, Jun 29, 2017 at 4:51 PM, Christian König
> wrote:
>> Yeah, I was thinking something similar.
>>
>> See
On 30/06/17 05:16 AM, Alex Deucher wrote:
> If the displays are off, set the vblank time to max to make
> sure mclk switching is enabled. Avoid mclk getting set
> to high when no displays are attached.
>
> bug: https://bugs.freedesktop.org/show_bug.cgi?id=101528
> fixes: 09be4a5219
On 30/06/17 06:08 AM, Shaoyun Liu wrote:
> 1. Use spin lock instead of mutex in KIQ
> 2. Directly write to KIQ fence address instead of using fence_emit()
> 3. Disable the interrupt for KIQ read/write and use CPU polling
This list indicates that this patch should be split up in at least three
Hello Christian,
I've running this since you've sent it on-top of amd-staging-4.11. But I
think my poor little FUJITSU PRIMERGY TX150 S7, Xeon X3470 (Nehalem),
PCIe 2.0, 24 GB is to old for this stuff...
[1.066475] pci :05:00.0: VF(n) BAR0 space: [mem
0x-0x0003 64bit]
1. Use spin lock instead of mutex in KIQ
2. Directly write to KIQ fence address instead of using fence_emit()
3. Disable the interrupt for KIQ read/write and use CPU polling
Change-Id: Id3693a2878ce1338f55aee3def6e7fc0f6b81996
Signed-off-by: Shaoyun Liu
---
Quoting Alex Deucher :
On Thu, Jun 29, 2017 at 1:38 PM, Gustavo A. R. Silva
wrote:
Add function header comment to make it clear that local variable sw_cg
is used for debugging and it should not be removed.
Addresses-Coverity-ID: 1198635
Cc:
On Thu, Jun 29, 2017 at 1:38 PM, Gustavo A. R. Silva
wrote:
> Add function header comment to make it clear that local variable sw_cg
> is used for debugging and it should not be removed.
>
> Addresses-Coverity-ID: 1198635
> Cc: Alex Deucher
>
Add function header comment to make it clear that local variable sw_cg
is used for debugging and it should not be removed.
Addresses-Coverity-ID: 1198635
Cc: Alex Deucher
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/radeon/vce_v2_0.c |
Do you have any concern if we also stop using the CPU_ACCESS flag on radeon?
Thanks,
Marek
On Thu, Jun 29, 2017 at 4:51 PM, Christian König
wrote:
> Yeah, I was thinking something similar.
>
> See the intention behind CPU_ACCESS_REQUIRED is to always guarantee that CPU
Yeah, I was thinking something similar.
See the intention behind CPU_ACCESS_REQUIRED is to always guarantee that
CPU access is immediately possible.
If you ask me that is not really useful for the UMD and was never meant
to be used by Mesa (only the closed source UMD and some kernel internal
Hi,
Given how our memory manager works and the guesswork that UMDs have to
do to determine whether to set the flag, I think the flag isn't
useful.
I'm proposing that CPU_ACCESS_REQUIRED:
- will be deprecated.
- It will remain to be accepted by the kernel driver, but it will
either not have any
> -Original Message-
> From: Christian König [mailto:deathsim...@vodafone.de]
> Sent: Thursday, June 29, 2017 4:17 AM
> To: Huang, Ray; amd-gfx@lists.freedesktop.org; Deucher, Alexander; Koenig,
> Christian
> Cc: Huan, Alvin; Qiao, Joe(Markham); Jiang, Sonny; Wang, Ken; Yuan, Xiaojie
>
-Original Message-
From: Mark Brown [mailto:broo...@kernel.org]
Sent: Wednesday, June 28, 2017 11:36 PM
To: Alex Deucher
Cc: dri-de...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org;
alsa-de...@alsa-project.org; airl...@gmail.com; Mukunda, Vijendar;
rajeevkumar.li...@gmail.com;
On Wed, Jun 28, 2017 at 7:08 PM, Gustavo A. R. Silva
wrote:
> Hi Alex,
>
> Quoting "Deucher, Alexander" :
>
>>> -Original Message-
>>> From: Gustavo A. R. Silva [mailto:garsi...@embeddedor.com]
>>> Sent: Wednesday, June 28, 2017 10:22 AM
On Thu, Jun 29, 2017 at 06:58:05PM +0900, Michel Dänzer wrote:
> On 29/06/17 05:23 PM, Christian König wrote:
> > Am 29.06.2017 um 04:35 schrieb Michel Dänzer:
> >> On 29/06/17 08:26 AM, John Brooks wrote:
> >>> On Wed, Jun 28, 2017 at 03:05:32PM +0200, Christian König wrote:
> >
> >
On 29/06/17 05:23 PM, Christian König wrote:
> Am 29.06.2017 um 04:35 schrieb Michel Dänzer:
>> On 29/06/17 08:26 AM, John Brooks wrote:
>>> On Wed, Jun 28, 2017 at 03:05:32PM +0200, Christian König wrote:
>
> Instead of the flag being set in stone at BO creation, set the flag
> when a
On Thu, Jun 29, 2017 at 04:16:53PM +0800, Christian König wrote:
> Am 29.06.2017 um 10:09 schrieb Huang Rui:
> > psp->cmd will be used on resume phase, so we can not free it on hw_init.
> > Otherwise, a memory corruption will be triggered.
> >
> > Signed-off-by: Huang Rui
> >
Am 29.06.2017 um 04:35 schrieb Michel Dänzer:
On 29/06/17 08:26 AM, John Brooks wrote:
On Wed, Jun 28, 2017 at 03:05:32PM +0200, Christian König wrote:
Am 28.06.2017 um 04:33 schrieb John Brooks:
When the AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag is given by userspace,
it should only be
Am 29.06.2017 um 10:09 schrieb Huang Rui:
psp->cmd will be used on resume phase, so we can not free it on hw_init.
Otherwise, a memory corruption will be triggered.
Signed-off-by: Huang Rui
---
V1 -> V2:
- remove "cmd" variable.
- fix typo of check.
Alex, Christian,
This
On Thu, Jun 29, 2017 at 04:07:33PM +0800, Michel Dänzer wrote:
> On 29/06/17 04:59 PM, Huang Rui wrote:
> > On Thu, Jun 29, 2017 at 03:34:57PM +0800, Michel Dänzer wrote:
> >> On 29/06/17 04:03 PM, Huang Rui wrote:
> >>> psp->cmd will be used on resume phase, so we can not free it on hw_init.
>
Am 29.06.2017 um 00:59 schrieb John Brooks:
On Wed, Jun 28, 2017 at 03:06:47PM +0200, Christian König wrote:
Am 28.06.2017 um 04:33 schrieb John Brooks:
Signed-off-by: John Brooks
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +++
psp->cmd will be used on resume phase, so we can not free it on hw_init.
Otherwise, a memory corruption will be triggered.
Signed-off-by: Huang Rui
---
V1 -> V2:
- remove "cmd" variable.
- fix typo of check.
Alex, Christian,
This is the final fix for vega10 S3. The random
Reviewed-by: Christian König .
Regards,
Christian.
Am 28.06.2017 um 21:26 schrieb Kent Russell:
The default was changed to 512 from 1024, but the default in the
description wasn't updated.
Kent
___
amd-gfx mailing list
On 29/06/17 04:59 PM, Huang Rui wrote:
> On Thu, Jun 29, 2017 at 03:34:57PM +0800, Michel Dänzer wrote:
>> On 29/06/17 04:03 PM, Huang Rui wrote:
>>> psp->cmd will be used on resume phase, so we can not free it on hw_init.
>>> Otherwise, a memory corruption will be triggered.
>>>
>>>
Indeed a nice catch.
Just skimming over the PSP code, wouldn't it be simpler to temporary
allocate the cmd buffer in psp_np_fw_load()?
Doesn't looks like that is used outside that function. Might even be
possible to just allocate the buffer on the stack.
Regards,
Christian.
Am 29.06.2017
On Thu, Jun 29, 2017 at 03:34:57PM +0800, Michel Dänzer wrote:
> On 29/06/17 04:03 PM, Huang Rui wrote:
> > psp->cmd will be used on resume phase, so we can not free it on hw_init.
> > Otherwise, a memory corruption will be triggered.
> >
> > Signed-off-by: Huang Rui
> > ---
>
On 29/06/17 04:03 PM, Huang Rui wrote:
> psp->cmd will be used on resume phase, so we can not free it on hw_init.
> Otherwise, a memory corruption will be triggered.
>
> Signed-off-by: Huang Rui
> ---
>
> Alex, Christian,
>
> This is the final fix for vega10 S3. The random
psp->cmd will be used on resume phase, so we can not free it on hw_init.
Otherwise, a memory corruption will be triggered.
Signed-off-by: Huang Rui
---
Alex, Christian,
This is the final fix for vega10 S3. The random memory corruption issue is root
caused.
Thanks,
Ray
---
34 matches
Mail list logo