Also, what if the user switches between say AMDGPU-PRO and RadeonSI? Regards //Ernst
2017-02-17 1:33 GMT+01:00 Timothy Arceri <tarc...@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@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev >>> >> >> _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
