[Mesa-dev] [RFC] spec: MESA_program_binary
Ernst Sjöstrand
ernstp at gmail.com
Fri Feb 17 08:31:32 UTC 2017
Also, what if the user switches between say AMDGPU-PRO and RadeonSI?
Regards
//Ernst
2017-02-17 1:33 GMT+01:00 Timothy Arceri <tarceri at itsqueeze.com>:
>
>
> 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.
>
>
>
>> 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.
>>>
>>> ---
>>>>>
>>>>> Techland games such as Dead Island and Dying Light make use of
>>>>> GetProgramBinary(). My current guess is the Dead Island crash
>>>>> https://bugs.freedesktop.org/show_bug.cgi?id=85564 is caused
>>>>> due to buggy handling of this feature not being available.
>>>>>
>>>>> Anyway I'm not sure how we go about getting Khronos to assign
>>>>> enums for the binary formats but thought I'd send this to the
>>>>> list for discussion.
>>>>>
>>>>
>> There's a two step process:
>>
>> 1. Vendors request a block of values via the Khronos internal bugzilla.
>>
>> 2. When the spec is ready, another bug is submitted requesting the spec
>> be published.
>>
>> Mesa might still have some available enums assigned to it. I'll have to
>> check...
>>
>> docs/specs/MESA_program_binary.txt | 78
>>>>> ++++++++++++++++++++++++++++++++++++++
>>>>> 1 file changed, 78 insertions(+)
>>>>> create mode 100644 docs/specs/MESA_program_binary.txt
>>>>>
>>>>> diff --git a/docs/specs/MESA_program_binary.txt
>>>>> b/docs/specs/MESA_program_binary.txt
>>>>> new file mode 100644
>>>>> index 0000000..b34e42e
>>>>> --- /dev/null
>>>>> +++ b/docs/specs/MESA_program_binary.txt
>>>>> @@ -0,0 +1,78 @@
>>>>> +Name
>>>>> +
>>>>> + MESA_program_binary
>>>>> +
>>>>> +Name Strings
>>>>> +
>>>>> + GL_MESA_program_binary
>>>>> +
>>>>> +Contact
>>>>> +
>>>>> + Timothy Arceri (tarceri 'at' itsqueeze.com)
>>>>> +
>>>>> +Status
>>>>> +
>>>>> + Complete.
>>>>> +
>>>>> +Version
>>>>> +
>>>>> + Last Modified Date: February 16, 2017
>>>>> + Revision: #1
>>>>> +
>>>>> +Number
>>>>> +
>>>>> + ???
>>>>> +
>>>>> +Dependencies
>>>>> +
>>>>> + OpenGL ES 2.0 is required.
>>>>> +
>>>>> + Written based on the wording of the OpenGL ES 2.0 specification.
>>>>> +
>>>>> + This extension interacts with OES_get_program_binary.
>>>>> +
>>>>> +Overview
>>>>> +
>>>>> + MESA provides drivers for multiple hardware vendors. This
>>>>> extension
>>>>> + provides binary formats in order to avoid conflicts between
>>>>> drivers when
>>>>> + loading precompiled binaries.
>>>>> +
>>>>> +New Procedures and Functions
>>>>> +
>>>>> + None.
>>>>> +
>>>>> +New Tokens
>>>>> +
>>>>> + Accepted by the <binaryFormat> parameter of ShaderBinary:
>>>>> +
>>>>> + MESA_PROGRAM_BINARY_AMD ????
>>>>> + MESA_PROGRAM_BINARY_NV ????
>>>>> + MESA_PROGRAM_BINARY_INTEL ????
>>>>> + MESA_PROGRAM_BINARY_BCOM ????
>>>>> + MESA_PROGRAM_BINARY_QCOM ????
>>>>> +
>>>>> +Additions to Chapter 2 of the OpenGL ES 2.0 Specification (OpenGL
>>>>> Operation)
>>>>> +
>>>>> + Add the following paragraph to the end of section 2.10.2:
>>>>> +
>>>>> + "Depending on the hardware in use the apropriate <binaryFormat> is
>>>>> + returned when querying the list of SHADER_BINARY_FORMATS.
>>>>> +
>>>>> + Pre-compiled shader binaries in this format may be loaded via
>>>>> ShaderBinary.
>>>>> +
>>>>> + When a binary fails to load, an INVALID_VALUE error is generated
>>>>> and a
>>>>> + more detailed error message is appended to the shader's info log."
>>>>> +
>>>>> +Errors
>>>>> +
>>>>> + INVALID_VALUE is generated if the <binary> parameter to
>>>>> ShaderBinary was
>>>>> + produced with an incompatible version of the MESA shader compiler.
>>>>> +
>>>>> +New State
>>>>> +
>>>>> + None.
>>>>> +
>>>>> +Revision History
>>>>> +
>>>>> + #01 02/16/2010 Timothy Arceri First draft.
>>>>> +
>>>>>
>>>>> _______________________________________________
>>> mesa-dev mailing list
>>> mesa-dev at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>
>>
>> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170217/6cec62ff/attachment-0001.html>
More information about the mesa-dev
mailing list