[Mesa-dev] [RFC] spec: MESA_program_binary

[Ian Romanick]

On 02/16/2017 04:33 PM, Timothy Arceri wrote:
> On 17/02/17 10:44, Ian Romanick wrote:
>> On 02/15/2017 11:58 PM, Timothy Arceri wrote:
>>> On 16/02/17 17:55, Tapani Pälli wrote:
>>>>
>>>> On 02/16/2017 04:52 AM, Timothy Arceri wrote:
>>>>> In order add functionality to ARB_get_program_binary we need
>>>>> binary format enums.
>>>>
>>>> I've understood that this is a driver internal enumeration. When
>>>> application gets the binary it also receives enum (integer value) what
>>>> format we gave. Then when loading application needs to query what
>>>> formats are supported by the implementation and load the correct
>>>> binary.
>>>> We just need to internally make agreement on format list and return
>>>> correct one matching the current driver in use?
>>>
>>> Not that it's actually likely to happen but if we were to only have a
>>> single MESA enum an application could only distribute a single binary.
>>
>> Applications really, really, *REALLY* should not distribute binaries
>> retrieved from the driver.  The intention of this extension is for
>> applications to implement their own shader cache, for example, at
>> application installation.  The driver can reject the binary at any time
>> for any reason.  Driver changes, hardware changes, OS changes, phase of
>> the moon, etc.
>>
>> Looking at the GLES extension registry, it appears that the other
>> vendors have just a single binary for all the hardware they make.  Based
>> on that, having a single Mesa enum isn't an insane idea.  We would just
>> need to agree on the format of the header so that the driver receiving
>> the blob could determine which driver generated the blob.
> 
> The only other thing to consider with a single enum is that it will
> require a laptop with an Intel cpu and Nvidia gpu for example to
> recompile the binary if the user were to switch between using the Intel
> and Nvidia gpus. This might happen depending on if the laptop is plugged
> into a power source or not.
> 
> If we don't care about this than one enum is fine.

Hm... I think we care, but I don't think multiple enums will help
existing apps... but maybe?  I imagine the usual scenario is:

- User runs first time on nouveau.

- Application saves binaries from nouveau.

- User runs second time on i965.

- Application submits binary from nouveau.

- Application deletes its binary cache, resubmits from source, resaves
binaries from i965.

- User runs third time on nouveau.

- Application submits binary from i965.

- Application deletes its binary cache, resubmits from source, resaves
binaries from nouveau.

- Lather

- Rinse

- Repeat

It seems like if we actually care about this configuration, we'd need a
more complex solution.  It's not 100% clear what that solution would be
or how we would be able to implement it.  I think the right solution is
a driver-side shader cache that is smart enough to track binaries from
multiple drivers without stomping on each other.  Right? :)

>>> e.g either for AMD, INTEL or NVIDIA but not one for each. That is unless
>>> we were to compile and pack all gpu vendor binarys at the same time
>>> which seems overly complicated and expensive.
>>>
>>> I could see an intenal id being used for gpu generations from hardware
>>> vendors.