From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id DA64543DB4 for ; Thu, 11 Aug 2022 02:18:29 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id D6FCB68B82B; Thu, 11 Aug 2022 05:18:26 +0300 (EEST) Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id C5D0D68B636 for ; Thu, 11 Aug 2022 05:18:20 +0300 (EEST) Received: by mail-qt1-f172.google.com with SMTP id x5so4944484qtv.9 for ; Wed, 10 Aug 2022 19:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc; bh=Xpbrs8SJNgGsfhMamF0L180C8Z7wHr33WvzDvifaBao=; b=jNKwd6k8lNr/tCXal6HfH4P6iRmUa8xTk3OuBV9hRKSWJrBIs235/tFFFyWXlz+1wI 0kEjxYkCzYC/DgmvvNo1NmaHMh9UiurhiXzLpB7gKUv6lI/MnRLx8YKro8rUT1Xd6Qxn GbImQKljFU6mmnIhY1/lulXzNrqKOAUpea53AiKzGPjLn67yBr4uVE9PcshezWBdHUdY yw3ydkvbaGkEZUkEAclYyQv6MYPHF66ydlUL4jH9Hw74+Wr474ht8Z0I35Z5hlNPiOkn lhsUHaRozonFdj7SwvG6YGa+yeQpzulwNhv4p3FGjdgONiMNqJNtpJIPS/XARTZ7AP9t /uew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc; bh=Xpbrs8SJNgGsfhMamF0L180C8Z7wHr33WvzDvifaBao=; b=iAMnWIxW5wfzXlZMWOnB0f5Xg4CaAUlLg85q9dj2hiKdCyGCRQA+jnkdHSY3Mru0id fsPlSKlH1GMRbLpOVRDGUha8nB5GZT2N1qRKliKtM4BQwUfwIZFSj1C9iVVIkop46S1E v3ekNxJ2ua6MwdETeO7FBowKVW+grv3RWW2tcNPOAi5R97Xv1PZWyUiSHa5w2M+6fQ58 NDaLysztV/PVombDLWTEQNBeHDdYx4mxJYRc+EeQN8DrgimbA1nj9uuxpQZMnRtyJlkq mFv2unIeIt533Daz/BSS4g0FbZlHkNQfbmB4hrNPDrDQmysdrCsQ49/bypLugNJJRaAr tXyg== X-Gm-Message-State: ACgBeo2OWdm1QHJim21ui5tAuKWWbu9WpAWnHWGU9XERrq6qVTXSDsXO AB2NucVxW4CiUm5GnfxBCKyJobQEiU6MwVB6ErFu94i6MJI= X-Google-Smtp-Source: AA6agR52jv9FJkVRi/00wK157pk4zGJGAX5/wDOmIUdHIk/BNHkwpsEy83GUaKI3BW1Jrzg3/8dvvn4kxQFTR7nHl+c= X-Received: by 2002:a05:622a:199f:b0:343:5c86:c98e with SMTP id u31-20020a05622a199f00b003435c86c98emr4258145qtc.220.1660184299117; Wed, 10 Aug 2022 19:18:19 -0700 (PDT) MIME-Version: 1.0 References: <20220810204712.3123-1-timo@rothenpieler.org> <20220810204712.3123-6-timo@rothenpieler.org> <423b2beb-9ad6-003e-be31-e3237f9f9788@rothenpieler.org> <9f390e60-6243-115c-ca11-81d2fc3d43e9@rothenpieler.org> <3ff257f1-dcbc-543e-21d6-50e62d8f879d@rothenpieler.org> In-Reply-To: <3ff257f1-dcbc-543e-21d6-50e62d8f879d@rothenpieler.org> From: Mark Reid Date: Wed, 10 Aug 2022 19:18:06 -0700 Message-ID: To: FFmpeg development discussions and patches X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [FFmpeg-devel] [PATCH 06/11] avutil/half2float: adjust conversion of NaN X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Wed, Aug 10, 2022 at 3:56 PM Timo Rothenpieler wrote: > On 11.08.2022 00:37, Mark Reid wrote: > > On Wed, Aug 10, 2022 at 3:28 PM Timo Rothenpieler > > > wrote: > > > >> On 11.08.2022 00:18, James Almer wrote: > >>> Then maybe the current implementation should be moved back to exr (it > >>> used to be internal to exr until Paul made it standalone), so this lavu > >>> module can match the existing hardware implementations of IEEE-734 half > >>> floats for the purpose of relevant pixel format support. > >> > >> That doesn't seem necessary to me. > >> The values produced before and now are both correct, just different. > >> But there is no functional difference in the values it produces. > >> > >> Duplicating the entirety of that code just for that seems extremely > >> unnecessary. > >> > > > > openexr does note the intel implementations difference here > > > https://github.com/AcademySoftwareFoundation/Imath/blob/main/src/Imath/half.h#L288 > > It's actually quite curious how that came to be. > My natural idea would be that our current and EXRs code does it right. > > But all hardware as well as gccs software emulation agrees. Makes me > wonder if it's fully intentional and according to some spec. But I > couldn't find anything on the matter. > Ya I'm curious too now. I might ask the exr folks. I noticed the difference when I fixed the subnormal bug a couple years ago. That is why I changed it to match the openexr's halfToFloat() version that preserves the Nan values instead of changing them. This new behavior might have been what it was before I changed it in 8d19b3c4a5. I looked at the intel architecture developer's manual and sadly it only describes the float32 to float16 algorithm. The change back seems pretty benign to me too. The openexr implementation is relying on the hardware instruction too if it can. I don't know what one would do with the exact NaN value anyway. _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".