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

[tournier.elie]

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.

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.