From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x29.google.com (mail-oa1-x29.google.com [IPv6:2001:4860:4864:20::29]) by sourceware.org (Postfix) with ESMTPS id 7CB893858D37 for ; Fri, 25 Aug 2023 17:39:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7CB893858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oa1-x29.google.com with SMTP id 586e51a60fabf-1c4de3b9072so741307fac.3 for ; Fri, 25 Aug 2023 10:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692985165; x=1693589965; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ij9d9egj0AvSmpK+HuiN2PVKqNbT+oYHCChXSus+N4k=; b=RSnpHbwklrgMUHwk0Rbp6J++ceAzxMlRdWkCw9mKwsgR/+brP8fmUFtL5nM2IfAq/d +tS3tH/jehDLDNnJYctpfnrlFOyC7pVOOPpy3xGDSILM/xKKt9sJFv9tCe9eViH925i1 RxWpnSF23aNQeuw1Ch7pOmwDzt+zCtpvqhwX9hOCQX74GSNVGD+ahb1TRUx11KlneNN8 s3+3SBinEvrXR7R81wSQ6B/JLveR3jkDbbnKU/ZE0+fxlVYY0Zw3x+so56yfqSq5H72x A3ytiCZVXLI0bOL1xbs8Ax74sIPY6FQJotGdfwG8Z80G7KWQZgt4WTKJvNkrIZ9iNCoD rA4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692985165; x=1693589965; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ij9d9egj0AvSmpK+HuiN2PVKqNbT+oYHCChXSus+N4k=; b=bG3CnafNWDoirEE9hmx9xnHuE3lIjj6fdDBVvQPR5hoWsX+ZJlGxvFc0imIN78Mj2+ 3FTmPnDeQwDMbs7vx5A+XdgpFSfJaBVepFOjIO8NlVcn+gGdbETwIRzRGyxtiXU0ikox KFExCDx9VaOyD4mLpROyxePb+HcAseOYwfV0Zg0lm4ib/eSTJ62YU/hLor7ScRrs0Szv 4HAniXa9Eceys0iCNaNAFFkBTu39GOvNJk1YeBFFJn6Ngfq8mYEIijmwqeXJTORH0cOc gzhB7AULzz0YSQFoilVExYi8lEfoWMYDxcdAOohUtsxxYY3czFaio8H0q6fm4CMUoqgN mKXw== X-Gm-Message-State: AOJu0YzzuB+z0WMroPhQuuiaE55ethKyURA70aCP7qAO4oNrdRZ5+qe7 ygBN34V7wgn4EBUgk1Cjfm3Z82t0j2asJB+AlMQ= X-Google-Smtp-Source: AGHT+IG+Z9bGTnmTA3oi8uGGn50Sn/bqjqRWTbuLKaCAGAPWuzkAe+xLdOS8wwGIz1F01wH2CYuXgXPn6jzOIRVz3TA= X-Received: by 2002:a05:6870:4713:b0:1bf:8724:9c19 with SMTP id b19-20020a056870471300b001bf87249c19mr3454012oaq.5.1692985165304; Fri, 25 Aug 2023 10:39:25 -0700 (PDT) MIME-Version: 1.0 References: <20230824184851.3204976-1-goldstein.w.n@gmail.com> <20230824191430.3220651-1-goldstein.w.n@gmail.com> <87r0nra94g.fsf@oldenburg.str.redhat.com> In-Reply-To: <87r0nra94g.fsf@oldenburg.str.redhat.com> From: Noah Goldstein Date: Fri, 25 Aug 2023 12:39:11 -0500 Message-ID: Subject: Re: [PATCH v2] x86: Add support for AVX10 version and vec size in cpu-features To: Florian Weimer Cc: Noah Goldstein via Libc-alpha , hjl.tools@gmail.com, carlos@systemhalted.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Aug 25, 2023 at 2:12=E2=80=AFAM Florian Weimer = wrote: > > * Noah Goldstein via Libc-alpha: > > > +/* AVX10 version information is handled differently from all other CPU= ID > > + related logic. Rather than being encoded in cpuid as discrete bool= eans, the > > + AVX10 version is encoded is a full byte that represents the version= number > > + (greater than or equal to 1). Since the CPUID API is only able to = handle > > + boolean returns, we enumerate `x86_cpu_AVX10_V{1..255}` which can b= e queried > > + by the user and have special logic in `x86_cpu_{present,active}`. = This is > > + unpleasant on our end, but is the only way to make the existing API= also > > + support version queries. */ > > + > > + /* All 1s should never be a value feature index. */ > > + x86_cpu_AVX10_V255 =3D ~0, > > + x86_cpu_AVX10_V254 =3D x86_cpu_AVX10_V255 - 1, > > + x86_cpu_AVX10_V253 =3D x86_cpu_AVX10_V254 - 1, > > + x86_cpu_AVX10_V252 =3D x86_cpu_AVX10_V253 - 1, > > + x86_cpu_AVX10_V251 =3D x86_cpu_AVX10_V252 - 1, > > Is this really necessary? We can define an x86_cpu_avx10_version inline > function that calls __x86_get_cpuid_feature_leaf and extracts the > version byte. Is it really necessary to support something like this? > I agree it's not the best API. My feelings are two fold on this. 1) The existing API that users know should support the feature, even if its not the best way for users query the logic. Adding support for specific ver= sion queries in CPU_FEATURE_{ACTIVE,PRESENT} doesn't prevent us from adding an API that allows for querying the full byte. But only adding the b= yte might be disruptive to users that expect to be able to do all their queryin= g through the existing API. 2) For a lot of use cases, this is sufficient. Currently we only have two versions and I think the common use case is not "is feature above level X?", but "do I have feature X?". The latter can reasonably be supported with a single query of: CPU_FEATURE_{ACTIVE,PRESENT}(AVX10_). > CPU_FEATURE_ACTIVE (AVX10_V2) > > This would be the alternative: > > x86_cpu_avx10_version () >=3D 2 > We do plan to propose a new byte API in a follow up :) > Let's hope that version 0 means no AVX10. 8-) > versions start at 1. > Thanks, > Florian >