[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <866f4e8d-98be-0aaf-d3a2-f3e5bc94e945@loongson.cn>
Date: Thu, 22 Jun 2023 00:49:48 +0800
From: Sui Jingfeng <suijingfeng@...ngson.cn>
To: Lucas Stach <l.stach@...gutronix.de>,
Sui Jingfeng <18949883232@....com>,
Russell King <linux+etnaviv@...linux.org.uk>,
Christian Gmeiner <christian.gmeiner@...il.com>,
David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>
Cc: linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
etnaviv@...ts.freedesktop.org,
Philipp Zabel <p.zabel@...gutronix.de>,
Bjorn Helgaas <bhelgaas@...gle.com>
Subject: Re: [PATCH v10 07/11] drm/etnaviv: Add support for the dma coherent
device
Hi
On 2023/6/21 23:58, Lucas Stach wrote:
>> you approach forbidden any possibility to use the WC BO at anywhere.
>>
>>
>> My approach need only check once, while you approach need at least 3
>> check plus
>>
>> so much bit-wise logic operations, plus a function call (&, ==, &&,
>> &, ~, &) .
>>
>> and every time you create a BO. This nasty judgement happens.
>>
> BO creation again is not a fast path. You are committing to allocate
> new memory, which is a few orders of magnitude more costly than the few
> instructions needed for those comparisons.
>
What's wrong with you point here is that
We are not going make it more worse because it is worse.
We would like same any single bit of the performance.
It's about the beauty, and beauty and correctness is every thing.
My implement is good both in the perspective of beauty and in the
perspective of the performance.
BO creation is fast or not is irrelevant to what the point we are discuss.
You are always introduce non-critical factor to disturb the discuss,
leading the people go a wrong direction.
--
Jingfeng
Powered by blists - more mailing lists