From: szabolcs.nagy@arm•com (Szabolcs Nagy)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] arm64: Add support for Half precision floating point
Date: Tue, 16 Feb 2016 12:57:26 +0000 [thread overview]
Message-ID: <56C31CB6.7090901@arm.com> (raw)
In-Reply-To: <20160216115335.GE14509@arm.com>
On 16/02/16 11:53, Will Deacon wrote:
> On Tue, Feb 16, 2016 at 11:48:14AM +0000, Szabolcs Nagy wrote:
>> On 28/01/16 16:00, Will Deacon wrote:
>>> On Tue, Jan 26, 2016 at 04:11:51PM +0000, Catalin Marinas wrote:
>>>> On Tue, Jan 26, 2016 at 04:02:58PM +0000, Will Deacon wrote:
>>>>> On Tue, Jan 26, 2016 at 03:52:46PM +0000, Suzuki K Poulose wrote:
>>>>>> +#define HWCAP_FPHP (1 << 9)
>>>>>> +#define HWCAP_ASIMDHP (1 << 10)
>>>>>
>>>>> Where did we get to with the mrs trapping you proposed here?
>>>>>
>>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/374609.html
>>>>>
>>>>> At some point, we need to consider whether or not we want to continue
>>>>> adding new HWCAPs or whether your suggestion above is actually useful
>>>>> to userspace.
>>>>
>>>> IMO, even if we merge the MRS emulation, I would still like to see
>>>> HWCAPs exported. We are not short on bits yet (53 to go ;)).
>>>
>>> I'm less keen. HWCAPs don't align well with the way that the ARM
>>> architecture versions features and we should be encouraging people to
>>> use the MRS emulation if it exists.
>>>
>>>>> Did the libc guys get anywhere with a prototype? What do we need to do
>>>>> to make progress with it?
>>>>
>>>> This investigation should indeed continue but I think it is orthogonal.
>>>
>>> Not if its intended to replace HWCAPs in the longterm.
>>>
>>
>> userspace needs HWCAP bits independently of the MIDR emulation.
>>
>> MIDR cannot replace HWCAP:
>>
>> - MIDR does not map to features in a future-proof way
>> (we don't know which MIDR will indicate fp16 availability)
>>
>> - MIDR would be useful for more fine-grained uarch specific
>> tuning decisions, HWCAP is for arch extensions like fp16.
>>
>> - We don't yet know if the proposed MIDR emulation solves
>> all userspace issues we want it to solve. I'll try to
>> investigate that as well as the alternative VDSO based
>> approach (if VDSO can work, that would be better for
>> userspace). There are nasty issues here so the conclusion
>> might take a while, but that should not hold up HWCAPs.
>
> I'm not solely proposing MIDR as an alternative to HWCAP. I'm proposing
> that the feature registers, e.g. ID_AA64MMFR0_EL1 are used instead.
>
if the ID_* system registers are made available to userspace
(with fixup for heterogeneous systems), that works too.
hwcap is still more accessible in userspace:
- libc gets it without additional syscall/trap
- user code can get it with getauxval(AT_HWCAP)
- ifunc resolvers take a hwcap argument.
- HWCAP_ bits are already exposed in uapi headers.
i'm not familiar with the ID_ regs though.
next prev parent reply other threads:[~2016-02-16 12:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-26 15:52 [PATCH] arm64: Add support for Half precision floating point Suzuki K Poulose
2016-01-26 16:02 ` Will Deacon
2016-01-26 16:11 ` Catalin Marinas
2016-01-28 16:00 ` Will Deacon
2016-02-16 11:48 ` Szabolcs Nagy
2016-02-16 11:53 ` Will Deacon
2016-02-16 12:57 ` Szabolcs Nagy [this message]
2016-01-26 16:21 ` Suzuki K. Poulose
2016-01-26 16:55 ` Siddhesh Poyarekar
2016-01-28 16:07 ` Will Deacon
2016-01-28 16:46 ` Siddhesh Poyarekar
2016-01-28 17:27 ` Catalin Marinas
2016-01-28 17:44 ` Siddhesh Poyarekar
2016-01-28 17:55 ` Suzuki K. Poulose
2016-01-28 16:51 ` Adhemerval Zanella
2016-02-02 17:31 ` Szabolcs Nagy
2016-02-02 18:12 ` Adhemerval Zanella
2016-02-02 18:25 ` Szabolcs Nagy
2016-02-02 18:28 ` Adhemerval Zanella
2016-02-26 15:37 ` Catalin Marinas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56C31CB6.7090901@arm.com \
--to=szabolcs.nagy@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox