On Tue, Jul 4, 2017 at 10:09 AM, Michel Dänzer wrote:
> On 03/07/17 10:03 PM, Marek Olšák wrote:
>> On Mon, Jul 3, 2017 at 12:08 PM, Michel Dänzer wrote:
>>> On 30/06/17 08:43 PM, Marek Olšák wrote:
I don't know what is being talked about here
On 03/07/17 10:03 PM, Marek Olšák wrote:
> On Mon, Jul 3, 2017 at 12:08 PM, Michel Dänzer wrote:
>> On 30/06/17 08:43 PM, Marek Olšák wrote:
>>>
>>> I don't know what is being talked about here anymore, but I wouldn't
>>> like to use CPU_ACCESS_REQUIRED or
On Mon, Jul 3, 2017 at 12:08 PM, Michel Dänzer wrote:
> On 30/06/17 08:43 PM, Marek Olšák wrote:
>>
>> I don't know what is being talked about here anymore, but I wouldn't
>> like to use CPU_ACCESS_REQUIRED or CPU_ACCESS_REALLY_REQUIRED in
>> userspace. The reason is that
On 30/06/17 08:43 PM, Marek Olšák wrote:
>
> I don't know what is being talked about here anymore, but I wouldn't
> like to use CPU_ACCESS_REQUIRED or CPU_ACCESS_REALLY_REQUIRED in
> userspace. The reason is that userspace doesn't and can't know whether
> CPU access will be required, and the
> On 30/06/17 03:59 PM, Christian König wrote:
>> Am 30.06.2017 um 08:51 schrieb Michel Dänzer:
>>> We can deal with that internally in the kernel, while fixing the
>>> existing flag for userspace.
>> And as I said, NAK to that approach. I'm not going to add a
>> CPU_ACCESS_REALLY_REQUIRED flag in
On Fri, Jun 30, 2017 at 12:34 PM, Christian König
wrote:
> Am 30.06.2017 um 09:14 schrieb Michel Dänzer:
>>
>> On 30/06/17 03:59 PM, Christian König wrote:
>>>
>>> Am 30.06.2017 um 08:51 schrieb Michel Dänzer:
We can deal with that internally in the kernel,
Am 30.06.2017 um 09:14 schrieb Michel Dänzer:
On 30/06/17 03:59 PM, Christian König wrote:
Am 30.06.2017 um 08:51 schrieb Michel Dänzer:
We can deal with that internally in the kernel, while fixing the
existing flag for userspace.
And as I said, NAK to that approach. I'm not going to add a
On 30/06/17 03:59 PM, Christian König wrote:
> Am 30.06.2017 um 08:51 schrieb Michel Dänzer:
>> We can deal with that internally in the kernel, while fixing the
>> existing flag for userspace.
>
> And as I said, NAK to that approach. I'm not going to add a
> CPU_ACCESS_REALLY_REQUIRED flag in the
Am 30.06.2017 um 08:51 schrieb Michel Dänzer:
We can deal with that internally in the kernel, while fixing the
existing flag for userspace.
And as I said, NAK to that approach. I'm not going to add a
CPU_ACCESS_REALLY_REQUIRED flag in the kernel just because mesa has
messed up it's use case.
Am 30.06.2017 um 03:36 schrieb Michel Dänzer:
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
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 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
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
17 matches
Mail list logo