[Mesa-dev] [RFC] spec: MESA_program_binary
Nicolai Hähnle
nhaehnle at gmail.com
Fri Feb 17 08:34:04 UTC 2017
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 <tarceri at itsqueeze.com
> <mailto: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
> <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 at lists.freedesktop.org
> <mailto:mesa-dev at 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 at lists.freedesktop.org <mailto:mesa-dev at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
More information about the mesa-dev
mailing list