On 17.02.2017 09:31, Ernst Sjöstrand wrote:
Also, what if the user switches between say AMDGPU-PRO and RadeonSI?
I'd expect radeonsi to use the single Mesa enum, while AMDGPU-PRO obviously uses an AMD-assigned enum.
Cheers, Nicolai
Regards //Ernst 2017-02-17 1:33 GMT+01:00 Timothy Arceri <tarc...@itsqueeze.com <mailto: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 <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 <http://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 <mailto:mesa-dev@lists.freedesktop.org> https://lists.freedesktop.org/mailman/listinfo/mesa-dev <https://lists.freedesktop.org/mailman/listinfo/mesa-dev> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org <mailto:mesa-dev@lists.freedesktop.org> https://lists.freedesktop.org/mailman/listinfo/mesa-dev <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
