[Mesa-dev] [RFC 00/11] GL_ARB_gpu_shader_fp64

Alex Deucher alexdeucher at gmail.com
Thu Mar 23 15:52:42 UTC 2017


On Thu, Mar 23, 2017 at 11:51 AM, tournier.elie <tournier.elie at gmail.com> wrote:
> Hello,
>
> It's seems impossible to expose all the drivers to soft fp64 with one
> piece of code.
> So what do you think about landing this series (with some fix) for r600?
>
> The other drivers will use the NIR version of soft fp64.
> BTW, an "alpha RFC" series is coming on the ML soonish.

Sounds good to me.

Thanks,

Alex


>
> Elie
>
> On 13 March 2017 at 17:00, tournier.elie <tournier.elie at gmail.com> wrote:
>> To resume, using NIR resolve some troubles: fp64 can be use by Intel,
>> no autogen code, SPIR-V on OpenGL.
>> So if nobody opposes (too hard), i will start implement fp64 in NIR.
>>
>> But NIR doesn't solve everything. How to handle drivers without NIR
>> support like r600? Should we land the GLSL IR version of fp64 for
>> that?
>> I know this imply code duplication but at least GL_ARB_gpu_shader_fp64
>> will be available for r600.
>>
>> On 11 March 2017 at 18:51, Jason Ekstrand <jason at jlekstrand.net> wrote:
>>> On Sat, Mar 11, 2017 at 9:50 AM, Jason Ekstrand <jason at jlekstrand.net>
>>> wrote:
>>>>
>>>>
>>>> As I said at the top, I'm really not going for NIR or nothing.  I agree
>>>> that GLSL has advantages for chips like r600 which badly needs emulation and
>>>> isn't moving to NIR any time soon.  Also, fp64 isn't a requirement in Vulkan
>>>> and, given that Vulkan covers both desktop and mobile, likely won't be any
>>>> time soon.  (In fact, if someone wanted Vulkan FP64 on hardware that didn't
>>>> support it, I'd be tempted to tell them to pay someone to write a layer.)
>>>> However, *if* we decide that emulated fp64 is better on, for instance Ivy
>>>> Bridge, *and* we had customers that cared about it (I don't know of any),
>>>> then doing it in NIR could yield substantially better results (depending on
>>>> initial shader quality) due to being able to run nir_opt_algebraic first.
>>>> Those are a lot of ifs so maybe I'm suggesting we design for a non-use-case,
>>>> but I really don't want to paint ourselves into a corner that we have to
>>>> crawl out of 2 years from now.
>>>
>>>
>>> Chatting with people on IRC this morning, I realized there's a killer
>>> argument for why we *need* NIR support: SPIR-V on OpenGL.  As soon as you
>>> expose the GL_ARB_spirv extension on an OpenGL 4.0+ driver, you must support
>>> fp64.  If we ever need emulated fp64 in such a driver, the lowering has to
>>> be done in NIR because there is no GLSL IR in the path.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


More information about the mesa-dev mailing list