[Mesa-dev] [RFC] spec: MESA_program_binary

[Timothy Arceri]

On 22/02/17 06:11, Ian Romanick wrote:
> 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? :)

Yeah ok, I hadn't thought about apps ignoring the enum and just keeping 
a single copy. I guess your right we should eventually have a 
driver-side cache by default so can just package up the cache items and 
return them.

I'm happy with a one enum solution :)


>
>>>> 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.
>