[Mesa-dev] [RFC] spec: MESA_program_binary

[Nicolai Hähnle]

On 16.02.2017 09:21, Tapani Pälli wrote:
> On 02/16/2017 10:11 AM, Timothy Arceri wrote:
>> On 16/02/17 18:58, 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.
>>> 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.
>>
>> Or are you saying we don't need to define the enums? If so I don't think
>> that is correct. The ARB_get_program_binary extension says:
>>
>>     "A vendor extension must also be present in order
>>     to define one or more binary formats, thereby populating the list of
>>     PROGRAM_BINARY_FORMATS.  The <binaryFormat> returned by
>>     GetProgramBinary is always one of the binary formats in this list.
>>
>>     ...
>>
>>     The beauty of this extension, however, is that an application does
>> not need
>>     to be aware of the vendor extension on any given implementation. It
>> only
>>     needs to retrieve a program binary with an anonymous
>> <binaryFormat> and
>>     resupply that same <binaryFormat> when loading the program binary."
>>
>
> OK, I did not spot this one. At same time we have to supply extension
> where values defined (which makes it hard to make changes later) but
> then from application POV the values are still considered anonymous and
> it will likely not use the extension. This is a bit strange requirement ..
>
> We can still internally put more data in to the blob about exact backend
> and version requirements and so on so I guess single enum value per
> vendor is enough.

So the question is what the use case of this extension really is. Keep 
in mind that the driver can always decide to fail loading a binary.

If the purpose is to allow games to cache shaders for a second run, then 
I think even a single Mesa enum is sufficient -- the local driver is 
always going to be the same.

If the purpose is to distribute pre-compiled binaries via the internet, 
then assigning enums that need to be registered with Khronos is clearly 
not scalable. We can't have an enum for each build ID, so it's all 
unworkable anyway, and we'd need some way of querying a build ID string.

I think this points towards us registering a single enum for Mesa only.

Still, a bit more information about how this extension is actually used 
in the wild could change my mind.

Cheers,
Nicolai